Transcript ppt
Occlusion Culling David Luebke University of Virginia Cells & Portals Goal: walk through architectural models (buildings, cities, catacombs) These divide naturally into cells – Rooms, alcoves, corridors… Transparent portals connect cells – Doorways, entrances, windows… Notice: cells only see other cells through portals Cells & Portals An example: Cells & Portals 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 So cell visibility reduces to testing portal sequences for a line of sight… Cells & Portals E A D B F C G H A B E C D H F G Cells & Portals E A D B F C G H A B E C D H F G Cells & Portals E A D B F C G H A B E C D H F G Cells & Portals E A D B F C G H A B E C D H F G Cells & Portals E A D B F C G H A B E C D H F G Cells & Portals E A D B C ? F G H A B E C D ? H F G Cells & Portals E A D B C X F G H A B E C D X H F G Cells & Portals View-independent solution: find all cells a particular cell could possibly see: E A D B F C G H C can only see A, D, E, and H Cells & Portals View-independent solution: find all cells a particular cell could possibly see: E A D B F C H H will never see F G Cells and Portals Questions: – How can we detect whether a given cell is visible from a given viewpoint? – How can we detect view-independent visibility between cells? The key insight: – These problems reduce to eye-portal and portal-portal visibility Cells and Portals: History Airey (1990): view-independent only – Portal-portal visibility determined by raycasting Non-conservative portal-portal test resulted in occasional errors in PVS – Slow preprocess – Order-of-magnitude speedups Cells and Portals: History Teller (1993): view-independent + view-dependent – Portal-portal visibility calculated by line stabbing using linear program Cell-cell visibility stored in stab trees View-dependent eye-portal visibility stage further refines PVS at run time – Slow preprocess – Elegant, exact scheme Cells and Portals: History Luebke (1995): view-dependent only – Eye-portal visibility determined by intersecting portal cull boxes – No preprocess (integrate w/ modeling) – Quick, simple hack – Public-domain library: pfPortals pfPortals Algorithm Depth-first adjacency graph traversal – Render cell containing viewer – Treat portals as special polygons If portal is visible, render adjacent cell But clip to boundaries of portal! Recursively check portals in that cell against new clip boundaries (and render) – Each visible portal sequence amounts to a series of nested portal boundaries Kept implicitly on recursion stack pfPortals Algorithm Recursively rendering cells while clipping to portal boundaries not new – Visible-surface algorithm (Jones 1971): general polygon-polygon clipping Elegant, expensive, complicated – Conservative overestimate (pfPortals): use portal’s cull box Cull box = x-y screenspace bounding box Cheap to compute, very cheap to intersect pfPortals Algorithm How badly does the cull box approximation overestimate PVS? – Not much for most architectural scenes Note: Can implement mirrors as portals with an extra transformation! – Some clipping & Z-buffering issues – Must limit recursion Cells and Portals: Details Usually separate model into occluders and detail objects – Occluders: walls, floors – Detail objects: desks, chairs, pencils – Cell creation process only accounts for occluders (Why?) pfPortals: find detail object visibility through portal sequences at run time Teller: also precompute into PVS Why View-Independent? If view-dependent techniques can often calculate a reasonable PVS fast enough, why bother finding view-independent PVS? One good answer: smart prefetching – Soda Hall walkthrough (Funkhouser) Whole model doesn’t fit in memory Use Teller stab trees to load in only cells that might be visible Creating Cells and Portals 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) Problems and issues – Running time – Free cells – Intra-wall cells Cells and Portals: Discussion Good solution for most architectural or urban models – Use the simplest algorithm that suffices for your needs: pfPortals-style algorithm: view-dependent solution, reasonably tight PVS, no preprocess necessary (except partition) Teller-style algorithm: tighter PVS, somewhat more complex, can provide view-independent solution for prefetching General Occlusion Culling When cells and portals don’t work… – Trees in a forest – A crowded train station Need general occlusion culling algorithms: – Aggregate occlusion – Dynamic scenes – Non-polygonal scenes General Occlusion Culling I’ll discuss two algorithms: – Loose front-to-back sorting – Hierarchical Z-Buffer Ned Greene, SIGGRAPH 93 I’ll also describe current hardware support Loose Front-To-Back Sorting 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 Why would this help? – A: Early rejection helps whole fragment pipeline Why might this be hard? – A: could conflict with sorting by render state Image-Space Occlusion Culling Most general occlusion culling algorithms use an image-space approach Idea: solve visibility in 2D, on the image plane Hierarchical Z-Buffer 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 Basic idea: hierarchical rasterization of the polygon, with early termination where polygon is occluded Hierarchical Z-Buffer 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 Hierarchical Z-Buffer Z-pyramid exploits image-space coherence: – Polygon occluded in a pixel is probably occluded in nearby pixels HZB also exploits object-space coherence – Polygons near an occluded polygon are probably occluded Hierarchical Z-Buffer 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 Hierarchical Z-Buffer 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 So start each frame by rendering octree nodes visible last frame Hierarchical Z-Buffer: Discussion HZB needs hardware support to be really competitive 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 But something almost as good has emerged… Modern Occlusion Culling 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? Test portal polygons before rendering adjacent cell Test object bounding boxes before rendering object – Yay! GL_HP_OCCLUSION_TEST extension – Problems: CPU/GPU synchronization == bad Might want to know “how visible” is the polygon Modern Occlusion Culling GL_NV_OCCLUSION_QUERY to the rescue – Non-blocking query “Is this occlusion query done yet?” Multiple queries in flight – Returns number of fragments visible Note: can actually render object or not Supports object-space coherence, temporal coherence Still lots of issues for efficient culling 111 uses for NV_OCCLUSION_QUERY Occlusion culling (duh) Others? – – – – – – Approximate culling LOD size estimation Lens flare effects Transparency Collision detection (!) Convergence testing NV_OCCLUSION_QUERY: Details Go to NVIDIA presentation…