Disney's Practical Guide to Path Tracing [video]

You are right though that it would be fascinating to see the speed difference. My guess is that it would be substantial.

Even compiling PBRT with Intel C++ instead of Microsoft's C++ compiler gives a %30 - %50 speedup, likely due to reordering instructions for better memory coherency on a granular level (batching rays would give better memory coherency on a very broad level).

Ptex really chokes with non-coherant texture accesses (partly due to the anisotropic filtering method it uses) in terms of thread scalability, so Disney have gone to great lengths to get around this issue. Doing such accurate texture filtering (the same goes for standard UV EWA filtering) is technically better, but is expensive, especially in a path-tracing context, where the whole point is to amortise the cost of shading over all the rays by making each intersection / shading calculation as cheap as possible.

From what I hear there are big downsides to this current implementation: the streaming of batches is pretty much off-line, so time till "first pixel" is significant, and thus you don't get interactive rendering functionality.

The big thing they were trying to get at is there are some clever tricks we can do to make these massive calculations more efficient.

They're probably alluding to Disney's Hyperion renderer[1]. Sorting rays helps with cache coherency.

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

If the surface is refractive/reflective, recursively shoot one more ray calculating the right direction, with correctly diminished intensity and follow the same process.

Keep in mind that there is a very mathematical foundation to all this, we're not just tracing paths for the fun of it. Basically what we want to solve is a path integral (an integral over all paths), we do this using a technique called Monte Carlo integration (which basically means we use randomness). We first sample a path (using path tracing) and then we calculate the contribution of that path (which basically is the amount of radiance is carries divided by the probability of sampling the path) and then we add that contribution to the right pixel.

Lots of caveats here, of course. You do need to also sample light going in other directions, since the sun isn't the only light source (other objects reflect). You can only do this on diffuse surfaces, so you need to keep going until you hit a diffuse surfaces. Most surfaces are partly diffuse partly specular, etc. so you'll actually want to sample both straight towards the light source and off in other angles.

But what does the most simple path tracer look like? You shoot rays from the camera. If it hits a diffuse surface, bounce a ray toward each light, adding that light if that ray isn't obstructed from the light. If it hits a specular surface, bounce off based on the surface and ray orientations, and recurse when you hit another surface. You see how we cheat? If everything is diffuse, then we only ever make one bounce, straight from us to the sun. But that's a great first order approximation, since sunlight is so much brighter than reflected light. Same approach works for more bounces; just end with it trying to hit the sun.