Vray Proxy - Always loading geometry despite not actually being traced

[Jimmi]

I would expect VrayProxy nodes only loading geometry once the proxy(bounds) itself gets hit by a ray that needs to sample the given area.

Ive previously noticed that the alembic files get "linked" which I assumed to be just "grab a file handle, perhaps read some meta-data about the bounds".

But from what I can gather in a simple test ( one proxy is behind camera, and occluded by a large mesh just to be sure, no GI.. or I just point the camera at nothing so no secondary rays will be traced), it seems that the primitives from the vray proxy node end up in the "dynamic" geometry tree immediately.
Is that the expected behavior or is there anything Im missing here?

Vray 3.6004( or latest nightly of 3.6005), Maya 2018 Update 2, Windows 7

[asen.atanasov]

Hi,

the geometry is loaded and acceleration structures are build only if a ray intersects the proxy bounds - either camera, reflection, GI, etc. How do you know what ends up in the dynamic tree? The alembic files geometry needs to be read for other reasons as well. All the geometry is read in order to compute viewport preview. Also, during rendering if "Recompute bounding box" is turned on, all the geometry is read in order to compute the correct bounds. If the bounds written in alembic files are correct (this is not always the case) then this option can be switched off and additional reading of the geometry is not necessary. If this doesn't answer your question, please provide more details.

Best regards,
Asen

[Jimmi]

Hi Asen.

Thanks for your reply.
What you describe is indeed what I expected to happen. So glad to get that confirmed.

I have no way of knowing what ends up in the dynamic tree, that is indeed true. So, it could be placeholder data or something, but even without knowning that, things seem a bit odd to me.

I have made a small test scene which I have attached here(which I should have done to begin with, sorry.. time was short)
It contains a vrayProxy that loads an alembic file with two boxes in it.
No GI or anything and the camera is turning away from the proxy object in the opposite direction so Im pretty sure that no camera rays ever hits the proxy.
"Recompute bounding box" is not ticked on, so it should rely on what the Maya scene/translator does in my guess.
The proxy is even in "bounding box mode" so the maya session should not even have read it and cashed it.

There is nothing else in the scene.

The render output log says this
[2018/Jul/12|15:35:52] V-Ray: Preparing scene for frame...
[2018/Jul/12|15:35:52] V-Ray: Mesh file "C:/vray_case_proxy_expand/box.abc" linked successfully.
[2018/Jul/12|15:35:52] V-Ray: Compiling geometry...
[2018/Jul/12|15:35:52] V-Ray: Using embree ray tracing.
[2018/Jul/12|15:35:52] V-Ray: Building embree dynamic geometry tree...
[2018/Jul/12|15:35:52] V-Ray: Embree dynamic geometry tree contains 2 primitives.
[2018/Jul/12|15:35:52] V-Ray: Embree dynamic geometry tree built in 107.53 ms.
[2018/Jul/12|15:35:52] V-Ray: Embree dynamic geometry tree takes 0.01 MB.
[2018/Jul/12|15:35:52] V-Ray: Rendering image...

It links to the alembic file (which could just be a file handle that is established), but then the dynamic geometry tree seems to be containing 2 primitives already before it starts "Rendering Image".
Establishing a file handle to the file for loading the bounding box is legit if the bounds are not valid. To my knowledge they should be, so I dont see why it need to establish a link to the file already, but there could be internal reasons as you mention and thats fine.

Its more that it seems to read something from the file at least and establishes it inside the dynamic geometry tree.
So perhaps the geometries are just "established" but not really loaded.
But even that part is something that I would hope was avoidable.
If one have thousands/hundreds of objects within a proxy (and thousands of proxys) then even the overhead of reading info about the geometry would be a hit one would like to avoid until its actually needed.

Hope it all makes sense, and sorry for not giving the example scene in the first place (was more of a "am I right in my assumptions" kind of thing I ended up doing).

Jimmi

[yolov]

According to the devs, all geometry is always stored into the dynamic/static trees no matter if the camera sees it or not.
Unlike static geometry, dynamic geometry is not fully loaded if a ray does not hit it. It creates some overhead, yes, but this it is necessary to keep it there, because there's not way for V-Ray to know in advance if a ray is going to potentially hit geometry behind the camera or not. V-Ray may hit an object in front of the camera, whose BRDF says that it should spawn rays that go behind the camera and hit something else. If it was done in another way, it could be less efficient (actually according to the devs one of the older dynamic tree implementations did something like that and was quite inefficient compared to what V-Ray does now).
Here's some logs where a 12,000,000 triangle proxy is behind and in front of the camera:

behind camera:

