1. CS 445: Introduction to Computer Graphics David Luebke University of Virginia Visibility Calculations and Occlusion Culling

2. Admin l Grades for assignment 1 should be out l Clipping assignment: how’s it going? –Sample solution (partial) on web

3. Demo l Videos

4. Recap: Visibility Culling l The basic idea: don’t render what can’t be seen –Off-screen: view-frustum culling –Occluded by other objects: occlusion culling –Generically: visibility calculation or visibility culling l The obvious question: why bother? –Off-screen geometry: solved by clipping –Occluded geometry: solved by Z-buffer l The (obvious) answer: efficiency –Clipping and Z-buffering take time linear to the number of primitives –Would like rendering to scale sublinearly

5. The Goal l Our goal: quickly eliminate large portions of the scene which will not be visible in the final image –Don’t want the exact visibility solution! –Want quick-and-dirty conservative estimate of which primitives might be visible n Z-buffer and clip this for the exact solution –This conservative estimate is the potentially visible set or PVS

6. Recap: View-Frustum Culling l An old idea (Clark 76): –Organize primitives into clumps –Before rendering the primitives in a clump, test a bounding volume against the view frustum n If the clump is entirely outside the view frustum, don’t render any of the primitives n If the clump intersects the view frustum, add to PVS and render normally n Common bounding volumes: spheres, axis-aligned bounding boxes n Other bounding volumes: oriented bounding boxes, ellipsoids, caplets, etc. l How big should the clumps be? –Choose minimum size so: cost testing bounding volume << cost clipping primitives –Organize clumps into a hierarchy of bounding volumes for more efficient testing n If a clump is entirely outside or entirely inside view frustum, no need to test its children

7. Cells & Portals l Goal: walk through architectural models (buildings, cities, catacombs) l These divide naturally into cells –Rooms, alcoves, corridors… l Transparent portals connect cells –Doorways, entrances, windows… l Notice: cells only see other cells through portals

8. Cells & Portals l An example:

9. Cells & Portals l Idea: –Cells form the basic unit of PVS –Create an adjacency graph of cells –Starting with cell containing eyepoint, traverse graph, rendering visible cells –A cell is only visible if it can be seen through a sequence of portals n So cell visibility reduces to testing portal sequences for a line of sight…

10. Cells & Portals A D H F CB E G H BCDFG EA

11. A D H F CB E G H BCDFG EA

12. A D H F CB E G H BCDFG EA

13. A D H F CB E G H BCDFG EA

14. A D H F CB E G H BCDFG EA

15. A D H F CB E G H BCDFG EA ? ?

16. A D H F CB E G H BCDFG EA X X

17. l View-independent solution: find all cells a particular cell could possibly see: C can only see A, D, E, and H A D H F CB E G A D H E

18. Cells & Portals l View-independent solution: find all cells a particular cell could possibly see: H will never see F A D H F CB E G A D CB E G

19. Cells and Portals l Questions: –How can we detect whether a given cell is visible from a given viewpoint? –How can we detect view-independent visibility between cells? l The key insight: –These problems reduce to eye-portal and portal-portal visibility

20. Cells and Portals l Airey (1990): view-independent only –Portal-portal visibility determined by ray-casting n Non-conservative portal-portal test resulted in occasional errors in PVS –Slow preprocess –Order-of-magnitude speedups

21. Cells and Portals: History l Teller (1993): view-independent + view-dependent –Portal-portal visibility calculated by line stabbing using linear program n Cell-cell visibility stored in stab trees n View-dependent eye-portal visibility stage further refines PVS at run time –Slow (?) preprocess –Elegant, exact scheme

22. Cells and Portals: History l Luebke & Georges (1995): view-dependent only –Eye-portal visibility determined by intersecting portal cull boxes –No preprocess (integrate w/ modeling) –Quick, simple hack –Now-archaic public-domain library: pfPortals

23. pfPortals Algorithm l Depth-first adjacency graph traversal –Render cell containing viewer –Treat portals as special polygons n If portal is visible, render adjacent cell n But clip to boundaries of portal! n Recursively check portals in that cell against new clip boundaries (and render) –Each visible portal sequence amounts to a series of nested portal boundaries n Kept implicitly on recursion stack

24. pfPortals Algorithm l Recursively rendering cells while clipping to portal boundaries not new –Visible-surface algorithm (Jones 1971): general polygon-polygon clipping n Elegant, expensive, complicated –Conservative overestimate (pfPortals): use portal’s cull box n Cull box = x-y screenspace bounding box n Cheap to compute, very cheap to intersect

25. pfPortals Algorithm l How badly does the cull box approximation overestimate PVS? l A: Not much for most architectural scenes l Note: Can implement mirrors as portals with an extra transformation! –Some clipping & Z-buffering issues –Must limit recursion

26. Cells and Portals: Details l Usually separate model into occluders and detail objects –Occluders: walls, floors –Detail objects: desks, chairs, pencils –Cell creation process only accounts for occluders (Why?) l pfPortals: find detail object visibility through portal sequences at run time l Teller: also precompute into PVS

27. Why View-Independent? l If view-dependent techniques can often calculate a reasonable PVS fast enough, why bother finding view- independent PVS? l One good answer: smart prefetching –Soda Hall walkthrough (Funkhouser) n Whole model doesn’t fit in memory n Use Teller stab trees to load in only cells that might be visible

28. Creating Cells and Portals l Given a model, how might you extract the cells and portals? –Airey: k-D tree (axis-aligned boxes) –Teller: BSP tree (general convex cells) –Luebke: modeler (any cells at all) l Problems and issues –Running time –Free cells –Intra-wall cells

29. Cells and Portals: Discussion l Good solution for most architectural or urban models –Use the simplest algorithm that suffices for your needs: n pfPortals-style algorithm: view-dependent solution, reasonably tight PVS, no preprocess necessary (except partition) n Teller-style algorithm: tighter PVS, somewhat more complex, can provide view-independent solution for prefetching

30. 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

31. General Occlusion Culling l I’ll discuss two algorithms: –Loose front-to-back sorting –Hierarchical Z-Buffer n Ned Greene, SIGGRAPH 93 l I’ll also describe current hardware support

32. Loose Front-To-Back Sorting l Can sort your geometry in roughly front-to-back order, e.g. by: –Using an octree/BSP tree –Sorting centroids or near points of bounding volumes l Why would this help? –A: Early rejection helps whole fragment pipeline

33. Image-Space Occlusion Culling l Many general occlusion culling algorithms use an image-space approach l Idea: solve visibility in 2D, on the image plane

34. 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

35. Hierarchical Z-Buffer l Idea: test polygon against highest level first –If polygon is further than distance recorded in pixel, stop—it’s occluded –If polygon is closer, recursively check against next lower level –If polygon is visible at lowest level, set new distance value and propagate up

36. 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

37. Hierarchical Z-Buffer l Exploiting object-space coherence: –Subdivide scene with an octree –All geometry in an octree node is contained by a cube –Before rendering the contents of a node, “render” the faces of its cube (i.e., query the Z-pyramid) –If cube faces are occluded, ignore the entire node

38. 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

39. 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 we’re getting there… –ATI HyperZ –Similar technology in NVIDIA –Both “under the hood”, not exposed to programmer l At the user level, hardware now supports occlusion queries

40. 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

41. 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

42. 111 uses for Occlusion Queries l Occlusion culling (duh) l Others? –Approximate culling –LOD size estimation –Lens flare effects –Transparency –Collision detection (!) –Convergence testing Side note: GL_ARB_OCCLUSION_QUERY is latest incarnation –Fixes a possible race condition in NV_occlusion_query logic