Optimizing/organizing scenes.

[Joelaff]

There is no need for this anymore with the latest builds; V-Ray will do this internally. The advantage is that it works even if the proxies are X-Ref'd in different files.
Vlado

Really? So if I have a bunch of objects that are instances in Max, and output them each to their own, separate proxy file, VRay is now smart enough to know that they are the same and only load one?

Just curious... How does that work? Saves some kind of object ID in the file and knows that those match?

That is really cool. I hadn't realized that it would work even if the instances were saved to separate files. I figured that only applied if you saved one big proxy file with all the instances in it.

[vlado]

Really? So if I have a bunch of objects that are instances in Max, and output them each to their own, separate proxy file, VRay is now smart enough to know that they are the same and only load one?

I meant that if there are VRayProxy objects that point to the same .vrmesh file, V-Ray will load the .vrmesh file only once. It's what the MaxScript that was described above does, but it's internal to V-Ray. What you describe is probably possible, but we don't do it right now (I know that something similar happens for .tx files where maketx will put a hash in the textures so that V-Ray can figure out if two texture files are the same and load just one of them).

Best regards,
Vlado

[Joelaff]

The Shell Material is quite useful for having lower resolution textures in your viewport than in your render. Takes a bit of organising and batch processing of textures to make low resolution versions but gives you a lot of control.

I think I learned this from you, Dave. It is a great trick! This is especially helpful when you want to use image sequences with VRayHDRI, as they do not update per frame in the viewport, whereas bitmaps image sequences do. So you can set up the shell to show the bitmap one in the viewport, but render the VRayHDRI.

Note that I am pretty sure Max still loads the bitmap texture into RAM during rendering, even if it is only marked for use in the viewport. This might only be the case if you set the bitmap as the "Original Material." I don't recall if it gets loaded when the Bitmap is in the "Baked Material." So watch out for this if you are trying to save render time memory. (VRayHDRI node would be smart enough to only load the textures that are needed for the current frame. So if both materials in the shell have only VRayHDRI maps then you are fine.)

[Joelaff]

I meant that if there are VRayProxy objects that point to the same .vrmesh file, V-Ray will load the .vrmesh file only once. It's what the MaxScript that was described above does, but it's internal to V-Ray. What you describe is probably possible, but we don't do it right now (I know that something similar happens for .tx files where maketx will put a hash in the textures so that V-Ray can figure out if two texture files are the same and load just one of them).

Thanks for the reply. I am now a little confused, though.

The maxscript I was talking about is zwischendrin.com_InstancesToVRayProxy_v1.0, which will let you select some existing, non-proxied instances and export them to a single VRayProxy file, but then create a proxy object in the scene for each of those instances. It sets all the proxy objects to reference the same VRayProxy file.

Is that no longer needed? What is the ideal way to handle a situation where you already have a bunch of instances that you basically want to convert to VRayProxies that render in the most efficient manner?

Thanks. Keep up with the tips. I love this sort of thread!

[Dave_Wortley]

I think I learned this from you, Dave. It is a great trick! This is especially helpful when you want to use image sequences with VRayHDRI, as they do not update per frame in the viewport, whereas bitmaps image sequences do. So you can set up the shell to show the bitmap one in the viewport, but render the VRayHDRI.

Note that I am pretty sure Max still loads the bitmap texture into RAM during rendering, even if it is only marked for use in the viewport. This might only be the case if you set the bitmap as the "Original Material." I don't recall if it gets loaded when the Bitmap is in the "Baked Material." So watch out for this if you are trying to save render time memory.

I know someone who's written a Shell Map which means you can do it at a map level rather than an entirely new material.

[dlparisi]

I meant that if there are VRayProxy objects that point to the same .vrmesh file, V-Ray will load the .vrmesh file only once. It's what the MaxScript that was described above does, but it's internal to V-Ray. What you describe is probably possible, but we don't do it right now (I know that something similar happens for .tx files where maketx will put a hash in the textures so that V-Ray can figure out if two texture files are the same and load just one of them).

Best regards,
Vlado

Does this mean we no longer need this script...http://forums.chaosgroup.com/showthr...184#post399184 ?

[Joelaff]

I see. I bet that is the script vlado was talking about. I don't think you need that one anymore, as VRayProxy objects that reference the same proxy file will not load the proxy more than once.

The one I was talking about converts EXISTING instances to VRayProxies that all reference the same file. (I think it also instances them in Max for convenience, but this is not needed anymore from a memory usage standpoint.)

Unless I am doing something where I need tons of high -res objects, like cloning rocks or trees I usually start with instances in Max, and then convert later. For cloning/scattering I would use proxies from the get-go.