Transcript PowerPoint

Visibility Culling
David Luebke
Computer Science Department
University of Virginia
<[email protected]>
Motivation
• Like most other rendering
acceleration techniques, the goal is
to avoid rendering redundant
geometry
• The basic idea: don’t render what
can’t be seen
– Off-screen: view-frustum culling
– Occluded by other objects: occlusion
culling
D2
Motivation
• 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
D3
The Goal
• Our goal: quickly eliminate large
portions of the scene which will not
be visible in the final image
– Not the exact visibility solution, but a
quick-and-dirty conservative estimate of
which primitives might be visible
• Z-buffer& clip this for the exact solution
– This conservative estimate is called the
potentially visible set or PVS
D4
Visibility Culling
• The remainder of this talk will
cover:
– View-frustum culling (briefly)
– Occlusion culling in architectural
environments
– General occlusion culling
D5
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
D6
Efficient
View-Frustum Culling
• 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
D7
Efficient
View-Frustum Culling
• What shape should bounding volumes
be?
– Spheres and axis-aligned bounding
boxes: simple to calculate, cheap to test
– Oriented bounding boxes converge
asymptotically faster in theory
– Lots of other volumes have been
proposed, but most people still use
spheres or AABBs.
D8
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
D9
Cells & Portals
• An example:
D10
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…
D11
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
F
G
H
D12
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
F
G
H
D13
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
F
G
H
D14
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
F
G
H
D15
Cells & Portals
E
A
D
B
F
C
G
H
A
B
E
C
D
F
G
H
D16
Cells & Portals
E
A
D
B
C
?
F
G
H
A
B
E
C
D
F
G
?
H
D17
Cells & Portals
E
A
D
B
C
X
F
G
H
A
B
E
C
D
X
H
F
G
D18
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
D19
Cells & Portals
• View-independent solution: find all cells a
particular cell could possibly see:
E
A
D
B
F
C
G
H
H will never see F
D20
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
D21
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
D22
Cells and Portals
• 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
D23
Cells and Portals
• 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
D24
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
D25
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 (constant time) to
intersect
D26
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
D27
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
D28
Why View-Independent?
• If view-dependent techniques can often
calculate a reasonable PVS fast enough,
why bother with view-independent
solutions?
• 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
D29
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
D30
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
D31
Cells and Portals:
Discussion
• Public-domain code I’m aware of:
– pfPortals: http://pfportals.cs.virginia.edu
• A very simple set of Performer callbacks that
implements cull-box portal culling
– pfWalkthru: http://home.earthlink.net/~mmchow/
• Includes code to extract cells and portals
– Game engine sites
• Lots of “level builders” and “level compilers”
• Treat these with a grain of salt
D32