Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering

Published on-line at developer.nvidia.com

Practical and Robust Stenciled Shadow Volumes for
Hardware-Accelerated Rendering
Cass Everitt and Mark J. Kilgard
March 12, 2002
NVIDIA Corporation, Copyright 2002
Austin, Texas
ABSTRACT
Twenty-five years ago, Crow published the shadow volume
approach for determining shadowed regions in a scene. A decade
ago, Heidmann described a hardware-accelerated stencil buffer-
based shadow volume algorithm.
However, hardware-accelerated stenciled shadow volume
techniques have not been widely adopted by 3D games and
applications due in large part to the lack of robustness of
described techniques. This situation persists despite widely
available hardware support. Specifically what has been lacking is
a technique that robustly handles various "hard" situations created • Shadow volumes automatically handle self-shadowing of
by near or far plane clipping of shadow volumes. objects if implemented correctly.
We describe a robust, artifact-free technique for hardware-
• Shadow volumes perform shadow determination in window
accelerated rendering of stenciled shadow volumes. Assuming
space, resolving shadow boundaries with pixel accuracy (or
existing hardware, we resolve the issues otherwise caused by
sub-pixel accuracy when multisampling is available).
shadow volume near and far plane clipping through a combination
of (1) placing the conventional far clip plane “at infinity”, (2) • Lastly, the fundamental stencil testing functionality required
rasterization with infinite shadow volume polygons via for hardware-accelerated stenciled shadow volumes is now
homogeneous coordinates, and (3) adopting a zfail stencil-testing ubiquitous due to the functionality’s standardization by
scheme. Depth clamping, a new rasterization feature provided by OpenGL 1.0 (1991) and DirectX 6 (1998) respectively. It is
NVIDIA's GeForce3 & GeForce4 Ti GPUs, preserves existing near impossible to purchase a new PC in 2002 without
depth precision by not requiring the far plane to be placed at stencil testing hardware.
infinity. We also propose two-sided stencil testing to improve the Stenciled shadow volumes have their limitations too. Shadow
efficiency of rendering stenciled shadow volumes. volumes model ideal light sources so the resulting shadow
Keywords boundaries lack soft edges. Shadow volume techniques require
polygonal models. Unless specially handled, such polygonal
Shadow volumes, stencil testing, hardware rendering. models must be closed (2-manifold) and be free of non-planar
polygons. Silhouette computations for dynamic scenes can prove
1. INTRODUCTION expensive. Stenciled shadow volume algorithms are inherently
Crow’s shadow volume approach [10] to shadow determination is multi-pass. Rendering shadow volumes can consume tremendous
twenty-five years old. A shadow volume defines a region of space amounts of pixel fill rate.
that is in the shadow of a particular occluder given a particular
ideal light source. The shadow test determines if a given point 2. PREVIOUS WORK
being tested is inside the shadow volume of any occluder.
Hardware stencil testing provides fast hardware acceleration for 2.1 Pre-Stencil Testing Work
shadow determination using shadow volumes. Despite the Crow [10] first published the shadow volume approach in 1977.
relative age of the shadow volume approach and the widespread Crow recognizes that the front- or back-facing orientations of
availability of stencil-capable graphics hardware, use of shadow consistently rendered shadow volume polygons with respect to the
volumes in 3D games and applications is rare. viewer indicate enters into and exits out of shadowed regions.
Crow also recognizes that some care must be taken to determine if
We believe this situation is due to the lack of a practical and the viewer’s eye point is within a shadow volume.
robust algorithm for rendering stenciled shadow volumes. We
propose here an algorithm to address this gap. Our algorithm is Crow’s formulation fundamentally involves walking a pixel’s
practical because it requires only features available in OpenGL view ray originating at the eye point and counting the number of
1.0. The algorithm is robust because shadow volume scenarios shadow volume enters and exits encountered prior to the first
that vexed previous algorithms, such as a light within an open visible rasterized fragment.
container, are handled automatically and correctly. Brotman and Badler [8] in 1984 adapted Crow’s shadow volume
We focus on robustly solving the problem of hardware- approach to a software-based, depth-buffered, tiled renderer with
accelerated stenciled shadow volume rendering for a number of deferred shading and support for soft shadows through numerous
reasons, many noted by other authors [9][10][11][19]: light sources all casting shadow volumes.
• Shadow volumes provide omni-directional shadows. Pixel-Planes [13] in 1985 provides hardware support for shadow
volume evaluation. In contrast to Crow’s original ray walking

1

Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering

approach, the Pixel-Planes algorithm relies on determining if a note (as have other authors [5][15]) that the shadow volume
pixel is within an infinite polyhedron defined by a single occluder polygons can be rendered in two passes: first, culling back-facing
triangle plane and its three shadow volume planes. This polygons to increment pixels rasterized by front-facing polygons;
determination is made for every pixel and for every occluder second, culling front-facing polygons to decrement pixels
polygon in the scene. Each “point within a volume” test is rasterized by back-facing polygons. This leverages the graphics
computed by evaluating the corresponding set of plane equations. hardware’s ability to make the face culling determination
Pixel-Planes is a unique architecture because the area of a automatically and minimizes hardware state changes at the cost of
rasterized triangle in pixels does not affect the triangle’s rendering the shadow volume polygons twice. Utilizing the
rasterization time. Otherwise, the algorithm’s evaluation of every hardware’s face culling also avoids inconsistencies if the CPU and
per-triangle shadow volume plane equation at every pixel would graphics hardware determine a polygon’s orientation differently in
be terribly inefficient. razor’s edge cases.

Bergeron [3] in 1986 generalizes Crow’s original shadow volume After the shadow volume polygons are rendered into the scene, a
approach. Bergeron explains how to handle open models and pixel’s stencil value is equal to zero if the light illuminates the
models containing non-planar polygons properly. Bergeron pixel and greater than zero if the pixel is shadowed. The scene
explicitly notes the need to close shadow volumes so that a correct can then be re-rendered with the appropriate light configured and
initial count of how many shadow volumes the eye is within can enabled, with stencil testing enabled to update only pixels with a
be computed. zero stencil value (meaning the pixel is not shadowed), and
“depth equal” depth testing (to update only visible fragments).
Fournier and Fussell [12] in 1988 discuss shadow volumes in the The light’s contribution can be accumulated with either the
context of frame buffer computations. In their computational accumulation buffer or additive blending.
model, each pixel in a frame buffer maintains a depth value and
shadow depth count. Fournier and Fussell’s frame buffer This can be repeated for multiple light sources, clearing the stencil
computation model lays the theoretical foundations for buffer between rendering the shadow volumes and summing the
subsequent hardware stencil buffer-based algorithms. contribution of each light.
2.2.2 Near and Far Plane Clipping and Capping
2.2 Stencil Testing-Based Work Heidmann fails to mention in his article a problem that seriously
2.2.1 The Original Approach undermines the robustness of his approach. With arbitrary scenes,
Heidmann [14] in 1991 describes an algorithm for using the then- the near and/or far clip planes may (and, in fact, often will) clip
new stencil buffer support of SGI’s VGX graphics hardware [1]. the infinite shadow volumes. Each shadow volume is, by
Heidmann recognizes the problem of stencil buffer overflows and construction, a half-space (dividing the entirety of space into the
demonstrates combining contributions from multiple light sources region shadowed by a given occluder and everything else).
with the accumulation buffer to simulate soft shadows. However, near and far plane clipping can “slice open” an
Heidmann’s approach is a multi-pass rendering algorithm. First, otherwise well-defined half space. Disturbing the shadow volume
the color, depth, and stencil buffers are cleared. Second, the in this way leads to incorrect shadow depth counting that, in turn,
scene is drawn with only ambient and emissive lighting results in glaringly incorrect shadowing.
contributions and using depth testing for visibility determination. Diefenbach [11] in 1996 recognized the problem created by near
Now the color and depth buffers contain the color and depth plane clipping for shadow volume rendering. Diefenbach presents
values for the closest fragment rendered at each pixel. Then a method that he claims works “for any shadow volume geometry
shadow volume polygons are rendered into the scene but just from any viewpoint,” but the method, in fact, does not work in
updating stencil. several cases. Figure 1 illustrates three cases where Diefenbach’s
Front-facing polygons update the frame buffer with the following method fails.
OpenGL per-fragment operations (for brevity, we drop the gl and Another solution to the shadow volume near plane clipping
GL prefixes for OpenGL commands and tokens): problem mentioned by Diefenbach is capping off the shadow
Enable(CULL_FACE); // Face culling enabled volume’s intersection with the near clip plane. Other authors
CullFace(BACK); // to eliminate back faces [2][4][9][16][17] have also suggested this approach. The
ColorMask(0,0,0,0); // Disable color buffer writes problem with near plane capping of shadow volumes is that it is,
DepthMask(0); // Disable depth buffer writes as described by Carmack [9], a “fragile” procedure.
StencilMask(~0); // Enable stencil writes Capping involves projecting each occluder’s back-facing
Enable(DEPTH_TEST); // Depth test enabled polygons to the near clip plane. This can be complicated when
DepthFunc(LEQUAL); // less than or equal only one or two of a projected polygon’s vertices intersect the
Enable(STENCIL_TEST); // Stencil test enabled near plane and careful plane-plane intersection computations are
StencilFunc(ALWAYS,0,~0) // always pass required in such cases. The capping process is further
StencilOp(KEEP,KEEP,INCR); // increment on zpass complicated when a back-facing occluder polygon straddles the
Similarly, back-facing polygons update the frame buffer with the near clip plane.
following OpenGL state modifications:
CullFace(FRONT); // Now eliminate front faces Rendering capping polygons at the near clip plane is difficult
StencilOp(KEEP,KEEP,DECR); // Now decrement on zpass because of the razor’s edge nature of the near clip plane. If you
Heidmann’s described algorithm computes the front- or back- are not careful, the very near plane you are attempting to cap can
facing orientation of shadow volume polygons on the CPU. We clip your capping polygons! Additionally if the capping polygons

