This document summarizes the topics to be covered in a CS 354 class on March 22, 2012. It includes an in-class quiz on shadow algorithms, continuing the discussion of shadow generation algorithms and an introduction to scene graphs. It also provides updates on course status including returning mid-term exams and feedback. The professor's office hours are listed. The lecture will finish the discussion of shadow algorithms and cover scene graphs, which are data structures used to organize rendering of 3D scenes.

1. CS 354
Shadows (cont’d) &
Scene Graphs
Mark Kilgard
University of Texas
March 22, 2012

2. CS 354 2
Today’s material
 In-class quiz
 On shadow algorithms lecture
 Lecture topic
 Finish Shadow Algorithms
 Scene Graphs
 Course status
 Return mid-terms & feedback

3. CS 354 3
My Office Hours
 Tuesday, before class
 Painter (PAI) 5.35
 8:45 a.m. to 9:15
 Thursday, after class
 ACE 6.302
 11:00 a.m. to 12
 Randy’s office hours
 Monday & Wednesday
 11 a.m. to 12:00
 Painter (PAI) 5.33

4. CS 354 4
Last time, this time
 Last lecture, we
 Discussed shadow generation algorithms
 Shadow mapping
 Planar projected shadows
 Shadow volumes
 This lecture
 Shadow generation algorithms
 Scene graph
 Data structures to organize the rendering of 3D
scenes

5. CS 354 5
On a sheet of paper
Daily Quiz • Write your EID, name, and date
• Write #1, #2, #3, #4 followed by its answer
 Multiple choice: Shadow acne is a  True or false: The stencil buffer
visual artifact that affects maintains a floating-point value
corresponding to each color sample.
a) shadow mapping
b) projected planar shadows Mid-term feedback
Total questions: 43
c) shadow volumes Maximum possible: 83
d) stencil buffer updates
Top grade: 75
 Multiple choice: An approach to Median: 59.0
reduce shadow acne is Average: 58.0
Standard deviation: 9.63
a) avoiding the far clip plane
Percentage Grade Distribution
16
b) casting fewer shadow rays 14
12
c) polygon offset
10
d) acne cream 8
6
4
2
0
40-49 50-59 60-69 70-79 80-89 90-100

6. CS 354 6
Visualizing
Shadow Volumes
 Occluder and light projects a shadow volume

7. CS 354 7
Shadow Volume
Result
 Objects within the volume are shadowed

8. CS 354 8
Shadow Volume
Algorithm
 High-level view of the algorithm
 Given the scene and a light source position,
determine the shadow volume (harder than it
sounds)
 Render the scene in two passes
 Draw scene with the light enabled,
updating only fragments in unshadowed region
 Draw scene with the light disabled,
updated only fragments in shadowed region
 But how to control update of regions?

9. CS 354 9
2D Cutaway of a
Shadow Volume
surface outside
shadowing shadow volume
object (illuminated)
light
source shadow
volume
(infinite extent)
eye
position surface inside
partially
shadowed shadow volume
object (shadowed)

10. CS 354 10
For Shadow Volumes
With Intersecting Polygons
 Use a stencil enter/leave counting approach
 Draw shadow volume twice using face culling
 1st pass: render front faces and increment when
depth test passes
 2nd pass: render back faces and decrement when
depth test passes
 This two-pass way is more expensive than
invert
 And burns more fill rate drawing shadow
volumes
 Inverting is better if no polygon intersections

11. CS 354 11
Why Eye-to-Object Stencil
Counting Approach Works
Light Shadowing object
source
zero +1
zero
Example in 2D
+2 +2
Eye +1
+3
position

12. CS 354 12
Illuminated,
Behind Shadow Volumes (Zpass)
Light Shadowing object
source
zero +1
zero
+ + + - - - Unshadowed
object
+2 +2
Eye +1
+3
position
Shadow Volume Count = +1+1+1-1-1-1 = 0

13. CS 354 13
Shadowed, Nested in Shadow
Volumes (Zpass)
Light Shadowing object
source
zero +1
zero
+ + + -
+2 +2 Shadowed
Eye +1 object
+3
position
Shadow Volume Count = +1+1+1-1 = 2

14. CS 354 14
Illuminated, In Front of Shadow
Volumes (Zpass)
Light Shadowing object
source
zero +1
zero
+2 +2 Shadowed
Eye +1 object
+3
position
Shadow Volume Count = 0 (no depth tests pass)

