Shadow Algorithms

Ikrima Elhassan

Outline

Curved Shadows on curved surfaces (Williams paper)

Shadow volumes & implementation (Crow & Heidmann paper)

(A lot of) Extra stuff (flaws of shadow volumes and solutions)

Shadow Buffers

Projecting shadows onto planes is trivial Project the scene onto a plane using light as

eye For curved surfaces, we still use two views

Algorithm

Compute z-buffer of the scene from the light’s view

Render the view from the eye perspective For each point in the view, transform it into

light space. If the point is not visible in light space, it’s in shadow, otherwise compute shading for the point.

Approximating the algorithm

Scene is computed from eye perspective, then a transform everything, point by point, to light space

Shadowing is taken as a post-process Incorrectly shades the highlights; they are

merely darkened Suffers from aliasing and quantization

problems

Algorithm (Cont)

Transform only applied to visible points Transform expense does not depend on complexity of

scene Depends on resolution, which increases with square of

the resolution Computation done in image space

Limitations

Occluders must be within view of light source For point lights, sphere of illumination should

be sectored into multiple views Cost increases because points must be

transformed into multiple light views or transformed into the view that the point falls under

Causes an increase in memory

Limitations (Cont)

Algorithm allows for self-shadowing surfaces

Problems with z-buffer precision when transforming points from surface in eye space onto surface in light space

Quantization Issues

Imprecision problems arise To alleviate problem, subtract z-bias to make

transformed points lie on visible surface in light space

Treating these problems as quantization problems improves image further

Not as big of a problem b/c during shading, there’s a smooth lighting transition from light to dark

Also, low pass filtering is applied to create soft-shadows, reducing error

Conclusion

Allows for self-shadowing Cost is roughly twice cost of rendering plus

cost of transforming points With exact version, transformation cost is

related to depth complexity With modified version, cost is tied to screen

resolution Cost is roughly twice rendering b/c shading is

not computed for light space Memory is no longer an issue

Shadow Volumes

Straight to Shadow volumes

Combine both papers so we can have time for extra material

Papers provided the foundation for volume shadow algorithms

Other two techniques are outdated and will come back to them at the very end so we can focus on the current algorithm

Algorithm is to create “shadow volume” from occluders

Everything within the shadow volume is in shadow

Shadow Volume Concept

Shadow volume is constructed from occluders

Although we can create volumes for every triangle in the occluders, we only need the silhouette

Different types of volume for different types of lights

Depth-Pass stencil testing

Render the Scene and keep the z-buffer. Fragments with non-zero stencil values are

considered to be in shadow. The generation of the values in the stencil buffer :

1. Render front face of shadow volume. If depth test passes, increment stencil value, else does nothing. Disable draw to frame and depth buffer.

2. Render back face of shadow volume. If depth test passes, decrement stencil value, else does nothing. Disable draw to frame and depth buffer.

Algorithm known as Depth-Pass b/c set the stencil values only when depth test passes

Depth-Pass stencil testing (Cont)

Assume objects have been rendered into framebuffer

Depth buffer would have been set with the correct values for depth testing

2 leftmost rays have 0 stencil values, meaning those fragments are not in shadow

For 3rd ray, when we render the front face of the shadow volume, fragment passes depth test and stencil value is incremented

When rendering back face of shadow volume, depth test fails; stencil value for the fragment is still 1 and fragment is in shadow

Does the shadow volume counting work for multiple shadow volumes? Yes, even for intersecting shadow volumes.

Infinite vs. Finite

In theory, shadow volume should extend to infinity but this is not a strict requirement

We extend to infinity to avoid the problem shown on left

We’ll discuss how to cap and extrude to infinity later

Summary of High Level algorithm

1. Render objects using only ambient lighting and other surface-shading attributes. Rendering cannot depend on lighting. Make sure depth buffer is written

2. Starting with a light source, clear stencil buffer and calculate the silhouette of all the occluders with respect to light

