SDK for 3dsMax: VRenderInstance best practices?

[tysonibele]

Interesting...so it's not rendering a single object interpolated over a larger segment of subframes, it's actually rendering multiple objects.....never would have guessed!

[tysonibele]

Hey Yavor,

I've run into an interesting problem:

So the instancing implementation we sussed out in this thread has been working great for a while now. But today I had a situation where rendering 1 million particles with embree enabled takes approximately 10x longer than with embree disabled (60 mins w/embree vs. 6 mins without). This is in VRay 3.6/2017. Perhaps this is already solved in Next and I'm simply behind the times

The setup is pretty simple: it's about a million particles each with a unique mesh, generated as VRay voxels ("instances"), with a Standard material and a couple of VRay lights. They're not true instances because none of them share a mesh, but I send them dynamically to VRay using the method discussed earlier in this thread so that VRay knows each particle's transform and can therefore render the meshes with proper motion blur.

If I disable embree, or keep it enabled and render the whole thing as a giant combined max mesh the render time is very fast. If I keep embree enabled and also treat each particle as an instance/voxel, the render is extremely slow. Literally 10x slower. And by render time I don't mean the time to generate the voxels, but the actual time to render the buckets.

Is this a known limitation of embree (it doesn't like lots of individual VRay voxels)? Or have I potentially run into a bug? I can send the scene/caches if it's the latter, but perhaps it's the former and I just wasn't aware of the limitation?

[yavor.rubenov]

Hm this doesn't sound OK.
I'd expect the following:
- fastest would be to render as a giant static mesh - of course if it fits in memory
- I'd expect embree with instances to be in second place
- and I'd expect instances and embree OFF to be the slowest

So - if you could send the scene and caches I'll try it here to see if I can find anything wrong. There are indeed changes in Next but 10x is too big of a difference.

[tysonibele]

Hey Yavor,

Here's a stripped down scene file and tyCache. 3dsmax 2017, VRay 3.60.04, tyFlow v0.16057.

Embree (bucket time): 100 seconds

Non-embree (bucket time): 5 seconds

http://www.tysonibele.com/Junk/slowEmbree.zip

[yavor.rubenov]

Thanks for the scene. I reproduced the issue here too and it happens with Next pretty much the same. It seems in this scene the Embree tree for the voxels is pretty bad and we end up intersecting too many voxels without needing to. Intersecting the actual voxels involves some locking and as a result CPU utilization is also very low - causing the long render times. There are some internal parameters for the Embree tree that I'll try and see if there's any change.

Do you get such results in other scenes with many voxels or it is something specific to this one ?

[tysonibele]

This is the only scene of my own I've run into this issue with, so far. However, the issue was also reported by another user in a different scene, so it doesn't seem to be an isolated incident.

My first thought was maybe I wasn't returning tight enough bounds in getVoxelBBox, which would mess with broadphase raycasting....however, checking my code it seems fine...and if my bounds were too large I'd assume that both embree and non-embree rendering would be slow.

[yavor.rubenov]

I did some debugging and profiling on the scene.
As far as I can see there are about 200 000 voxels but each of them has only one triangle right? Both Embree ON and Embree OFF will be very very inefficient for this case - voxels require additional memory, some locking and some more calculations. Doing all this for a single triangle will be very slow.

Additionally Embree has some internal specifics when building separate voxels trees - it does the building in separate threads, allocates lots of additional structures to build the right trees etc.. Those add quite some overhead for a tree with one triangle.
On the other hand - our tree manages to skip a lot of the work for such corner case and is faster.

Overall - is there some way to limit the minimum amount of triangles in a voxel - at least a few thousand triangles ?

[tysonibele]

"Both Embree ON and Embree OFF will be very very inefficient for this case"

Well in this scene (embree off) it renders in 5 seconds on my computer...that's pretty quick even if memory usage is inefficient.

Overall - is there some way to limit the minimum amount of triangles in a voxel - at least a few thousand triangles ?

No, because I need each voxel to have a separate transform...even though no meshes are shared in this case, I still need each individual particle to have proper motion blur. Also these particles being triangles is incidental...in the other scene reported by another user with the same issue, each particle had multiple triangles.

Also, the slowdown only occurs during bucket evaluation...but surely embree will have already built it voxel trees before buckets start rendering right? So I don't understand how that would contribute to the slowdown, even if embree has to do some extra stuff. Seems like the slowdown is caused by a separate inefficiency within embree not related to the initialization. Unless embree builds voxel trees on the fly as buckets evaluate? And even then...10-20x slower seems like it would still warrant some kind of change to fix things....

[yavor.rubenov]

The voxel trees are built the first time a ray hits that voxel - so at render time during bucket evaluation.

[tysonibele]

Ah I see, that makes sense then.