Shadow Algorithms Ikrima Elhassan

Download Report

Transcript Shadow Algorithms Ikrima Elhassan

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 softshadows, 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.
2.

Render front face of shadow volume. If depth test passes,
increment stencil value, else does nothing. Disable draw
to frame and depth buffer.
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.
2.
3.
4.
5.
6.


Render objects using only ambient lighting and other surface-shading
attributes. Rendering cannot depend on lighting. Make sure depth
buffer is written
Starting with a light source, clear stencil buffer and calculate the
silhouette of all the occluders with respect to light
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)
Render shadow volumes using the depth-pass
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.
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, depthfail 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 depthfail 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.
2.
3.
4.
5.
6.
Loop through all the model's triangles
If triangle faces the light source (dot product > 0)
Insert the three edges (pair of vertices), into an
edge stack
Check for previous occurrence of each edges or it's
reverse in the stack
If an edge or its reverse is found in the stack,
remove both edges
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/Robus
tShadowVolumes.pdf