Upcoming SlideShare
×

# CS 354 Shadows (cont'd) and Scene Graphs

1,501 views
1,326 views

Published on

CS 354 Shadows (cont'd) & Scene Graphs; University of Texas at Austin; March 22, 2012

Published in: Technology, Education
4 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

Views
Total views
1,501
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
72
0
Likes
4
Embeds 0
No embeds

No notes for slide

### CS 354 Shadows (cont'd) and Scene Graphs

1. 1. CS 354Shadows (cont’d) &Scene GraphsMark KilgardUniversity of TexasMarch 22, 2012
2. 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. 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. 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
6. 6. CS 354 6 Visualizing Shadow Volumes  Occluder and light projects a shadow volume
7. 7. CS 354 7 Shadow Volume Result  Objects within the volume are shadowed
8. 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?
10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. CS 354 22 Problem Solved by Eliminating Far Clip zero +1 +1 +2 +2 +3 Near clip plane
23. 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. 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. 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. 26 Verifying Pinf Will Not ClipCS 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. 27 Verifying Pinf Will Not ClipCS 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. 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. 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. 30. CS 354 30 Stencil Volume Rendering Animation
31. 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. 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. 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. 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. 35. CS 354 35 Area Light Sources Cast Soft Shadows area light source umbra
36. 36. CS 354 36 Soft Shadow Example  Eight samples (more would be better) Note the banding artifacts
37. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. CS 354 46 Layering Application Scene graph Graphics API OpenGL or Direct3D Graphics hardware
47. 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. 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. 49. CS 354 49 Transform types  Standard transforms  Rotation, translation, scale, shear  Rotations  Quaternion, trackball  Animation  Splines  Blends Unity transforms
50. 50. CS 354 50 Hierarchical Scenes
51. 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. 52. CS 354 52 Camera types  Orthographic camera  Perspective camera
53. 53. CS 354 53 Geometry  Shapes are represented  Geometry  Usually meshes  Or patches for tessellation  Surface appearance  Material parameters  Shaders  Textures
54. 54. CS 354 54 Traversal
55. 55. CS 354 55 Acceleration Structures  Binary Space Partitioning (BSP) trees  Bounding spheres  Bounding hulls  Portal systems  Octrees  Grids
56. 56. CS 354 56 View Frustum Culling  Avoid drawing objects in scene graph conservatively outside the view frustum
57. 57. CS 354 57 Occlusion Culling With occlusion culling Without occlusion culling
58. 58. CS 354 58 Portal Culling  Good for indoor environments
59. 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. 60. CS 354 60 Manipulators Trackball manipulator Handle-box manipulator
61. 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. 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. 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. 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. 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?