Transcript ppt

Level of Detail & Visibility:
A Brief Overview, Cont.
David Luebke
University of Virginia
Project Advice


Lots of work, get started
Major tasks:
– Design the base class hierarchy
– Import 3D models, build sample scene
– Interface: Window system, camera control

May want to move beyond GLUT
– Traversals: LOD, visibility, top-down,
animation/BV update, etc.
– Project proposal writeup

Group dynamic tips
Summary: LOD Frameworks

Discrete LOD
– Generate a handful of LODs for each object

Continuous LOD (CLOD)
– Generate data structure for each object from which a
spectrum of detail can be extracted

View-dependent LOD
– Generate data structure from which an LOD
specialized to the current view parameters can be
generated on the fly.
– One object may span multiple levels of detail

Hierarchical LOD
– Aggregate objects into assemblies with their own LODs
Choosing LODs:
LOD Run-Time Management

Fundamental LOD issue: where in the
scene to allocate detail?
– For discrete LOD this equates to choosing
which LOD will represent each object
– Run every frame on every object; keep it fast
Choosing LODs

Describe a simple method for the system
to choose LODs
– Assign each LOD a range of distances
– Calculate distance from viewer to object
– Use corresponding LOD

How might we implement this in a scenegraph based system?
Choosing LODs

What’s wrong with this simple approach?
– Visual “pop” when switching LODs can be
disconcerting
– Doesn’t maintain constant frame rate; lots of
objects still means slow frame times
– Requires someone to assign switching
distances by hand
– Correct switching distance may vary with field
of view, resolution, etc.

What can we do about each of these?
Choosing LODs
Maintaining constant frame rate

One solution: scale LOD switching
distances by a “bias”
– Implement a feedback mechanism:


If last frame took too long, decrease bias
If last frame took too little time, increase bias
– Dangers:


Oscillation caused by overly aggressive feedback
Sudden change in rendering load can still cause
overly long frame times
Choosing LODs:
Maintaining constant frame rate


A better (but harder) solution: predictive
LOD selection
For each LOD estimate:
– Cost (rendering time)
– Benefit (importance to the image)
Choosing LODs:
Maintaining constant frame rate


A better (but harder) solution: predictive
LOD selection
For each LOD estimate:
– Cost (rendering time)




# of polygons
How large on screen
Vertex processing load (e.g., lighting) OR
Fragment processing load (e.g., texturing)
– Benefit (importance to the image)
Choosing LODs:
Maintaining constant frame rate


A better (but harder) solution: predictive
LOD selection
For each LOD estimate:
– Cost (rendering time)
– Benefit (importance to the image)






Size: larger objects contribute more to image
Accuracy: no of verts/polys, shading model, etc.
Priority: account for inherent importance
Eccentricity: peripheral objects harder to see
Velocity: fast-moving objects harder to see
Hysteresis: avoid flicker; use previous frame state
Choosing LODs:
Funkhouser & Sequin, SIGGRAPH 93

Given a fixed time budget, select LODs to
maximize benefit within a cost constraint
– Variation of the knapsack problem
– What do you think the complexity is?

A: NP-Complete (like the 0-1 knapsack problem)
– In practice, use a greedy algorithm




Sort objects by benefit/cost ratio, pick in sorted
order until budget is exceeded
Guaranteed to achieve at least 50% optimal sol’n
Time: O(n lg n)
Can use incremental algorithm to exploit coherence
Visibility

Next topic: visibility algorithms
– A.k.a. visibility culling
– A.k.a. occlusion culling
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
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
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 quickand-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
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
Efficient
View-Frustum Culling

How big should the clumps be?
– Choose minimum size so:
cost testing bounding volume << cost clipping primitives
– Choose minimum size so primitives can be rendered
efficiently

At least 500 triangles/clump on today’s hardware
– 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
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

Capsules, ellipsoids, k-DOPs
– …but most use spheres or AABBs.
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 + viewdependent
– 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
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
Still lots of issues for efficient culling