3. Extrude the silhouette away from the light source to a finite or infinite distance to form the shadow volumes (Infinite shadow volume extrusion is not a necessity)

4. Render shadow volumes using the depth-pass 5. Using the updated stencil buffer, do a lighting pass to shade (make it

a tone darker) the fragments that corresponds to non-zero stencil values.

6. Repeat step 2 to 5 for all the lights in the scene.

Where do highlights fit in? More lights means having more passes which can destroy frame rate

Extra Stuff

Why do we need to find alternatives to shadow volumes?

Shadow volumes works great until camera is in a volume

Carmack’s solution (Depth-Fail)

Render back face of shadow volume. If depth test fails, increment stencil value, else does nothing. Disable draw to frame and depth buffer.

Render front face of shadow volume. If depth test fails, decrement stencil value, else does nothing. Disable draw to frame and depth buffer.

This works for when eye is outside volume, but it also fails in some cases

Robust solution requires a hybrid of both of these techniques

Depth Fail (Cont)

To put in non-zero values into the stencil buffer, depth-fail depends on the failure to render the shadow volume's back faces with respect to the eye position

Means the shadow volume must be a closed volume

Without capping, the depth-fail technique would produce erroneous results.

You can cap the shadow volume even at infinity.

Capping

We can build the front cap by reusing the front facing triangles with respect to the light source.

The geometries used in the front cap can then be extruded with reversed orderings to create the back cap.

Must reverse order to ensure back cap face outward

To create closed volume, all of the bounding primitives of the volume must face outward

Capped volumes are more expensive

Larger primitive count for the shadow volume

Additional computational resource needed to compute the front and back capping

Silhouette Determination

Many ways to calculate the silhouette edges and all are CPU cycles hungry

Broken lines indicate redundant internal edges

Only interested in the solid outline of the box

Silhouette determination is one of the two most expensive operations in stencil shadow volumes

Other is shadow volume rendering passes to update the stencil buffer

Silhouette Determination (Cont)

1. Loop through all the model's triangles 2. If triangle faces the light source (dot product > 0) 3. Insert the three edges (pair of vertices), into an

edge stack 4. Check for previous occurrence of each edges or it's

reverse in the stack 5. If an edge or its reverse is found in the stack,

remove both edges 6. Start with new triangle

Generating Shadow Volume Capping

Capping should be done during silhouette determination because we need silhouette geometry

Front/Back caps are trivial, just use the silhouette (w/reverse order for the back)

For directional light sources, the light projects the silhouette to a single point (?)

Extruding to infinity

In vague terms, set the far clip plane at infinity Changes the perspective matrix slightly Use homogenous coordinates For points, w is equal to 1.0. For vectors, w is equal to 0.0. For points at infinity, set w to be 0.0.

Problems with extruding to infinity

Ghost shadows occur Shadow volume

extends to both sides of an object

There’s really no solution

View Frustum Clipping

The worst problem of stencil shadow volumes Problem for both depth-pass and depth fail To solve for depth fail, make the far clipping plane go

to infinity so you have an infinite view frustum Also have precision issues when extruding to infinity

because far clip plane is so far away

Depth Pass vs. Depth Fail

Advantages – Does not require capping for

shadow volumes – Less geometry to render – Faster of the two techniques – Easier to implement if we

ignore the near plane clipping problem

– Does not require an infinite perspective projection

Disadvantages – Not robust due to unsolvable

near plane clipping problem – No self shadowing

Advantages – Robust solution since far plane

clipping problem can be solved elegantly

Disadvantages – Requires capping to form

closed shadow volumes – More geometry to render due

to capping – Slower of the two techniques – Slightly more difficult to

implement – Requires an infinite perspective

projection – No self shadowing

Misc

The math falls outside the scope of the presentation A lot of areas to optimize and create a more efficient

and robust algorithm Stencil volumes can be perfectly implemented with

vertex shaders For more information,

http://developer.nvidia.com/docs/IO/2585/ATT/RobustShadowVolumes.pdf