Path Tracing
In 1986, James Kajiya wrote down a single equation that describes how light behaves in any scene.1 The rendering equation says that the light leaving a surface point in some direction is the emitted light plus the integral of all incoming light, weighted by how the surface redirects it. That integral is over the entire hemisphere of directions above the surface — an infinite-dimensional problem that can't be solved analytically for any scene more complex than a mirror in a void. Everything that's happened in physically based rendering since is, in one way or another, an attempt to estimate that integral.
A Taxonomy of Rays
The terminology has gotten muddled over four decades, so it helps to be precise. Alain Galvan lays out the hierarchy cleanly: ray casting is the simplest operation — fire a ray, find the first hit, stop. Ray marching replaces the hit test with iterative stepping, typically using signed distance functions to determine safe step sizes. Ray tracing (Whitted-style, 1980) allows rays to continue recursively past their first hit — reflections and refractions. Path tracing (Kajiya, 1986) adds the full rendering equation: diffuse interreflection, global illumination, physically based material functions.2
Each level subsumes the previous. A path tracer still casts rays, can use marching for collision detection, and handles specular bounces — it just also handles everything else. The grainy, noisy look of an unconverged path tracer is unmistakable: thousands of random rays per pixel gradually converge toward the correct image, with noise decreasing as the square root of the sample count.
How It Works
The core loop is disarmingly simple. For each pixel, shoot a ray into the scene. When it hits a surface, add the emitted light (weighted by accumulated throughput), multiply the throughput by the surface's albedo, then bounce the ray in a random direction weighted by the surface's BRDF. Repeat until the ray escapes the scene or you hit a maximum bounce count.3
The "throughput" concept is key. It tracks how much light the current path is still capable of carrying. A ray that bounces off a red surface has its throughput filtered — subsequent emissive hits contribute red-tinted light. A ray that bounces off a dark surface has most of its throughput absorbed. This multiplicative chain is why path tracing naturally produces colour bleeding, contact shadows, and ambient occlusion without any special-case code. They're all just consequences of solving the rendering equation.
The demofox blog makes an important philosophical point: you can throw out most of the mathematical formalism and still get beautiful results.3 Forget about PDFs and importance sampling for a moment — just bounce rays randomly and accumulate. The images will be noisy and slow to converge, but they'll be correct in the limit. The formalism exists to make convergence faster, not to make the images more correct. This is a liberating insight for anyone intimidated by the math.
The Rendering Equation in 2D
Benedikt Bitterli took the rendering equation and rederived it in two dimensions — not as a simplification but as a tool for understanding.4 In his 2D light transport simulator, "surfaces" become curves, the hemisphere of directions becomes a hemicircle, steradians become radians, and the rendering equation keeps almost exactly the same form. The key difference is subtle and consequential: in 3D, converting from solid angle to spherical coordinates introduces a sine factor in the Jacobian. In 2D, no such factor appears. This missing sine makes many 3D BRDFs (Beckmann, GGX, even Phong) impossible to normalize or sample analytically in 2D.
Bitterli's solution was to use a logistic distribution as a microfacet model — Gaussian-like but integrable — a trick he credits to Brent Burley. The deeper point is that the math of light transport is less universal than it looks. Drop a dimension and normalization constants change, sampling routines break, and you have to rebuild material models from scratch. It's a reminder that the elegant formulations in rendering textbooks encode specific assumptions about 3D geometry that don't transfer automatically.
The 2D simulator also demonstrates something about algorithm design: the "analog" approach of shooting photons and drawing their paths as lines with additive blending is extremely intuitive — it directly simulates the physical process. But it's not optimal. Light tracing can be made arbitrarily worse by moving the light source farther away, and the structured error (line-shaped noise rather than pixel noise) trades away the human visual system's ability to filter white noise. Sometimes the physically intuitive algorithm is the wrong one.
Materials and the BRDF Zoo
The bidirectional reflectance distribution function (BRDF) determines how a surface redirects light. It takes an incoming direction and an outgoing direction and returns a ratio.5 A perfect mirror concentrates all reflection into a single direction. A perfect diffuser (Lambertian) scatters equally in all directions — its BRDF is just a constant: albedo divided by pi (in 3D; divided by 2 in Bitterli's 2D world).
Real materials are more interesting. Microfacet theory models a surface as covered in tiny mirror facets whose orientations follow some statistical distribution — the normal distribution function (NDF). Smooth surfaces have tightly concentrated facet orientations; rough surfaces have broadly distributed ones. The full microfacet BRDF has three terms: the NDF (how many facets point the right way), a geometry term (how many facets are shadowed or masked by neighbours), and a Fresnel term (how much light reflects vs. refracts at each facet).5
The Fresnel effect deserves special attention because it's so visually important. All materials become more reflective at grazing angles — look across a lake and it's a mirror; look straight down and you can see the bottom. The Schlick approximation captures this with a simple power-of-five falloff from the base reflectance to full reflection. Metals and dielectrics differ fundamentally here: dielectrics have low base reflectance (~0.04) and get their colour from subsurface scattering of the refracted light, while metals absorb all refracted light and get their colour from wavelength-dependent reflection.5
Google's Filament documentation goes further, showing how the metallic/roughness parameterisation maps to physically measured materials.6 The specular colour of a metal can be computed from complex index of refraction data — measured spectral samples multiplied by CIE colour matching functions and the D65 illuminant spectrum, integrated and converted to sRGB. Gold falls out of gamut and needs normalisation. The cloth BRDF uses a different model entirely — Ashikhmin's inverted Gaussian rather than GGX — because fabric scatters light through fibres rather than off microfacets. These aren't academic distinctions: the wrong material model for velvet produces something that looks like plastic, not cloth. Filament achieves near-reference-quality rendering at 60fps on a mobile Tegra K1 by choosing the right simplifications for each material class rather than brute-forcing a single general model.6
Making It Fast
Naive path tracing converges slowly because most random rays don't find useful light. The field of variance reduction is vast, but a few techniques matter most:
Importance sampling biases ray directions toward where the BRDF is large — for a glossy surface, concentrate samples near the reflection direction instead of scattering them uniformly. The mathematical correction (dividing by the PDF of the sampling distribution) keeps the estimate unbiased while dramatically reducing noise.
Multiple importance sampling (MIS) combines samples from different strategies — sample the BRDF and sample the light sources, then weight each strategy by how well it matches the actual integrand. Veach's 1998 thesis formalised this and it remains the backbone of modern production renderers.2
Next event estimation (NEE) shoots a shadow ray directly toward a light source at each bounce. If the path to the light is unoccluded, you can add its contribution immediately rather than hoping a random bounce eventually finds it. Russian roulette probabilistically terminates dim paths, concentrating computation on paths that carry significant energy.
Andrew Kensler's postcard-sized path tracer packs many of these ideas into 2037 bytes of C++: cosine-weighted hemisphere sampling for diffuse bounces, direct light evaluation with shadow rays, Reinhard tone mapping, and a complete SDF-based scene — all obfuscated to fit on the back of a Pixar recruitment flier.7 Fabien Sanglard's reverse-engineering of the code is one of the best walkthroughs of a minimal path tracer in existence.
Vertex Connection and Merging
Bidirectional path tracing (BPT) and photon mapping (PM) were both introduced in the 1990s and solved complementary problems — BPT handles scenes where light takes unlikely paths to the camera (strong indirect lighting, small light sources), while PM handles caustics through path reuse (one photon traced through a glass sphere can contribute to many camera rays). But neither displaced unidirectional path tracing in production because each had crippling weaknesses: BPT's memory footprint and ray incoherence killed cache performance, and PM's density estimation was biased and converged slowly on diffuse surfaces.8
Georgiev et al.'s Vertex Connection and Merging (VCM, 2012) unified both techniques in a single MIS framework. The idea: trace light paths and store their hit points in a spatial data structure (as in photon mapping), then trace camera paths and at each hit point both connect to light vertices (as in BPT) and merge with nearby stored light vertices (as in PM). The mathematical contribution was reformulating the merge step — which is fundamentally a density estimation — into something compatible with Veach's MIS weight calculation. This lets the algorithm automatically choose the best strategy at each path vertex: direct connections for diffuse surfaces, merging for caustics, and all the intermediate cases weighted by how well each technique matches the local geometry.8
The recursive weight formulation is the practical breakthrough. A naive MIS weight calculation would require iterating over every possible way a path could have been constructed — every vertex as a potential connection or merge point — which would be prohibitively expensive. Georgiev showed that three running values (dVCM, dVC, dVM), updated incrementally as each new vertex is added to a path, are sufficient to compute the exact MIS weight for any connection or merge. Each value is a partial term built from the ratio of forward and reverse area PDFs at each vertex. This turns what would be an O(n²) computation per path into O(n), making VCM practical for production.8
The Differentiable Future
Path tracing is increasingly being run backwards — not from camera to light, but from a loss function to scene parameters. Differentiable rendering propagates gradients through the light transport simulation, enabling optimization of geometry, materials, and lighting to match a target image. This is the foundation of inverse rendering and neural radiance fields, and it requires that every operation in the rendering pipeline — ray intersection, BRDF evaluation, sampling — has a well-defined derivative. The rendering equation isn't just a description of physics; it's becoming a differentiable program.
Footnotes
-
The Rendering Equation by James Kajiya, SIGGRAPH 1986 — source ↩
-
Physically Based Rendering by Wolfram Research — source ↩ ↩2 ↩3
-
Physically Based Rendering in Filament by Google — source ↩ ↩2
-
Deciphering the Postcard Sized PathTracer by Fabien Sanglard — source ↩
-
Vertex Connection and Merging by Joe Schutte — source ↩ ↩2 ↩3
Linked from
- Color Science
Every 3D renderer does this already — path tracing operates in linear space by necessity, because light transport equations assume linear superposition.
- Demoscene
The renderer is a legitimate path tracer: cosine-weighted hemisphere sampling for diffuse bounces, direct light evaluation with shadow rays, specular reflection on the letter surfaces.
- Demoscene
The rendering equation was published in 1986.
- Gpu Pipeline Architecture
It exists because the GPU needs to compute screen-space derivatives for texture filtering — how fast UV coordinates change between adjacent pixels determines which mipmap level to sample. Helper invocations (pixels in the quad that fall outside the t…
- Graphics And Rendering Overview
Path Tracing is the mathematically complete approach: solve the rendering equation by shooting rays, bouncing them randomly, and accumulating.
- Physically Based Rendering
Path tracing gives the correct answer but remains too expensive for most real-time applications.
- Shader Programming
Path tracing is naturally divergent — every bounce can send rays to different materials — which is why real-time path tracers are hard even on hardware with enormous theoretical throughput.
- Shader Programming
Path tracing gave us physically based images.
- Volumetric Rendering
But the gap between film and game volumetrics remains one of the widest in graphics: where Path Tracing of surfaces has become real-time (via hardware RT cores), path-tracing of volumes is still orders of magnitude too expensive for 60fps rendering.