15. CS 354 15
Shadow Volume
Issues
 Practical considerations [Bergeron 86]
 If eye is in shadow volume, need to
determine this and flip enabled & disabled
lighting passes
 Shadow volume only as good as its
tessellation
 Shadows tend to magnify limited tessellation of
curved surfaces
 Open models and non-planar polygons
 Must cap the shadow volume’s intersection
with the near clipping plane

16. CS 354 16
Problem Created by
Near Clip Plane (Zpass)
Missed shadow volume
intersection due to near
clip plane clipping; leads
to mistaken count Far clip
plane
zero
+1
+1
+2
zero
+3
+2
Near clip
plane

17. CS 354 17
Alternative Approach: Zfail
 Render scene to initialize depth buffer
 Depth values indicate the closest visible
fragments
 Use a stencil enter/leave counting approach
 Draw shadow volume twice using face culling
 1st pass: render back faces and increment when depth
test fails
 2nd pass: render front faces and decrement when depth
test fails
 Don’t update depth or color
 Afterward, pixel’s stencil is non-zero if pixel in
shadow, and zero if illuminated

18. CS 354 18
Illuminated,
Behind Shadow Volumes (Zfail)
Light Shadowing object
source
zero +1
zero
Unshadowed
object
+2 +2
Eye +1
+3
position
Shadow Volume Count = 0 (zero depth tests fail)

19. CS 354 19
Shadowed, Nested in
Shadow Volumes (Zfail)
Light Shadowing object
source
zero +1
zero
+ +
+2 +2 Shadowed
Eye +1 object
+3
position
Shadow Volume Count = +1+1 = 2

20. CS 354 20
Illuminated, In Front of Shadow
Volumes (Zfail)
Light Shadowing object
source
zero +1
zero
- - - + + +
+2 +2 Shadowed
Eye +1 object
+3
position
Shadow Volume Count = -1-1-1+1+1+1 = 0

21. CS 354 21
Problem Created by
Far Clip Plane (Zfail)
Far clip
plane
Missed shadow volume
intersection due to far
clip plane clipping;
zero
leads to mistaken count
+1
zero
+1 +2
+2
+3
Near clip
plane

22. CS 354 22
Problem Solved by
Eliminating Far Clip
zero
+1
+1 +2
+2
+3
Near clip
plane

23. CS 354 23
Avoiding Far Plane Clipping
 Usual practice for perspective GL projection
matrix
 Use glFrustum (or gluPerspective)
 Requires two values for near & far clip planes
 Near plane’s distance from the eye
 Far plane’s distance from the eye
 Assumes a finite far plane distance
 Alternative projection matrix
 Still requires near plane’s distance from the eye
 But assume far plane is at infinity
 What is the limit of the projection matrix when
the far plane distance goes to infinity?

24. CS 354 24
Standard glFrustum Projection
Matrix
 2 × Near Right + Left 
 Right − Left 0 0 
Right − Left
 
 2 × Near Top + Bottom 
0 0
P= Top − Bottom Top − Bottom 
 Far + Near 2 × Far × Near 
 0 0 − − 
 Far − Near Far − Near 

 0 0 −1 0 

 Only third row depends on Far and Near

25. CS 354 25
Limit of glFrustum Matrix as
Far Plane is Moved to Infinity
 2 × Near Right + Left 
 Right − Left 0 0 
Right − Left
 
2 × Near Top + Bottom
lim P = Pinf = 0 0 
Far →∞  Top − Bottom Top − Bottom 
 0 0 −1 − 2 × Near 
 

 0 0 −1 0 

 First, second, and fourth rows are the same as
in P
 But third row no longer depends on Far
 Effectively, Far equals ∞

26. 26
Verifying Pinf Will Not Clip
CS 354
Infinitely Far Away Vertices (1)
 What is the most distant possible vertex in
front of the eye?
 Ok to use homogeneous coordinates
 OpenGL convention looks down the negative Z
axis
 So most distant vertex is (0,0,-D,0) where D>0
 Transform (0,0,-D,0) to window space
 Is such a vertex clipped by Pinf?
 No, it is not clipped, as explained on the next
slide

27. 27
Verifying Pinf Will Not Clip
CS 354
Infinitely Far Away Vertices (2)
 Transform eye-space (0,0,-D,0) to clip-space
 2 × Near Right + Left 
0 0
 xc   xc   Right − Left Right − Left   0 
 y  y   2 × Near Top + Bottom
  0 
 c  =  c =  0 0   
− D   zc   Top − Bottom Top − Bottom  − D 
     0 0 −1 − 2 × Near   
 − D   wc     0 

 0 0 −1 0 

 Then, assuming glDepthRange(0,1), transform clip-
space position to window-space position
zc −D
z w = 0.5 × + 0.5 = 0.5 × + 0.5 = 1
wc −D
 So ∞ in front of eye transforms to the maximum
window-space Z value, but is still within the valid depth
range (i.e., not clipped)

28. CS 354 28
Robust Shadow Volumes sans
Near (or Far) Plane Capping
 Use Zfail Stenciling Approach
 Must render geometry to close shadow volume extrusion
on the model and at infinity (explained later)
 Use the Pinf Projection Matrix
 No worries about far plane clipping
 Losses some depth buffer precision (but not much)
 Draw the infinite vertices of the shadow volume
using homogeneous coordinates (w=0)

29. CS 354 29
Visualize Net Stencil Rendering
 Non-zero stencil state marks shadowed pixels
w.r.t. the light source
Fully shaded scene Final stencil state

30. CS 354 30
Stencil Volume
Rendering Animation

31. CS 354 31
Shadow Volumes Add “Invisible”
Geometric Complexity
Visible geometry
Scene with multiple light sources Shadow volume
geometry
Abducted game images courtesy
Joe Riedel at Contraband Entertainment

32. CS 354 32
Examples of Possible Silhouette
Edges for Quake2 Models
An object viewed from the
same basic direction that
the light is shining on the
object has an identifiable
light-view silhouette
An object’s light-view
silhouette appears quite
jumbled when viewed form
a point-of-view that does
not correspond well with
the light’s point-of-view

33. CS 354 33
Multiple Lights and
Shadow Volumes
 Requires still more rendering passes,
but can work!
Shadows from different
light sources overlap
correctly

34. CS 354 34
Shadow Volumes from
Area Light Sources
 Make soft shadows
 Shadow volumes work for point light sources
 Area light sources are common and make
soft shadows
 Model an area light source as a collection of
point light sources [Brotman & Badler 84]
 Use accumulation buffer or additive blending
to accumulate soft shadow
 Linear cost per shadow volume sample

35. CS 354 35
Area Light Sources Cast Soft
Shadows
area light
source
umbra

36. CS 354 36
Soft Shadow Example
 Eight samples (more would be better)
Note the banding
artifacts

37. CS 354 37
Combined
Shadow Approaches
 Two Approaches at Once
just logo shadow volume
logo lacks shadow
on the teapot
just planar projected
teapot lacks
shadows
shadow
on the floor
combined
approach

38. CS 354 38
Pre-computed
Shadow Textures
 Lightmaps are static shadow textures
 Compute lightmaps off-line with radiosity
solver
 local lighting models evaluated on tight grid can
work well too
 Lightmaps with soft shadows can be built
faster with convolution approach, accelerated
using the Fast Fourier Transform [Soler &
Silion 98]
 Pre-computed shadow textures work well for
building interior with lots of diffuse surfaces

39. CS 354 39
Light maps can encode
Static Pre-computed Shadows
decal only
×
(modulate)
light maps only
=
* Id Software’s Quake 2
combined scene circa 1997

40. CS 354 40
Rendering
Soft Shadow Textures
 Fast soft shadows [Heckbert & Herf 96]
 Render a shadow texture
 For each shadowed polygon, project all light-source-
occluding polygons into the shadowed polygon’s plane
* Similar to projected planar shadows
* Model area light sources as multiple jittered points
* Use additive blending to accumulate all contributions
 Copy resulting image to the shadow texture
 Draw polygon in final scene with shadow texture

41. CS 354 41
Rendered
Soft Shadow Texture Example
 Shadow Texture and Final Result
Shadow texture, accumulation Final resulting scene, shadow
of nine jittered occluder texture modulated with
projections wooden floor

42. CS 354 42
Scene Graphs
 Refers to the application data structures
for representing a 3D scene
 Typically object-oriented, often C++
 Inheritance is very natural
 Game engine
 Scene graph + much more
 Tightly coupled to
 Content creation tools
 Compiled/packed game data

43. CS 354 43
Game Engines
 Scene graph is usually the core of a game engine’s data
structure
 Game engines do much more
 Audio
 Networking
 Physics + collision detection
 Game play
 User input
 Artificial intelligence / strategy
 Control panel
 Scripting language environment
 Resource management: textures, geometry, etc.