2


StencilOp(KEEP,INCR,KEEP); // increment on zfail
What Carmack describes is projecting back faces, with respect to
the light source, some large but finite distance (importantly, still
within the far clip plane) and also treating the front faces of the
occluder, again with respect to the light source, as a part of the
shadow volume boundary too. This still has a problem because
when a light source is arbitrarily close to a single occluder
N ear F ar N ear F ar N ea r F ar polygon, any finite distance used to project out the back faces of
p lan e p la ne p lan e p lan e p lan e p lan e
the occluder to close off the shadow volume may not extend far
enough to ensure that objects beyond the occluder are properly
Figure 1: Three cases where Deifenbach’s capping algorithm shadowed.
fails because some or all pixels requiring capping are covered
Still Carmack’s insight is fundamental to our new algorithm. We
by neither a front-nor back-facing polygon so Diefenbach’s
call Bilodeau and Carmack’s approach zfail stenciled shadow
approach cannot correct these pixels.
volume rendering because the stencil increment and decrement
are not “watertight” (2-manifold) with the shadow volume being operations occur when the depth test fails rather than when it
capped then rasterization cracks or double hitting of pixels can passes. We call the conventional approach zpass rendering.
create shadowing artifacts. These artifacts appear as exceedingly
One way to think of the zfail formulation, in contrast to the zpass
narrow regions of the final scene where areas that clearly should
formulation, is that the zfail version counts shadow volume
be illuminated are shadowed and vice versa. These artifacts are
intersections from the opposite direction. The zpass formulation
painfully obvious in animated scenes.
counts shadow volume enters and exits along each pixel’s view
Watertight capping is non-trivial, particularly if shadow volumes ray between the eye point and the first visible rasterized fragment.
are drawn using object-space geometry so that fast dedicated Technically due to near plane clipping, the counting occurs only
vertex transformation hardware can be exploited. Kilgard [16] between the ray’s intersection point with the near clip plane and
proposes creating a “near plane ledge” whereby closed capping the first visible rasterized fragment. The objective of shadow
polygons can be rendered in a way that avoids clipping by the volume capping is to introduce sufficient shadow volume enters
near clip plane even when rendering object-space shadow volume so that the eye can always be considered “out of shadow” so the
geometry. This approach cedes a small amount of depth buffer stencil count can reflect the true absolute shadow depth of the first
precision for the ledge. Additionally shadow volume capping visible rasterized fragment.
polygons must be rendered twice, incrementing front-faces and
The zfail formulation instead counts shadow volume enters and
decrementing back-facing geometry because the orientation
exits along each pixel’s view ray between infinity and the first
(front- or back-facing) of a polygon can occasionally flip when a
visible rasterized fragment. Technically due to far plane clipping,
polygon of nearly zero area in window space is transformed from
the counting occurs only between the ray’s intersection with the
object space to window space due to floating-point numerics.
far plane and the first visible fragment. By capping the open end
Otherwise, shadow artifacts result.
of the shadow volume at or before the far clip plane, we can force
Even when done carefully, shadow volume near plane capping is the idea that infinity is always outside of the shadow volume.
treacherous because of the fragile nature of required ray-plane
intersections and the inability to guarantee identical and bit-exact 3. OUR ALGORITHM
CPU and GPU floating-point computations. In any case, capping
computations burden the CPU with an expensive task that our
3.1 Requirements
For our algorithm to operate robustly, we require the following:
algorithm obviates.
• Models for occluding objects must be composed of triangles
2.2.3 Zpass vs. Zfail Stenciled Shadow Volumes only (avoiding non-planar polygons), be closed (2-manifold),
The conventional stenciled shadow volume formulation is to and have a consistent winding order for triangles within the
increment and decrement the shadow depth count for front- and model. Homogeneous object coordinates are permitted,
back-facing polygons respectively when the depth test passes. assuming w≥0.
Bilodeau [5] in 1999 noted that reversing the depth comparison • Light sources must be ideal points. Homogeneous light
works too. Another version of this alternative formulation is to positions (w≥0) allow both positional and directional lights.
decrement and increment the shadow depth count for front- and
back-facing polygons respectively depth test fails (without • Connectivity information for occluding models must be
reversing the comparison). available so that silhouette edges with respect to a light
position can be determined at shadow volume construction
Carmack [9] in 2000 realized the equivalence of the two time.
formulations because they both achieve the same result, if in the
• The projection matrix must be perspective, not orthographic.
“depth test fail” formulation, the shadow volume is “closed off” at
both ends (rather than being open at the ends). Compare the • Functionality available in OpenGL 1.0 [18] and DirectX 6:
following OpenGL rendering state modifications with the settings transformation and clipping of homogeneous positions; front
for conventional shadow volume rendering in section 2.2.1. and back face culling; masking color and depth buffer writes;
depth buffering; and stencil-testing support.
Front-facing shadow volume rendering configuration:
• The renderer must support N bits of stencil buffer precision,
StencilOp(KEEP,DECR,KEEP); // decrement on zfail
where 2N is greater than the maximum shadow depth count
Back-facing configuration: ever encountered during the processing of a given scene.

