Shadow Mapping and the Depth-Buffer Trick for Real-Time Shadows
Shadow mapping renders the scene from a light's viewpoint, stores the nearest depth, and compares that map during normal rendering. The simple depth-buffer idea became a foundation of real-time shadow rendering.
Shadows are a visibility problem viewed from the light
To decide whether a visible point is illuminated by a point or directional light, a renderer must determine whether another surface blocks the path between that point and the light. Lance Williams’ 1978 paper “Casting Curved Shadows on Curved Surfaces” reframed this as a familiar graphics operation: render visible surfaces from the light’s viewpoint, store their depths, then reuse those depths when rendering the camera image.[1] The method was attractive because it borrowed the ordinary Z-buffer idea instead of requiring special geometric shadow volumes for every object.
A depth map is the light’s memory of what it can see
For each direction represented in the map, the stored value is the nearest surface to the light. Anything farther along the same projected ray is occluded.
The algorithm renders the scene twice
In the first pass, the camera is conceptually placed at the light. The renderer records depth rather than final color. In the second pass, each camera-visible point is transformed into the light’s coordinate system and compared with the stored depth at the corresponding shadow-map location. If the point is farther from the light than the stored surface, it lies in shadow. Williams emphasized that the method can work wherever visible surfaces can already be computed and that it does not require adding new geometric entities to the scene.[1]
Reusing the depth buffer made shadow mapping compatible with raster hardware
The method’s historical power came from composability. Graphics systems already needed depth comparison to determine which surface is visible to the camera. Shadow mapping applies essentially the same mechanism from another viewpoint. As GPUs became optimized around rasterization, depth buffers, texture memory, and matrix transforms, shadow maps fit naturally into the pipeline. This is one reason the technique migrated from offline rendering into interactive graphics and games.
Image-space methods trade geometric exactness for bounded work
The map has finite resolution, so the cost is controlled by the number of depth samples rather than directly by the geometric complexity of every shadow boundary.
Finite resolution creates aliasing and self-shadowing artifacts
The depth map samples the light’s view on a grid. When that grid is projected onto camera-visible geometry, one texel can cover many screen pixels, creating jagged shadow edges. Small numerical differences can also cause a surface to compare against its own stored depth and incorrectly shadow itself, producing “shadow acne.” A major survey of real-time hard shadow mapping classifies these sampling and precision problems and documents the large family of techniques developed to reduce them.[4] Bias terms, higher resolution, warped projections, and multiple maps all try to make the limited samples better match the final image.
Percentage-closer filtering made depth comparisons filterable
Ordinary color texture filtering averages sample values, but averaging depth values before comparison does not produce the correct fraction of visible light. Reeves, Salesin, and Cook introduced percentage-closer filtering in 1987: perform several depth comparisons around the projected point and average the binary visibility results instead.[2] This antialiases shadow boundaries and can create a soft-edged appearance. PCF later became a standard capability in graphics hardware and APIs because it fits the shadow-map representation while addressing one of its most obvious artifacts.
Filtering visibility differs from filtering depth
The key operation is asking how many nearby samples say “lit,” not simply blending their stored distances into one meaningless intermediate depth.
Variance shadow maps changed the stored statistics to enable ordinary filtering
Donnelly and Lauritzen proposed variance shadow maps in 2006, storing depth moments rather than only a single nearest depth.[3] From the mean and squared mean, the renderer estimates a bound on the probability that the receiver is visible. Because these statistics can be linearly filtered, the technique works with standard texture filtering and supports large filter kernels efficiently. The tradeoff is different artifact behavior, including light bleeding, illustrating a recurring graphics pattern: changing the representation can make one class of operations cheap while introducing new approximation errors.
Large scenes led to multiple maps and split view volumes
A single fixed-resolution map struggles when one camera view spans both nearby detailed geometry and distant terrain. Parallel-split and cascaded shadow-map techniques divide the camera frustum into depth ranges and assign a separate map to each range. GPU Gems documents this family as a practical real-time response to aliasing in large environments.[5] Near ranges receive dense effective resolution while far ranges use their maps over larger areas. Modern game engines commonly use related cascaded techniques for sunlight and other large directional lights.
Shadow quality became a resource-allocation problem
The engine decides where limited depth samples matter most, how often maps update, and which lights deserve separate passes. Shadows became part of frame-budget scheduling as well as illumination.
Why shadow mapping belongs in the history of real-time graphics
Shadow mapping belongs in graphics history because Williams found a reusable image-space trick for a difficult geometric visibility problem. The same raster machinery used for ordinary depth could generate a light-space visibility map, and later researchers extended the representation with filtering, moments, and view partitioning.[1][2][3] The basic two-pass concept remains recognizable in modern engines.
The technique also demonstrates why some graphics algorithms endure. Shadow maps are not exact, and their artifacts are well understood. Yet they map efficiently onto GPUs, support arbitrary geometry, and allow quality to scale with memory and sampling effort. That combination of generality, speed, and controllable approximation made a 1978 idea one of the central tools of real-time lighting.
Works Cited
- 01
- 02
- 03
- 04
- 05NVIDIA GPU Gems 3 — Parallel-Split Shadow Maps on Programmable GPUs developer.nvidia.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead