Upcoming SlideShare
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Standard text messaging rates apply

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

900
views

Published on

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

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

Published in: Technology, Education

3 Likes
Statistics
Notes
• Full Name
Comment goes here.

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

Views
Total Views
900
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
60
0
Likes
3
Embeds 0
No embeds

No notes for slide

### Transcript

• 1. CS 354Shadows (cont’d) &Scene GraphsMark KilgardUniversity of TexasMarch 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
• 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?
• 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 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 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. 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?