3


This requirement is scene dependent, but 8 bits of stencil We consider the limit of P as the far clip plane distance is driven
buffer precision (typical for most hardware today) is to infinity (this is not novel; Blinn [7] mentions the idea):
reasonable for typical scenes. Right + Left
 2 × Near 
• The renderer must guarantee “watertight” rasterization (no  Right − Left 0 0 
Right − Left
double hitting of pixels or missed pixels along shared edges  
2 × Near Top + Bottom
lim P = Pinf = 0 0 
of rasterized triangles). f →∞  Top − Bottom Top − Bottom 
 0 0 −1 − 2 × Near 
Support for non-planar polygons and open models can be  
achieved using special case handling along the lines described by 
 0 0 −1 0 

Bergeron [3].
The first, second, and fourth rows of Pinf are the same as P; only
3.2 Approach the third row changes. There is no longer a Far distance.
We developed our algorithm by methodically addressing the A vertex that is an infinite distance from the viewer is represented
fundamental limitations of the conventional stenciled shadow in homogeneous coordinates with a zero we coordinate. If the
volume approach. We combine (1) placing the conventional far vertex is transformed into clip space using Pinf, assuming the
clip plane “at infinity”; (2) rasterizing infinite (but fully closed) vertex is in front of the eye, meaning that ze is negative (the
shadow volume polygons via homogeneous coordinates; and (3) OpenGL convention), then wc=zc so this transformed vertex is not
adopting the zfail stencil-testing scheme. clipped by the far plane. Moreover, its non-homogeneous depth
This is sufficient to render shadow volumes robustly because it zc/wc must be 1.0, generating the maximum possible depth value.
avoids the problems created by the far clip plane “slicing open” It may be surprising, but positioning the far clip plane at infinity
the shadow volume. The shadow volumes we construct project typically reduces the depth buffer precision only marginally.
“all the way to infinity” through the use of homogeneous Consider how much we would need to shrink our window
coordinates to represent the shadow volume’s infinite back coordinates so we can represent within the depth buffer an infinite
projection. Importantly, though our shadow volume geometry is eye-space distance in front of the viewer. The projection P
infinite, it is also fully closed. The far clip plane, in eye-space, is transforms (0,0,-1,0) in eye-space (effectively, an infinite distance
infinitely far away so it is impossible for any of the shadow in front of the viewer) to the window-space depth Far/(Far-Near).
volume geometry to be clipped by it. The largest window coordinate representable in the depth buffer is
By using the zfail stencil-testing scheme, we can always assume 1 so we must scale Far/(Far-Near) by its reciprocal to “fit”
that infinity is “beyond” all closed shadow volumes if we, in fact, infinity in the depth buffer. This scale factor is (Far-Near)/Far
close off our shadow volumes at infinity. This means the shadow and is very close to 1 if Far is many times larger than Near which
depth count can always start from zero for every pixel. We need is typical.
not worry about the shadow volume being clipped by the near clip Said another way, using Pinf instead of P only compresses the
plane since we are counting shadow volume enters and exits from depth buffer precision slightly in typical scenarios. For example,
infinity, rather than from the eye, due to zfail stencil-testing. No if Near and Far are 1 and 100, then the depth buffer’s precision
fragile capping is required so our algorithm is both robust and must be squeezed by just 1% to represent an infinite distance in
automatic. front of the viewer.

3.2.1 Far Plane at Infinity 3.2.2 Infinite Shadow Volume Polygons
The standard perspective formulation of the projection matrix We assume that given a light source position and a closed model
used to transform eye-space coordinates to clip space in OpenGL with its edge-connectivity, we can determine the subset of
(see glFrustum [18]) is possible silhouette edges for the model. A possible silhouette
 2 × Near Right + Left 
edge is an edge shared by two triangles in a model where one of
 Right − Left 0 0  the two triangles faces a given light while the other triangle faces
Right − Left
  away from the light.
 2 × Near Top + Bottom 
0 0
P= Top − Bottom Top − Bottom  We call these edges “possible silhouette” edges rather than just
 Far + Near 2 × Far × Near 
 0 0 − −  silhouette edges because these edges are not necessarily
 Far − Near Far − Near  boundaries between shadowed and illuminated regions as implied

 0 0 −1 0 
 by the conventional meaning of silhouette. It is possible that an
