Graphics, the Right Way

Raytracing, the Right Way

by Ian Mallett

"Rasterization isn't dead, but it will be."
"Friends don't let friends do path tracing."

Introduction, Motivation, and Physically-Correct Rendering

Raytracing, and particularly ELS pathtracing (a form thereof), are widely-used algorithms for producing photorealistic images. It is now universal in high-quality visual effects, and raytracing techniques have crept into games over the past decade. Pathtracing in realtime is possible, and with the advent of NVIDIA RTX, even practical.

The ELS pathtracing algorithm requires only a superficial understanding of light transport—and this unfortunately usually leads to it being taught in a misleading and inaccurate way. This has caused an astonishing lack of knowledge that leads, if nothing else, to suboptimal algorithms.

For example, we all know that light is made out of photons with particular wavelengths. So-called "spectral" renderers take this into account, tracing one wavelength at a time into a binned representation of the spectrum. Spectral renderers aren't used in production because they are slow (instead, they trace "red", "green", and "blue"—whatever those mean—and do complex and inaccurate adjustments to make up for the imprecision).

Instead, with just a tiny bit of rendering theory, we make a spectral renderer that doesn't use binning, and therefore has none of the quantization error. Furthermore, this renderer will actually reach convergence faster than an ordinary RGB renderer! There is, in-fact, no good reason to be using RGB rendering for physically-correct rendering in the present day.

That term—"physically-correct"—is my appellation for what the better-known term "physically-based" should have been: a description of a renderer that produces the same answer that nature does (up to the ray-optics approximation). We need a new term because the term "physically-based" is a buzzword that doesn't mean anything anymore.

To demonstrate: in the film industry, they'll go out on set and capture an environment map with an LDR camera, scale the resulting sRGB pixels by 100 to make it "HDR", render their CGI stuff with a non-spectral, ELS pathtracer that also throws out LS+DE paths, composite the result in with alpha blending, tonemap it back to LDR with some local "perceptual" sigmoid curve, and then rotate all their colors to a blue/orange color palette, and hallucinate the contrast for the final frame because that's what the art director wanted.

Then, they go give presentations at SIGGRAPH wherein they'll have the audacity to call that procedure "physically-based"! While some of the ingredients in that pipeline came from or are based on reality, the end result is not physical—not in any meaningful sense. You might as well call sugar and cyanide the same thing, just because they both have carbon in them.

Like cyanide, the tiniest amount of nonphysicality will poison the validity of a physically-correct renderer. It is quite common, especially when shipping a video game during crunch time, that your render will be off, say, by a factor of π or something. Now your pipeline isn't physically-correct! You can't use this for predictive rendering, and even if you can't pinpoint the reason, the human eye will perceive it as subtly wrong.

Worse, the workarounds you make to combat these errors tend to compound with each other. Say you multiply another π in somewhere to compensate—except it's in the wrong place, so now your scene has the right brightness overall, but diffuse indirect lighting is too dark and you're getting weird convergence issues on tertiary bounces. You don't even consciously notice the former, and you try to correct the latter with firefly clamping. Now your renderer doesn't handle glass right and your antialiasing is somehow darkening your scene? So you clamp your antialiasing too, but now your temporal filter is returning negative values? Maybe adjust the tonemapping curve and hope?

It is my belief that this is the wrong approach. There is no technical reason why renderers, both offline and realtime, cannot be physically correct, and we should strive to make them so. It isn't actually (much) harder than doing it the usual way, and better yet, the procedures you're doing make sense. Moreover, the results speak for themselves. I'd like to show you how to do this.