Better understanding of vrmesh files.

[Ihno]

Hi,
I'm using them alot because it enables me to work with big CAD models without bothering too much about the polycount.
And I think I kind of understand what they are doing but I'm not sure and the information the docs provide doesn't seem to answer my questions.

Lets first try to explain my probably wrong understanding of it:
The vrmesh will split the model into multiple parts (Faces in voxel parameter) and is then able to load them independently if needed.
So it will load all chunks of geometry it needs into the ram and start the rendering. It can even unload and load parts while rendering if the ram is full. Which will slow down the render but at least it renders.
This isn't the case when the Optimize for instancing checkbox is checked. This checkbox means there will only be one chunk of geometry in the file so vray has to load it entirely.
That way we can prevent vray from loading/unloading this mesh on the fly.
The advantage of this is: when the mesh is used excessively i.e instancing grass leaves or trees in a forest scene vray has everything it needs in the ram.

Having that in mind I come to the conclusion: If you need to instance something very often which has NOT 100th of millions of polys the optimize for instancing option would be the way to go.
If you have a big mesh with tons of polys on the other hand it would probably be better to turn this off so vray can use the chunks to save ram.

So here are the questions:

1: Is this how it works?
2: Is my conclusion right?
3: Do you recommend to change the faces in voxel parameter? For example: to raise it in order to force vray to use more ram and do less load/unloading.
4: If I load the mesh and set it to show whole mesh, will I still have the same behaviour i.e. load/unload geo. on the fly or will it behave like standard max geometry?
5: If I set show whole mesh AND use modifiers above I will most likely lose all advantages and basically get normal geometry.(?)
6: Does this apply to all modifiers or just the ones which are like edit poly/ unwarp uvw skin and so on. Or also the ones which work with dynamically changing geometry like material, push, uvw map and so on?
7: Does all of this also apply for vray gpu?
I'm asking this because I have a big scene with 200m+ polys, all in vray meshes. And it doesn't want to render.
Smaller instanced geometry was exported with "optimize for instancing" enabled. And I exported the bigger meshes with optimize for instancing disabled.
I'll render the scene on cpu anyway but I would have expected a very slow render because of all the loading and unloading but not that it completely refuses to render. (3.6 btw)

[^Lele^]

1)yes
2)yes
3)yes, to a point. too low a facespervoxel count will make the voxel structure so heavy that it'll be slower to parse than the geo itself, and use up nearly as much ram. So, down to something like 5k is fine, below, not really. Use the vrmeshViewer.exe tool in the bin folder of your installation to inspect proxy voxelisation, and other aspects of your meshes.
4/5/6)to all intent and purposes, the mesh is loaded in ram, and appears to max as a trimesh. Modifiers can work because of that. So yes.
7)Yes.

Visibility (and so the loading of a proxy or part thereof) is determined not by camera alone, but also by GI and Shadow Rays.
You'll still save a wee bit of RAM compared to having the same geo as static (as far as RAM is concerned) triangles in your max scene, but likely all the above heuristics will be thrown out of the window if you're rendering, f.e. under sun and sky in the open.
Some ray will hit some part, and sooner, rather than later, in that case.
If a proxy is wholly occluded (try enclosing one into an opaque box, f.e.), then only the non-occluded part loads in ram, and the above points all hold true(er).

EDIT: Important note: when the dynamic memory limit is set to 0, proxies aren't allowed to be unloaded from RAM. So if you're starved for memory, set an explicit, suitable limit.
Second important note: Render with BUCKETS. Progressive methods (it includes the LC. so if you can, render BF with lower bounces) will query the whole of the screen at once, forcing the loading of most of the visible proxies in the scene at once. Not good.

[Ihno]

Thanks alot!
Very usefull Information! Especially the EDIT part