44. CS 354 44
Tension in Scene Graph Design
Balanced
Lots
of control Highest
of scene performance
Expressiveness Efficiency
Good engineering is to balancing design choices
based on application needs

45. CS 354 45
Scene Graphs
 API examples
 Open Inventor, IRIS Performer
 Open Scene Graph
 Game engine examples
 Id Tech
 Epic
 C4 Engine
 Ogre
 Unity
 File format examples
 Virtual Reality Modeling Language (VRML)
 Didn’t really work, re dux is X3D
 Scalable Vector Graphics (SVG)
 Specialized for 2D scenes
 COLLADA
 Scene interchange format
 X3D

46. CS 354 46
Layering
Application
Scene graph
Graphics API
OpenGL or Direct3D
Graphics hardware

47. CS 354 47
Common Nodes
 Transform
 Nest hierarchically
 Geometry Object (shape)
 Geometric mesh (geoset)
 Material or surface shader
 Camera (view)
 Light Source
 Group
 Property

48. CS 354 48
Example: Performer
LOD = Level-of-detail Billboard = geometry set always
SCS = Static coordinate system oriented to point towards viewer
DCS = Dynamic coordinate system Example: textured tree cut-outs

49. CS 354 49
Transform types
 Standard transforms
 Rotation, translation, scale, shear
 Rotations
 Quaternion, trackball
 Animation
 Splines
 Blends
Unity transforms

50. CS 354 50
Hierarchical Scenes

51. CS 354 51
Light Node types
 Directional light
 Point light
 Spot light
 Advanced lights
 Shadowed light
 Depends on multi-pass traversal of scene graph
 Blinking light

52. CS 354 52
Camera types
 Orthographic camera
 Perspective camera

53. CS 354 53
Geometry
 Shapes are represented
 Geometry
 Usually meshes
 Or patches for tessellation
 Surface appearance
 Material parameters
 Shaders
 Textures

54. CS 354 54
Traversal

55. CS 354 55
Acceleration Structures
 Binary Space Partitioning (BSP) trees
 Bounding spheres
 Bounding hulls
 Portal systems
 Octrees
 Grids

56. CS 354 56
View Frustum Culling
 Avoid drawing objects in scene graph
conservatively outside the view frustum

57. CS 354 57
Occlusion
Culling
With occlusion
culling
Without
occlusion
culling

58. CS 354 58
Portal Culling
 Good for indoor environments

59. CS 354 59
Maintaining Constant Frame Rate
 Visual simulation and games aim for a high and
constant frame rate
 60 frames per second for illusion of animation
 Means 16.6 milliseconds per frame
 “Never drop a frame” (hard in practice)
 Tied to the refresh interval of the display device
 Strategies to maintain frame rate
 Level-of-detail
 Hard to do this while avoiding “popping” artifacts
 Maximizing cull-able rendering
 Dynamic resize the pixel resolution
 Tune the scene to avoid “complex” views

60. CS 354 60
Manipulators
Trackball manipulator
Handle-box manipulator

61. CS 354 61
Scene Graph Labor
 High-level division of scene graph labor
 Four pipeline stages
 App (application)
 Code that manipulates/modifies the scene graph in response to
user input or other events
 Isect (intersection)
 Geometric queries such as collision detection or picking
 Cull
 Traverse the scene graph to find the nodes to be rendered
 Best example: eliminate objects out of view
 Optimize the ordering of nodes
 Sort objects to minimize graphics hardware state changes
 Draw
 Communicating drawing commands to the hardware
 Generally through graphics API (OpenGL or Direct3D)
 Can map well to multi-processor CPU systems

62. CS 354 62
Scene Graph Profiling
 Scene graph should help provide insight
into performance
 Process statistics
 What’s going on?
 Time stamps
 Database statistics
 How complex is the scene in any frame?

63. CS 354 63
Example:
Depth Complexity Visualization
 How many pixels are being rendered?
 Pixels can be rasterized by multiple objects
 Depth complexity is the average number of times a
pixel or color sample is updated per frame
yellow and black indicate higher depth complexity

64. CS 354 64
Example:
Heads-up Display of Statistics
 Process statistics
 How long is
everything taking?
 Database statistic
 What is being
rendered?
 Overlaying on
active scene often
value
 Dynamic update

65. CS 354 65
Next Class
 Project 2 today (!?)
 On texturing, shading, & lighting
 Study GLSL
 Two weeks to complete
 Next lecture
 Compression
 How can images and other graphics data be stored
more compactly?