CS 445: Introduction to Computer GraphicsDavid LuebkeUniversity of Virginia

Visibility Calculationsand Occlusion Culling

Admin Grades for assignment 1 should be out Clipping assignment: how’s it going?

– Sample solution (partial) on web

Demo Videos

Recap: Visibility Culling

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

The obvious question: why bother?– Off-screen geometry: solved by clipping– Occluded geometry: solved by Z-buffer

The (obvious) answer: efficiency– Clipping and Z-buffering take time linear to the

number of primitives– Would like rendering to scale sublinearly

The Goal 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 Z-buffer and clip this for the exact solution

– This conservative estimate is the potentially visible set or PVS

Recap: View-Frustum Culling

An old idea (Clark 76):– Organize primitives into clumps– Before rendering the primitives in a clump, test a bounding volume

against the view frustum If the clump is entirely outside the view frustum, don’t render any of the

primitives If the clump intersects the view frustum, add to PVS and render normally Common bounding volumes: spheres, axis-aligned bounding boxes Other bounding volumes: oriented bounding boxes, ellipsoids, caplets,

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

If a clump is entirely outside or entirely inside view frustum, no need to test its children

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

AD

H

FCB

E

G

H

B C D F G

EA

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

?

?

Cells & Portals

AD

H

FCB

E

G

H

B C D F G

EA

X

X

Cells & Portals View-independent solution: find all cells a particular cell could

possibly see:

C can only see A, D, E, and H

AD

H

FCB

E

G

AD

H

E

Cells & Portals View-independent solution: find all cells a particular cell could

possibly see:

H will never see F

AD

H

FCB

E

G

AD

CB

E

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 Airey (1990): view-independent only

– Portal-portal visibility determined by ray-casting 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 & 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

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? A: 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

Image-SpaceOcclusion Culling

Many 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 we’re getting there…– ATI HyperZ– Similar technology in NVIDIA– Both “under the hood”, not exposed to programmer

At the user level, hardware now supports occlusion queries

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 Occlusion Queries

Occlusion culling (duh) 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