Occlusion Culling David Luebke University of Virginia

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

Cells & Portals l An example:

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…

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

A D H F CB E G H BCDFG EA

A D H F CB E G H BCDFG EA

A D H F CB E G H BCDFG EA

A D H F CB E G H BCDFG EA

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

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

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

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

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

Cells and Portals: History 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

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

Cells and Portals: History l 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 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

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

pfPortals Algorithm l How badly does the cull box approximation overestimate PVS? –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

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

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

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

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

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

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

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 l Why might this be hard? –A: could conflict with sorting by render state

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

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

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

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

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

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

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 something almost as good has emerged…

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

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

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

NV_OCCLUSION_QUERY : Details l Go to NVIDIA presentation…