Embree raycaster for V-Ray

[vlado]

Does it have the 2.3 version of V-Ray? Which OS is it running?

Best regards,
Vlado

[bear75]

vista business 64 bit, max 2011 64 sp2, vray 2.30.01

[cecofuli]

Fast test: Win7 64, 3ds max 2011 64, I7 970, plane, VRaySky+Sun, X3 VRaytrees proxy as istance, vrayembree bvh4. Same, exact rendertime

[super gnu]

this i think is the expected result since anything with dynamic geometry (i.e. proxies, or instances) will currently not use the embree raycaster.

[vlado]

What super gnu said - I specifically mentioned that the embree code has no effect on proxies. We can do that, but it requires rebuild of V-Ray itself and cannot be done as a plugin.

Best regards,
Vlado

[cecofuli]

this i think is the expected result since anything with dynamic geometry (i.e. proxies, or instances) will currently not use the embree raycaster.

Ahh, ok, thanks for the info. We use tons of proxy in our project. We will wait the VRayembree version with dynamic geometry support

[^Lele^]

You may have to wait a WEE bit for that, given companies may have a lot of effort invested in creating proxy libraries (which would need reconversion), and a lower precision raycaster is not to everyone's taste (in film, particularly, where scenes tend to be on the large-ish side, with very tiny objects present)...
Rewriting the bsp tree of vray to go bvh in the light of 30% speed improvement on selected situations (hardware/software/scene dependent) only is somewhat risky a business, in my eyes, especially when there are actually very few people i am aware of that can effectively squeeze every drop of Vray's power as it currently is.
In my view there's a lot more to be had from personal RnD, than there is in waiting for a rewrite.
I'm all up for options though: choice is nearly always good...

[vlado]

You may have to wait a WEE bit for that, given companies may have a lot of effort invested in creating proxy libraries (which would need reconversion)

There won't be need to reconvert the proxies; the .vrmesh format only describes the geometry but not any raycasting stuff - so we can switch to embree quite easily with full support for existing files.

Best regards,
Vlado

[^Lele^]

so you CAN actually switch to a bvh method for proxies?
I thought the whole point of a bvh versus bsp was the difference in space partitioning, which in proxies is written within the file, much like the bsp tree prepares static geo.
Would you be so kind as to clarify that a bit more?

Edit: what i may have missed of the embree stuff is that it has both a different partitioning scheme AND accelerated raycasting, and you can use either as you please, rather than be forced to a bvh partitioning to use the accelerated stuff. Is this the case?

Edit #2: http://software.intel.com/en-us/arti...o-ray-tracing/
Reading this, it seems to me that one needs the acceleration structures provided to get the most out of the performance of the raycaster itself, although some benefit can be had from the other aspects of the embree set of algorithms.
So it would work, but with reduced performance gains compared to properly BVHd geo?

[vlado]

so you CAN actually switch to a bvh method for proxies?

Yes.

I thought the whole point of a bvh versus bsp was the difference in space partitioning, which in proxies is written within the file, much like the bsp tree prepares static geo. Would you be so kind as to clarify that a bit more?

The proxy only stores a very crude partitioning of the geometry into voxels that contain about 10000 faces (see http://www.spot3d.com/vray/help/maya...sh_format.html). It does not specify how these voxels are organized for raycasting, nor does it specify how the triangles within each voxel are organized. So we are free to implement whatever raycasting strategies we want. Right now, the voxels go into the V-Ray dynamic raycaster as bounding boxes. Then, when loading a voxel, we build a separate bsp tree for it, so that it can be intersected with rays. It is this tree that can be switched to Embree very easily.

Best regards,
Vlado

[^Lele^]

Aaaaah!
That's the one bit i was missing: the voxelised representation in proxies is NOT an acceleration structure in itself.
I thought the format's partitioning of geo would be done on EXPORT, and kept that way at rendertime.
A number of performance issues with dynamic geo are now a LOT clearer, thankyou ever so much Vlado!

p.s.: does that mean that the bsp parameters for the static geo will ALSO influence the rendertime BSP building for dynamic geo?
Or are other heuristics used when preparing the bsp for the proxy voxel?

[stilgarna]

Hello Vlado,

At first it always crash with an existing scene. After many test, I disable shadows from global switch and no more problems.

Max2011 + Vray 2.30.01 (Bi Xeon-E5-2650 + 64Gb)
Scene with no GI.

Vray Raycaster : 05:22
Embree Raycaster (no AVX) : 05:12
Embree Raycaster (AVX) : Crash

I'll try to reproduce the crash with a more simple scene.

Best regards...

[bear75]

ok Vlado, so i can't figure out what is going on with this render slave

any news for my issue?

[vlado]

any news for my issue?

No, I have no idea what's wrong with that slave, unfortunately. The only thing I can think of, is if it had a different V-Ray version installed.

As for the crashes, there was a specific issue with displacement, which we are looking into, but if you have a scene that you can send to vlado@chaosgroup.com, it will be very helpful.

Best regards,
Vlado

[bear75]

No, I have no idea what's wrong with that slave, unfortunately. The only thing I can think of, is if it had a different V-Ray version installed.

As for the crashes, there was a specific issue with displacement, which we are looking into, but if you have a scene that you can send to vlado@chaosgroup.com, it will be very helpful.

Best regards,
Vlado

you've got mail