where Near and Far are the respective distances from the viewer edge is an actual silhouette edge, but it is also possible that the
to the near and far clip planes in eye-space. edge is itself in shadow.
P is used to transform eye-space positions to clip-space positions: Assume we have computed the plane equations in the form
Ax+By+Cz+Dw=0 for every triangle in a given model. The plane
[x c yc zc wc ] = P [ x e
T
ye ze we ]
T
equation coefficients must be computed using a vertex ordering
consistent with the winding order shared by all the triangles in the
We are interested in avoiding far plane clipping so we only
model such that Ax+By+Cz+Dw is non-negative when a point
concern ourselves with the third and fourth row of P used to
(x,y,z,w) is on the front-facing side of the triangle’s plane.
compute clip-space zc and wc. Regions of an assembled polygon
Assume we also know the light’s homogeneous position L in the
with interpolated clip coordinates outside –wc ≤ zc ≤ wc are clipped coordinate space matching the plane equations. For each triangle,
by the near and far clip planes. evaluate d=ALx+BLy+CLz+DLw for the triangle’s plane equation
coefficients and the light’s position. If d is negative, then the

4


triangle is back-facing with respect to L; otherwise the triangle is 2. Load the projection with Pinf given the aspect ratio, field of
front-facing with respect to L. Any edge shared by two triangles view, and near clip plane distance in eye-space.
with one triangle front-facing and the other back-facing is a float Pinf[4][4];
possible silhouette edge. Pinf[1][0] = Pinf[2][0] = Pinf[3][0] = Pinf[0][1] =
To close a shadow volume completely, we must combine three Pinf[2][1] = Pinf[3][1] = Pinf[0][2] = Pinf[1][2] =
Pinf[0][3] = Pinf[1][3] = Pinf[3][3] = 0;
sets of polygons: (1) all of the possible silhouette polygon edges
extruded to infinity away from the light; (2) all of the occluder’s Pinf[0][0] = cotangent(fieldOfView)/aspectRatio;
back-facing triangles, with respect to L, projected away from the Pinf[1][1] = cotangent(fieldOfView);
Pinf[3][2] = -2*near; Pinf[2][2] = Pinf[2][3] = -1;
light to infinity; and (3) all of the occluder’s front-facing triangles
with respect to L. MatrixMode(PROJECTION); LoadMatrixf(&Pinf[0][0]);
3. Load the modelview matrix with the scene’s viewing
Each possible silhouette edge has two vertices A and B,
transform.
represented as homogeneous coordinates and ordered based on
the front-facing triangle’s vertex order. The shadow volume MatrixMode(MODELVIEW); loadCurrentViewTransform();
extrusion polygon for this possible silhouette is formed by the 4. Render the scene with depth testing, back-face culling, and
edge and its projection to infinity away from the light. The all light sources disabled (ambient & emissive illumination
resulting quad consists of the following four vertices: only).
Enable(DEPTH_TEST); DepthFunc(LESS);
B x , B y , B z , Bw
Enable(CULL_FACE); CullFace(BACK);
Ax , Ay , Az , Aw Enable(LIGHTING); Disable(LIGHT0);
Ax Lw − Lx Aw , Ay Lw − L y Aw , Az Lw − L z Aw ,0 LightModelfv(LIGHT_MODEL_AMBIENT, &globalAmbient);
drawScene();
B x L w − L x B w , B y L w − L y B w , B z L w − L z B w ,0
5. Disable depth writes, enable additive blending, and set the
The last two vertices are the homogeneous vector differences of global ambient light contribution to zero (and zero any
A-L and B-L. These vertices represent directions heading away emissive contribution if present).
from the light, explaining why they have w coordinate values of DepthMask(0);
zero. We do assume Aw≥0, Bw≥0, Lw≥0, etc. Enable(BLEND); BlendFunc(ONE,ONE);
When we use a perspective transform of the form Pinf, we can LightModelfv(LIGHT_MODEL_AMBIENT, &zero);
render shadow volume polygons without the possibility that the 6. For each light source:
far plane will clip these polygons.
A. Clear the stencil buffer to zero.
For each back-facing occluder triangle, its respective triangle Clear(STENCIL_BUFFER_BIT);
projected to infinity is the triangle formed by the following three
B. Disable color buffer writes and enable stencil testing
vertices:
with the always stencil function and writing stencil..
Ax Lw − Lx Aw , Ay Lw − L y Aw , Az Lw − Lz Aw ,0 ColorMask(0,0,0,0);
Bx Lw − Lx Bw , B y Lw − L y Bw , Bz Lw − Lz Bw ,0 Enable(STENCIL_TEST);
StencilFunc(ALWAYS,0,~0); StencilMask(~0);
C x Lw − Lx C w , C y Lw − L y C w , C z Lw − Lz C w ,0 C. For each occluder:
where A, B, and C are each back-facing occluder triangle’s three a. Determine whether each triangle in the occluder’s
vertices (in the triangle’s vertex order). model is front- or back-facing with respect to the
light’s position. Update triList[].backfacing.
The front-facing polygons with respect to L are straightforward.
Given each triangle’s three vertices A, B, and C (in the triangle’s b. Configure zfail stencil testing to increment stencil
vertex order), the triangle is formed by the vertices: for back-facing polygons that fail the depth test.
CullFace(FRONT); StencilOp(KEEP,INCR,KEEP);
Ax , Ay , Az , Aw c. Render all possible silhouette edges as quads that
Bx , By , Bz , Bw project from the edge away from the light to
infinity.
C x , C y , C z , Cw
Vert L = currentLightPosition;
Together, these three sets of triangles form the closed geometry of Begin(QUADS);
an occluder’s shadow volume with respect to the given light. for (int i=0; i<numTris; i++) // for each triangle
// if triangle is front-facing with respect to the light
3.3 Rendering Procedure if (triList[i].backFacing==0)
Now we sketch the complete rendering procedure to render for (int j=0; j<3; j++) // for each triangle edge
shadows with our technique. Pseudo-code with OpenGL // if adjacent triangle is back-facing
commands is provided to make the procedure more concrete. // with respect to the light
if (triList[triList[i].adjacent[j]].backFacing) {
// found possible silhouette edge
1. Clear the depth buffer to 1.0; clear the color buffer. Vert A = triList[i].v[j];
Clear(DEPTH_BUFFER_BIT | COLOR_BUFFER_BIT); Vert B = triList[i].v[(j+1) % 3]; // next vertex

5


Vertex4f(B.x,B.y,B.z,B.w); The INCR zpass stencil operation in step 6.E avoids the double
Vertex4f(A.x,A.y,A.z,A.w); blending of lighting contributions in the usually quite rare
Vertex4f(A.x*L.w-L.x*A.w, circumstance when two fragments alias to the exact same pixel
A.y*L.w-L.y*A.w, location and depth value. Using the KEEP zpass stencil operation
A.z*L.w-L.z*A.w, 0); // infinite instead can avoid usually unnecessary stencil buffer writes,
Vertex4f(B.x*L.w-L.x*B.w, improving rendering performance in situations where double
B.y*L.w-L.y*B.w,
blending is deemed unlikely.
B.z*L.w-L.z*B.w, 0); // infinite
} In the case of a directional light, all the vertices of a possible
End(); // quads silhouette edge loop project to the same point at infinity. In this
d. Specially render all occluder triangles. Project and case, a TRIANGLE_FAN primitive can render these polygons
render back facing triangles away from the light to extremely efficiently (1 vertex/projected triangle).
infinity. Render front-facing triangles directly. If the application determines that the shadow volume geometry for
#define V triList[i].v[j] // macro used in Vertex4f calls a silhouette edge loop will never pierce or otherwise require
Begin(TRIANGLES); capping of the near clip plane’s visible region, zpass shadow
for (int i=0; i<numTris; i++) // for each triangle volume rendering can be used instead of zfail rendering. The
// if triangle is back-facing with respect to the light zpass formulation is advantageous in this context because it does
if (triList[i].backFacing) not require the rendering of any capping triangles. Mixing the
for (int j=0; j<3; j++) // for each triangle vertex zpass and zfail shadow volume stencil testing formulations for
Vertex4f(V.x*L.w-L.x*V.w, V.y*L.w-L.y*V.w, different silhouette edge loops does not affect the net shadow
V.z*L.w-L.z*V.w, 0); // infinite depth count as long as each particular loop uses a single
else formulation.
for (int j=0; j<3; j++) // for each triangle vertex Shadow volume geometry can be re-used from frame to frame for
Vertex4f(V.x,V.y,V.z,V.w); any light and occluder that have not changed their geometric
End(); // triangles relationship to each other.
e. Configure zfail stencil testing to decrement stencil
for front-facing polygons that fail the depth test. 4. IMPROVED HARDWARE SUPPORT
CullFace(BACK); StencilOp(KEEP,DECR,KEEP);
4.1 Wrapping Stencil Arithmetic
f. Repeat steps (c) and (d) above, this time rendering DirectX 6 and the OpenGL EXT_stencil_wrap extension provide
front facing polygons rather than back facing ones. two additional increment wrap and decrement wrap stencil
D. Position and enable the current light (and otherwise operations that use modulo, rather than saturation, arithmetic.
configure the light’s attenuation, color, etc.). These operations reduce the likelihood of incorrect shadow results
Enable(LIGHT0); due to an increment operation saturating a stencil value’s shadow
Lightfv(LIGHT0, POSITION, &currentLightPosition.x); depth count. Using the wrapping operations with an N-bit stencil
E. Set stencil testing to render only pixels with a zero buffer, there remains a remote possibility that a net 2N increments
stencil value, i.e., visible fragments illuminated by the (or a multiple of) may alias with the unshadowed zero stencil
current light. Use equal depth testing to update only the value and lead to incorrect shadows, but in practice, particularly
visible fragments, and then, increment stencil to avoid with an 8-bit stencil buffer, this is quite unlikely.
double blending. Re-enable color buffer writes again.
StencilFunc(EQUAL, 0, ~0); StencilOp(KEEP,KEEP,INCR);
4.2 Depth Clamping
NVIDIA’s GeForce3 and GeForce4 Ti GPUs support depth
DepthFunc(EQUAL); ColorMask(1,1,1,1); clamping via the NV_depth_clamp OpenGL extension. When
F. Re-draw the scene to add the contribution of the current enabled, depth clamping disables the near and far clip planes for
light to illuminated (non-shadowed) regions of the rasterizing geometric primitives. Instead, a fragment’s window-
scene. space depth value is clamped to the range [min(zn,zf),max(zn,zf)]
drawScene(); where zn and zf are the near and far depth range values.
G. Restore the depth test to less. Additionally when depth clamping is enabled, no fragments with
DepthFunc(LESS); non-positive wc are generated.
7. Disable blending and stencil testing; re-enable depth writes. With depth clamping support, a conventional projection matrix
Disable(BLEND); Disable(STENCIL_TEST); DepthMask(1); with a finite far clip plane distance can be used rather than the Pinf
form. The only required modification to our algorithm is enabling
3.4 Optimizations DEPTH_CLAMP_NV during the rendering of the shadow volume
Possible silhouette edges form closed loops. If a loop of possible geometry.
silhouette edges is identified, then sending QUAD_STRIP primitives Depth clamping recovers the depth precision (admittedly quite
(2 vertices/projected quad), rather than independent quads (4 marginal) lost due to the use of a Pinf projection matrix. More
vertices/projected quad) will reduce the per-vertex transformation significantly, depth clamping generalizes our algorithm so it
overhead per shadow volume quad. Similarly, the independent works with orthographic, not just perspective, projections.
triangle rendering used for capping the shadow volumes can be
optimized for rendering as triangle strips or indexed triangles.

