A possible remedy would be to gather all volume intersections in one go (similar to intersect_shadow_all) and do the ray marching in a single step. There are hints that Arnold is using such a method in " Importance Sampling Techniques for Path Tracing in Participating Media", section 6.

That alone isn't a stable fix though, since this uses extra dimensions in the RNG that aren't taken into account at setup time, potentially causing out of bounds crashes reading from the sobol table.

Could this be similar to T53854? When I change the two occurrences of

May or may not be related to T53914.

That sounds like a good approach. I suspect that in general, transparent intersections can lead to incorrect path termination. Note how for example how an environment light with diffuse bounces = 0 will not provide direct illumination through transparency. Volume emission currently also provides direct light to surfaces inside the volume's bounds, but not to surfaces outside of the volume's bounds.

I see what you mean.

Thanks, that was quick.
You're right, D2766 only made the issue more visible - it was present in earlier revisions as well when the min transparency parameter was set low enough.

It looks like this happens with plain transparency too - branched path tracing and plain path tracing give different results. See the attached scene.

It is strange, it fails the unit tests because of different noise patterns, but appears to converge to the same result. I'll do some more investigating to find out where things take a different path.

• Cycles: Changed object properties offset to match new data structure size

Yes, Embree is a new dependency. For best results, you should use a patched version of Embree that (like Cycles) ignores ray/ribbon intersections when the ray origin is inside the ribbon. My patched version can be found here: https://github.com/skwerner/embree/tree/cycles_compatible

Even more so, we could use this for the on-demand kernel compilation in device_cuda.cpp. Since it is possible to load PTX directly from the CUDA runtime (with the driver taking over the ptxas step), this should enable on-demand compilation on any operating system without any dependencies other than the CUDA driver.

Since CUEW wraps NVRTC, it could also be an option to use NVRTC directly instead of trying to find and launch nvcc from the command line. That way, this feature would be independent of a 3rd party compiler tool chain and would have less platform-dependent code.

Is there anything holding up a commit? I have a few extensions to this patch to make it work on my system. I see that here the CUDA installer set an environment variable where we can grab the Toolkit location from on Windows. Since it defaults to "C:\Program Files\etc" it also needs slight changes to have quotation marks in the right places to deal with the spaces in the path.

Thanks for your work, this is looking good! Especially the addition for sharing memory with CPU devices is good.