[2018/Jul/19|12:08:17] V-Ray: Mesh file(s) "C:/Users/yolov/Desktop/cube_huge.vrmesh" linked successfully.
[2018/Jul/19|12:08:17] V-Ray: Compiling geometry...
[2018/Jul/19|12:08:17] V-Ray: Using embree ray tracing.
[2018/Jul/19|12:08:17] V-Ray: Building embree dynamic geometry tree...
[2018/Jul/19|12:08:17] V-Ray: Embree dynamic geometry tree contains 854 primitives.
[2018/Jul/19|12:08:17] V-Ray: Embree dynamic geometry tree built in 4.40 ms.
[2018/Jul/19|12:08:17] V-Ray: Embree dynamic geometry tree takes 0.11 MB.
[2018/Jul/19|12:08:17] V-Ray: Rendering image...
[2018/Jul/19|12:08:17] V-Ray: Number of raycasts: 518400 (1.00 per pixel)
[B][2018/Jul/19|12:08:17] V-Ray: Maximum memory usage for resman: 0.00 MB[/B]
[2018/Jul/19|12:08:17] V-Ray: Number of intersectable primitives: 854
[2018/Jul/19|12:08:17] V-Ray:   Static primitives: 854
[2018/Jul/19|12:08:18] V-Ray: Maximum memory usage for texman: 0.00 MB
[2018/Jul/19|12:08:18] V-Ray: Render complete

in front of camera:

[2018/Jul/19|12:08:27] V-Ray: Mesh file(s) "C:/Users/yolov/Desktop/cube_huge.vrmesh" linked successfully.
[2018/Jul/19|12:08:27] V-Ray: Compiling geometry...
[2018/Jul/19|12:08:27] V-Ray: Using embree ray tracing.
[2018/Jul/19|12:08:27] V-Ray: Building embree dynamic geometry tree...
[2018/Jul/19|12:08:27] V-Ray: Embree dynamic geometry tree contains 854 primitives.
[2018/Jul/19|12:08:27] V-Ray: Embree dynamic geometry tree built in 6.22 ms.
[2018/Jul/19|12:08:27] V-Ray: Embree dynamic geometry tree takes 0.11 MB.
[2018/Jul/19|12:08:27] V-Ray: Rendering image...
[2018/Jul/19|12:08:28] V-Ray: Number of raycasts: 518400 (1.00 per pixel)
[B][2018/Jul/19|12:08:28] V-Ray: Maximum memory usage for resman: 825.49 MB[/B]
[2018/Jul/19|12:08:28] V-Ray: Number of intersectable primitives: 854
[2018/Jul/19|12:08:28] V-Ray:   Static primitives: 854
[2018/Jul/19|12:08:29] V-Ray: Maximum memory usage for texman: 0.00 MB
[2018/Jul/19|12:08:29] V-Ray: Render complete

Note the memory for the resource manager.

Also a note - the 'bounding box' option for the proxy is only for the viewport representation, it has no effect on rendering.

I'm no expert on this side of V-Ray, but let me know if you need more information and I'll talk to the devs again.
I hope you find this information useful.

[Jimmi]

Hi Alex.
Great info there and great to know that the geometry at least isnt loaded on startup (and I guess I should have noticed the resman stats to begin with )

I guess my next question is. Would it be possible to have the Proxy node not submit its geometry to the tree before "it" is even hit?
The overhead of having to load hundreds of proxy nodes (reading alembic files) and submit hundreds of primitives from each of them, is a slight overhead that we would not mind being without.

My nearest reference to what I am seeking is from what I remember about Renderman Procedurals. They would just exist in the vray scene as a "bounded primitive" and would do nothing until a ray hits it. Only at that point would it be loading rib or generating geometry which would then be submitted to whatever trees it used.

[yolov]

No, not as far as I could understand from the devs.
But if you have a case where the overhead is a showstopper, do let us know and we'll look into it.

[Jimmi]

At the moment I think we will manage, so its not directly a show stopper.
For now we are primarily using VrayScene instances for all our none-deforming assets ( faster than proxy when we do not need to tweak shaders, and also due to other issues with the vray proxy setups ).
We can keep it down to a "limited" amount of assets dialed into "vray-proxy" mode on the shows currently running at least.

I hope that the "dummy" entries for the primitives are now slowing down the dynamic tree to much ( as per another thread of mine, the dynamic tree is pretty slow compared to the static one, and it gets worse the more stuff we push though it).

Anywa, it would be a nice thing to have in mind if a new iteration on the proxy setup is done (which I really hope there will be, if not then just a full blown replacement)

Thanks for your time.
Jimmi