6


4.3 Two-Sided Stencil Testing 8. ACKNOWLEDGEMENTS
We propose two-sided stencil testing, a new stencil functionality We are grateful to John Carmack, Matt Craighead, Eric Haines,
that uses distinct front- and back-facing stencil state when and Matt Papakipos for fruitful discussions, Steve Burke for
enabled. Front-facing primitives use the front-facing stencil state modeling the SIGGRAPH logo and Loop subdivision surface for
for their stencil operation while back-facing primitives use the us; and James Green, Brian Collins, Rich B, and Stecki for
back-facing state. With two-sided stencil testing, shadow volume designing and animating the Quake2 models that we picture.
geometry need only be rendered once, rather than twice.
Two-sided stencil testing generates the same number of stencil
REFERENCES
[1] Kurt Akeley and James Foran, “Apparatus and method for
buffer updates as the two-pass approach so in fill-limited shadow controlling storage of display information in a computer system,”
volume rendering situations, the advantage of a single pass is US Patent 5,394,170, filed Dec. 15, 1992, assigned Feb. 28, 1995.
marginal. However, pipeline bubbles due to repeated all front-
[2] Harlen Costa Batagelo and Ilaim Costa Junior, “Real-Time Shadow
facing or all back-facing shadow volumes lead to inefficiencies Generation Using BSP Trees and Stencil Buffers,” XII Brazilian
using two passes. Perhaps more importantly, two-sided stencil Symposium on Computer Graphics and Image Processing,
testing reduces the CPU overhead in the driver by sending shadow Campinas, Brazil, Oct. 1999, pp. 93-102.
volume polygon geometry only once.
[3] Philippe Bergeron, “A General Version of Crow’s Shadow
Because stencil increments and decrements are intermixed with Volumes,” IEEE Computer Graphics and Applications, Sept. 1986,
two-sided stencil testing, the wrapping versions of these pp. 17-28.
operations are mandatory. [4] Jason Bestimt and Bryant Freitag, “Real-Time Shadow Casting
Using Shadow Volumes,” Gamasutra.com web site, Nov. 15, 1999.
5. EXAMPLES [5] Bill Bilodeau and Mike Songy, Creative Labs sponsored game
Figures 2 through 5 show several examples of our algorithm. developer conference, unpublished slides, Los Angeles, May 1999.

