1. Recap: General Occlusion Culling l When cells and portals don’t work… –Trees in a forest –A crowded train station l Need general occlusion culling algorithms: –Aggregate occlusion –Dynamic scenes –Non-polygonal scenes

2. Recap: Image-Space Occlusion Culling l Most general occlusion culling algorithms use an image-space approach –Idea: solve visibility in 2D, on the image plane –Note: gives up view-independent visibility

3. Recap: Hierarchical Z-Buffer l Replace Z-buffer with a Z-pyramid –Lowest level: full-resolution Z-buffer –Higher levels: each pixel represents the max depth of the four pixels “underneath” it l Basic idea: hierarchical rasterization of the polygon, with early termination where polygon is occluded

4. Recap: Hierarchical Z-Buffer l Z-pyramid exploits image-space coherence: –Polygon occluded in a pixel is probably occluded in nearby pixels l HZB also exploits object-space coherence –Polygons near an occluded polygon are probably occluded

5. Recap: Hierarchical Z-Buffer l HZB can exploit temporal coherence –Most polygons affecting the Z-buffer last frame will affect Z-buffer this frame –HZB also operates at max efficiency when Z-pyramid already built l So start each frame by rendering octree nodes visible last frame

6. Hierarchical Z-Buffer: Discussion l HZB needs hardware support to be really competitive l Hardware vendors haven’t entirely bought in: –Z-pyramid (and hierarchies in general) unfriendly to hardware –Unpredictable Z-query times generate bubbles in rendering pipe l But there are promising trends: –ATI’s HYPER-Z technology: one-level HZB –Occlusion queries!

7. Modern Occlusion Culling l Support from hardware would be nice –Want an “occlusion test”: would this polygon be visible if I rendered it? –How could you use such a test? n Test portal polygons before rendering adjacent cell n Test object bounding boxes before rendering object –Yay! GL_HP_OCCLUSION_TEST extension –Problems: n CPU/GPU synchronization == bad n Might want to know “how visible” is the polygon

8. Modern Occlusion Culling GL_NV_OCCLUSION_QUERY to the rescue –Non-blocking query n “Is this occlusion query done yet?” n Multiple queries in flight –Returns number of fragments visible l Note: can actually render object or not l Supports object-space coherence, temporal coherence l Still lots of issues for efficient culling Wrong

9. Modern Occlusion Culling GL_ARB_OCCLUSION_QUERY –Deprecates NV_OCCLUSION_QUERY –Fixes a potential race condition

10. 111 uses for NV_OCCLUSION_QUERY l Occlusion culling (duh) l Others? –Approximate culling –LOD size estimation –Lens flare effects –Transparency –Collision detection (!) –Convergence testing

11. NV_OCCLUSION_QUERY : Details l Go to NVIDIA presentation…

12. Occlusion Culling: Grab Bag l Portal textures –Dan Aliaga and others l From-region visibility –Generalizes view-independent cell-portal problem l Linear-time view-independent portal cull box approach? –Nina Amenta and others l Modeling issues for cells-and-portals –Daniel Cohen-Or and others

13. Advanced Texturing: Stupid Texture Tricks David Luebke University of Virginia

14. Point Sprites l A point sprite is a screen-aligned textured quad placed by rendering a single vertex –Ideal for particle systems –When GL_POINT_SPRITE_NV is enabled: n Point antialiasing state ignored – all points  quads n Points are rendered with point width as usual n Tex coords of points can be replaced by special “point sprite” tex coords s,t,r between 0,1 n Tex coord r is special, can set to zero (default) or use to ‘play through’ an animation stored in 3D tex –Enable this with COORD_REPLACE_NV n For hardware acceleration on GF3, set r to 0 (default) and enable coordinate replacement for tex unit 3 only –See http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_point_sprite.txthttp://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_point_sprite.txt –See http://www.codesampler.com/oglsrc.htm; search for “point sprite”http://www.codesampler.com/oglsrc.htm

15. Billboards l A point sprite is a certain kind of billboard –Billboards are textured polygons (usually quads) that rotate to face the viewer n Build a rotation matrix for each billboard n Screen-aligned billboard: quad is parallel to the screen and has a constant up vector n Similar to old-school 2D sprites n Useful for text, HUDs, lens flare, etc n Build rotation matrix with camera u, n = -v, r=uXv n World-oriented billboard n Sprite’s native up vector not always appropriate n World-oriented billboard: use the world up vector n Still faces viewer  n = -v, r=uXv

16. Billboards l Viewpoint-aligned –v = vector to eye (Fig. 8.5) –Resulting quads capture perspective distortions across view-frustum –Ex: clouds (Fig 8.6) l Axially-alligned –Rotates around a fixed world-space axis –Ex: trees (Fig 8.7) –Problem: from above, look like cardboard cutouts

17. Imposters l An imposter is a billboard created on the fly to “cache” rendered imagery –Once rendered, cost of rendering an imposter is just a single textured quad –Can use for a few frames before updating –Can use for a few instances of the object l Works best on distant objects (why?) l Great example: portal textures –But what’s wrong with this idea?

18. Depth Sprites l Can render an object with a depth texture, so depth buffer affects and is affected by the rendering (Fig 8.16) –Can also do depth-affected lighting –Needs to be orthogonal or nearly orthogonal to look right –Under the right circumstances, might allow imposters with dynamic geometry n Ex: portal texture with monster moving around in the textured room

19. Imposters Continued l Depth meshes –UNC MMR system

20. Multitexturing l Modern hardware can read from multiple textures at once, even with mipmapping l Detail texturing l Light mapping l Bump mapping