The source of the problem is the use of ray_offset() to prevent self-intersections for rays that originate from a transparent surface. A solution to this problem is outlined in the paper "Robust Iterative Find-Next-Hit Ray Traversal": http://www.sci.utah.edu/~wald/Publications/2018/nexthit-pgv18.pdf

The root cause is that PathState.volume_stack is a fixed size array and kernel_volume_stack_init() does not perform any bounds checking when writing to that array.

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