6. FUTURE WORK [6] David Blythe, Tom McReynolds, et.al., “Shadow Volumes,”
Program with OpenGL: Advanced Rendering, SIGGRAPH course
Because of the extremely scene-dependent nature of shadow
notes, 1996.
volume rendering performance and space constraints here, we
defer thorough performance evaluation of our technique. Still we [7] Jim Blinn, “A Trip Down the Graphics Pipeline: The Homogeneous
are happy to report that our rendering examples, including Perspective Transform,” IEEE Computer Graphics and
Applications,” May 1993, pp. 75-88.
examples that seek to mimic the animated behavior of a
sophisticated 3D game (see Figure 4), achieve real-time rates on [8] Lynne Brotman and Norman Badler, “Generating Soft Shadows with
current PC graphics hardware. a Depth Buffer Algorithm,” IEEE Computer Graphics and
Applications, Oct. 1984, pp. 5-12.
Yet naïve rendering with stenciled shadow volumes consumes
[9] John Carmack, unpublished correspondence, early 2000.
tremendous amounts of stencil fill rate. We expect effective
shadow volume culling schemes will be required to achieve [10] Frank Crow, “Shadow Algorithms for Computer Graphics,”
consistent interactive rendering rates for complex shadowed Proceedings of SIGGRAPH, 1977, pp. 242-248.
scenes. Portal, BSP, occlusion, and view frustum culling [11] Paul Diefenbach, Multi-pass Pipeline Rendering: Interaction and
techniques can all improve performance by avoiding the rendering Realism through Hardware Provisions, Ph.D. thesis, University of
of unnecessary shadow volumes. Additional performance scaling Pennsylvania, tech report MS-CIS-96-26, 1996.
will be through faster and cleverer hardware designs that are [12] Alain Fournier and Donald Fussell, “On the Power of the Frame
better tuned for rendering workloads including stenciled shadow Buffer,” ACM Transactions on Graphics, April 1988, 103-128.
volumes. [13] Henry Fuchs, Jack Goldfeather, Jeff Hultquist, Susan, Spach, John
Future graphics hardware will support more higher-order graphics Austin, Frederick Brooks, John Eyles, and John Poulton, “Fast
primitives beyond triangles. Combining higher-order hardware Spheres, Shadows, Textures, Transparencies, and Image
Enhancements in Pixel-Planes,” Proceedings of SIGGRAPH, 1985,
primitives with shadow volumes requires automatic generation of
pp. 111-120.
shadow volumes in hardware. Two-sided stencil testing will be
vital since it only requires one rendering of automatically [14] Tim Heidmann, “Real Shadows Real Time”, IRIS Universe, Number
18, 1991, pp. 28-31.
generated shadow volume geometry. Automatic generation of
shadow volumes will also relieve the CPU of this chore. [15] Mark Kilgard, “Improving Shadows and Reflections via the Stencil
Buffer,” Advanced OpenGL Game Development course notes, Game
7. CONCLUSIONS Developer Conference, March 16, 1999, pp. 204-253.
Our stenciled shadow volume algorithm is robust, straightforward, [16] Mark Kilgard, “Robust Stencil Volumes,” CEDEC 2001
and requires hardware functionality that is ubiquitous today. We presentation, Tokyo, Sept. 4, 2001.
believe this will provide the opportunity for 3D games and [17] Michael McCool, “Shadow Volume Reconstruction from Depth
applications to integrate shadow volumes into their basic Maps,” ACM Transactions on Graphics, Jan. 2001, pp. 1-25.
rendering repertoire. The algorithm we developed is the result of [18] Mark Segal and Kurt Akeley, The OpenGL Graphics System: A
careful integration of known, but not previously integrated, Specification, version 1.3, 2001.
techniques to address methodically the shortcomings of existing
[19] Andrew Woo, Pierre Poulin, and Alain Fournier, “A Survey of
shadow volume techniques caused by near and/or far plane
Shadow Algorithms,” IEEE Computer Graphics and Applications,
clipping. Nov. 1990, pp. 13-32.

