[xwintermutex]

> As the linked article mentions, the solution was to optimize a massively-parallel algorithm by finding coherent rays that can be efficiently calculated together. It's a batch method: start casting a bunch of rays, identify similar rays and group them, calculate collisions for each group, cast reflected rays, identify similar rays and group them, etc. What I like about it conceptually is that in a way it treats light as a field rather than as individual directed rays.

How does this differ from "coherent ray tracing" and "ray packets", like people have been doing the last 15 years?

(e.g. "Interactive Rendering with Coherent Ray-Tracing" by Wald et al.: http://www.sci.utah.edu/~wald/Publications/2001/CRT/CRT.pdf)

[tomvbussel]

They're generating millions of rays to trace them at the same time, so they should be able to use packet tracing and they seem to use that [1]. Incoherent rays can be extremely troublesome when tracing packets, as you could be entering a branch of the BVH for just a few rays in the packets and in that case you're wasting a large part of the SIMD vector. There has been some research to alleviate that [2, 3] and creating more cohorent batches alleviates it even more. One of the other big problems of packet tracing is that there is no good way to handle motion blur, but if they're generating millions of rays at once they can just create packets with rays that are all in the same time interval.

[1] https://disney-animation.s3.amazonaws.com/uploads/production...

[2] http://www.sci.utah.edu/~wald/Publications/2011/singleray_hy...

[3] http://fileadmin.cs.lth.se/graphics/research/papers/2014/drs...

[couchand]

I've already gone beyond my understanding of the technical details. The paper probably goes into it (linked in the sibling), and it also looks like it cites Wald.

Just noticed it also has the proof-of-concept city scene I mentioned on the last page.