- User Since
- Mar 31 2015, 9:29 AM (168 w, 2 d)
Tue, Jun 19
Tue, Jun 5
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
Mon, May 28
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.
Apr 24 2018
Apr 12 2018
Apr 4 2018
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.
Mar 20 2018
Mar 17 2018
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.
Mar 16 2018
Could this be similar to T53854? When I change the two occurrences of
Mar 14 2018
Feb 19 2018
May or may not be related to T53914.
Feb 1 2018
Jan 31 2018
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.
Jan 30 2018
I see what you mean.
Jan 27 2018
Jan 22 2018
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.
Dec 13 2017
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.
Dec 4 2017
Dec 2 2017
- Cycles: Changed object properties offset to match new data structure size
Dec 1 2017
Nov 29 2017
Nov 28 2017
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