7


Scene from eye’s point of view (left) and visualizing shadow volumes (right). Shadowed scene with the light near the eye
and surrounded by a complex surface.

Alternate view of scene showing eye frustum (left) and visualizing shadow volumes (right).
An alternate view of the scene including
shadow volumes and silhouette edges with
everything outside the eye's infinite frustum
clipped away.

View of scene in eye’s clip space (left) and visualizing shadow volumes (right).

Figure 2: These images show a scene with a light source surrounded by a
complex object. This arrangement is a “hard” case for shadow volume rendering.
The infinite capping polygons can be seen behind the wall and floor in the bottom Same as above, except the scene is shown in
eye's clip space.
right image. All the scenes use a Pinf projection matrix.

Figure 3: These images illustrate the
capping at infinity that is required for
correct closed shadow computation.

Figure 5: Shadowed scene lit by a directional
Figure 4: Game-like scenes with 3 independent colored light sources (left, light (left) and the corresponding clip-space
34 frames/second on a GeForce4 Ti 4600 at 640x480, 80+ fps for 1 light) view with the shadow volume’s back projection
and 12 clustered lights to simulate soft shadows (right, 8 fps). Characters meeting at infinity on the far clip plane (right).
have diffuse/specular per-pixel bump map shading, correctly shadowed.

8

Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering

Recommended

More Related Content

What's hot (20)

Similar to Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering (20)

More from Mark Kilgard (20)

Recently uploaded (20)

Practical and Robust Stenciled Shadow Volumes for Hardware-Accelerated Rendering