Visibility Culling
description
Transcript of Visibility Culling
Visibility Culling
Roger A. Crawfis
CIS 781
The Ohio State University
Interactive Frame Rates Are Difficult To Achieve
The Problem
• Two keys for an interactive system– Interactive rendering speed: too many polygons
– difficult!! – Uniform frame rate: varied scene complexity –
difficult!!
Possible Solutions
• Visibility Culling – back face culling, frustum culling, occlusion culling (might not be sufficient)
• Levels of Detail (LOD) – hierarchical structures and choose one to satisfy the frame rate requirement
LOD Selections
How to pick the Optimal ones??!!
Occlusion Culling
• Hidden Surface Removal methods are not fast enough for massive models on current hardware
• Occlusion Culling avoids rendering primitives that are occluded by another part of the scene
• Occlusion Culling techniques are ideally output sensitive – runtime is proportional to the size of exact visibility set
Related Work
• Hierarchical Z-Buffer– Image space occlusion culling method [Greene’93]
– Build a layered Z-pyramid with a different resolution of the Z-buffer at each level
– Allows quick accept/reject
• Hierarchical LODs– Simplification Culling : Approximate entire branch of
the scene graph by an HLOD
– Can we use HLODs as occluders/occludees?
Visibility in Games
• What do we need it for?– Increase of rendering speed by removing
unseen scene data from the rendering pipeline as early as possible
– Reduction of data transfers to the graphics hardware
– Current games would not be possible without visibility calculations
Visibility methods
• 2 very different categories:– Visibility from a region (Portals, PVS)
• (Quake, Unreal, Severance and co.)
– Visibility from a point (Z-Buffer, BFC,...)• Racing games, outdoor scenes, sports games etc.
Point-Visibility Occlusion
• Traditionally used:– Back-Face culling– Z-Buffering– View frustum culling
• Octree
• Quadtree
A PSX Example
• Iron Soldier 3 on PSX:– View frustum culling based on a quad-tree– Back-face culling– Painters algorithm
Only culling to the leftand right sides of the
viewing frustum.
New Occlusion Methods
• Image-space occlusion culling– Hierarchical Z-Buffering– Hierarchical Occlusion Maps
• Object-space occlusion culling– Hierarchical View Frustum culling– Hierarchical Back-Face culling
Visibility Culling
• We will look at these:– Hierarchical Back-face culling – View-frustum culling – Occlusion culling – Detail culling
Hierarchical Back-Face Culling• Partitions each model into clusters
• Primitives in one cluster are:– Facing into similar directions– Lie close to each other
• If the cluster fails the visibility test, all primitives in this cluster are culled
Hierarchical Back-Face Culling
Normal Maps
• Create a data structure that places each polygon in the space according to its normal direction.
• Partition this space and then simply look at those partitions that might have visible polygons.
theta
phi
View-Frustum Culling
• Remove objects that are outside the viewing frustum
1. Construct bounding volumes (BVs)2. Create hierarchy3. BV/V-F intersection tests
Mostly done in “Application Stage”
View-Frustum Culling
• Culling against bounding volumes to save time
• Bounding volumes – AABB, OBB, Spheres, etc. – easy to compute, as tight as possible
AABB Sphere OBB
View-Frustum Culling
• Often done hierarchically to save time
In-order, top-downtraversal and test
View-Frustum Culling
• Two popular hierarchical data structures – BSP Tree and Octree
Axis-Aligned BSP Polygon-Aligned BSP
Intersecting?
View-Frustum Culling
• Octree• A parent has 8 childrens
• Subdivide the space until the number of primitives within each leaf node is less than a threshold
• In-order, top-down traversal
Hierarchical Z-Buffer
• Z-Buffer is arranged in an image pyramid.
• Scene is partitioned in an octree.
• Octree nodes are tested against the Z-Pyramid where pixels have the same size.
• Visible nodes serve as input for the next frame.
• Relies on HW visibility query.
HZB/Hierarchical occlusion maps
Hierarchical occlusion maps
• Potential occluders are pre-selected
• These occluders are rendered to the occlusion map. The hierarchy can be built with MIP-Mapping HW
• Depth test after occlusion test
• Separate depth estimation buffer
Hierarchical View Frustum Culling
• Speeds up VFC by testing only 2 box corners of a bounding box first.
• Plane coherency during frame advancing
• Test against VF-octants.
• BB-Child masking
Detail Culling
• A technique that sacrifices quality for speed
• Base on the size of projected BV – if it is too small, discard it.
• Also often done hierarchically.
Always helps to create a hierarchical structure, or scene graph.
Occlusion Culling
• Discard objects that are occluded
• Z-buffer is not the smartest algorithm in the world (particularly for high depth-
complexity scenes)
• We want to avoid the processing of invisible objects
Occlusion Culling
OcclusionCulling (G) Or = empty For each object g in G if (isOccluded(g, Or))
skip g else
render (g) update (Or) end End
G: input graphics dataOr: occlusion representation
The problem: 1. algorithms for isOccluded()2. Fast update Or
Hierarchical Visibility
• Object-space octree– Primitives in a octree node are hidden if the
octree node (cube) is hidden– A octree cube is hidden if its 6 faces are hidden
polygons – Hierarchical visibility test:
Hierarchical Visibility (obj-sp.)
From the root of octree: • View-frustum culling • Scan conversion each of the 6 faces and perform
z-buffering • If all 6 faces are hidden, discard the entire node
and sub-branches• Otherwise, render the primitives here and traverse
the front-to-back children recursively A conservative algorithm – why?
• Scan conversion the octree faces can be expensive – cover a large number of pixels (overhead)
• How can we reduce the overhead?
• Goal: quickly conclude that a large polygon is hidden
• Method: use hierarchical z-buffer !
Hierarchical Visibility (obj-sp.)
Hierarchical Z-buffer
An image-space approach
• Create a Z-pyramid
Original Z-buffer
½ resolution
¼ resolution
1 value
Hierarchical Z-buffer (2)
7 1 0 60 3 1 2
3 9 1 2
9 1 2 2
7 6
9 29
Keep the maximum value
Hierarchical Z-buffer
Visibility (OctreeNode N) if (isOccluded (N, Zp) then return; for each primitive p in N render and update Zp end for each child node C of N in front-to-back order Visibility ( C ) end
update
Some Practical Issues
• A fast software algorithm
• Lack of hardware support – Scan conversion – Efficient query of if a polygon is visible
(without render it)– Z feedback
Combining with hardware
• Utilizing frame-to-frame coherence – First frame – regular HZ algorithm (software)
• Remember the visible octree nodes
– Second frame (view changes slightly)• Render the previous visible nodes using OpenGL
• Read back the Z-buffer and construct Z-pyramid
• Perform regular HZ (software)
– What about the third frame?
– Utilizing hardware to perform rendering and Z-buffering – considerably faster
Hierarchical Occlusion Map
Zhang et al
SIGGRAPH 98
Basic Ideas
• Choose a set of graphics objects from the scene as Occluders
• Use the occluders to define an Occlusion Map (hierarchically)
• Compare the rest of scene against the occlusion map
Example
Blue: OccludersRed: Occludees
Algorithm Pipeline
Occluder Viewing Frustum Occluder Rendering Database Culling Selection
Build Occlusion Map Hierarchy
Real Viewing Frustum Occlusion Test Scene Culling
2-Step Occlusion Test
1. Overlap Test 2. Overlap Test Overlap + Depth = Occlusion
Why decomposition?
• The occlusion test is done approximately (conservatively)
• We can afford to be more conservative in depth test than overlap test
Why Decomposition?
Overlap Test – Occlusion Map
• Representation of projection for overlap test: occlusion map
• A gray scale image – each pixel represents one block of screen region
• Generate by rendering occluders
Occlusion Map (OM)
• Each pixel of the occlusion map has an opacity, which represents the ratio of the sum of the opaque areas in the block to the total area.
• If fully covered, p= 1, if anti-alised pixel, p <1)
• Occlusion map: the alpha channel of an image
Overlap Test using OM
For each potential occludee, we can scan-convert it and compare against the opacity of the pixels itoverlaps Expensive!!
• Conservative Approximation: use the screen-space bounding box of the occludee (a superset of the actual covered pixels) • If all the pixels inside the bounding box are opaque, the object is occluded.
Hierarchical Occlusion Map
Like hierarchical Z-buffer, we can create a hierachy to speed up the comparison (for large objects)
The low resolution pixel is an average of the high resolution pixels
Overlap Test using HOM
1. Start from the lowest resolution2. If the pixel cover the bounding rectangle has a value 1, the object is occluded3. Otherwise traverse down the hierarchy:
• If all children =1: occluded• If all children =0; not occluded• Otherwise, traverse down further
Basic Algorithm
Approximate Overlap Test
• Instead of concluding an object is occluded only when the bounding box is within pixels with opacity 1, we can use an threshold between [0,1]
• Early termination in the high level of the hierarchy • What does it mean when a block has high opacity
but not one?
This is the unique feature of HOM !!
Depth Test
Approximate Z (depth) test:
• A single Z Plane A single Z plane to separate the occluders fromoccludees.
Depth Test
Break the screen into small regions
• Build at each frame• Instead of using Z-buffer, use the occluder’s bounding volume’s farthest Z • Compare each potential occludee’s nearest Z (con- servative test)
Occluder Selection
Ideal occluder: the visible objects – it’s a jokeView-dependent occluder: too expensive Solution: Estimate and build an occluder database
Discard objects that do not server as good occluders
Occluder Selection
• Size: not too small• Redundant: detail polygons (clock on the
wall)• Complexity: Complex polygons are not
preferred (why?)• Done at run time – sort the occluders in
depth, add them in order until reach the polygon count.
OPS
– View-independent Occluders
X
Z
OPS
– View-dependent Occluders
Occludders– In practice, use traditional, static LOD’s
• More restrictive view-independent OPS
• Well-studied and available
• Low run-time overhead
• Shared with final rendering, no extra memory
• Area-preserving [Erikson 98]
Occluder selection
• At run time– Distance-based selection with a polygon budget– Temporal coherence
• Visibility sampling– Pre-compute visible objects on a 3-D grid– Facilitates run-time selection
Implementation
• A two-pass framework
ViewViewFrustumFrustumCullingCulling
Build OcclusionBuild OcclusionRepresentationRepresentation
SceneScene
DatabaseDatabase
OccluderOccluderSelectionSelection
RenderingRendering
OcclusionOcclusionCullingCulling
LODLOD
LODLOD
Results
• The city model
Results
• The city model– 312,524 polygons– Single CPU– 5,000 occluder polygons– Depth estimation buffer– Opacity thresholds 1.0– Lighting; display lists; no triangle strips
Results
0
10
20
30
40
50
60
70
80
90
1 201 401 601
Frame #
Fram
e ra
te (f
ps)
OC+VFC
VFC+Only
Results
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
160,000
180,000
200,000
220,000
240,000
260,000
280,000
300,000
320,000
1 201 401 601
Frame #
Nu
mb
er
of
rem
ain
ing
tri
an
gle
s
Total
after VFC
after VFC+OC
Ideal
Results
• Auxiliary Machine Room (AMR)
Results
•AMR– 632,252 polygons– 3 CPUs– 25,000 occluder polygons– No-background z-buffer– Approximate culling (0.85 for level 64x64)– LOD– Lighting; display lists; no triangle strips
Results
0
1
2
3
4
5
6
7
8
1 201 401
Frame #
Fra
me r
ate
(fp
s)
LOD+VFC+OC
LOD+VFC
Results
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
1 201 401
Frame #
Nu
mb
er
of
rem
ain
ing
tri
an
gle
s
Original model
After LOD
After LOD+VFC
After LOD+VFC+OC
Ideal
Results
60,000
80,000
100,000
120,000
140,000
160,000
180,000
1 201 401
Frame #
Nu
mb
er o
f tr
ian
gle
s cu
lled
by
OC
OT=1.0
OT=0.8
Results
• The power plant model
Results
•The power plant model– 15 million triangles– 3 CPUs– Visibility pre-processing on a 20x20 grid (~15min)– No-background z-buffer– 18,000 occluder polygons– opacity thresholds from 0.85 and up– LOD
Results
0
2
4
6
8
10
12
14
16
18
1 201 401
Frame #
Fra
mes
rat
e (f
ps)
LOD+VFC+OC
LOD+VFC
-
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
1 201 401
Frame #
Nu
mb
er o
f re
mai
nin
g p
oly
go
ns
After LOD+VFC
After LOD+VFC+OC
Ideal
11,400,000
12,400,000
13,400,000
14,400,000
1
Original model
After LOD
Conclusion
•Goals achieved– Generality
• Any model, any occluder• Occluder fusion
– Speed-up• Accelerate interactive graphics
– Ease of implementation• Configurability• Robustness
HP hardware occlusion
• Extend OpenGL – add an OCCLUSION_MODE• The bounding box of an object is scan converted• A flag is set if any pixel of the BB faces is visible• Only need to read back one flag, instead of the
entire frame buffer • Tradeoff – valuable rendering time is used to
render useless BB faces (need to be used wisely)• Reportedly 25%-100% speedup were observed
The Real World
• Scientific approaches often too complicated
• Science often uses models with hundreds of thousands of vertices, games don’t. (LOD)
• Game developers “pick” ideas from different algorithms
• Research has impact on hardware design!
Gaming Industry
• Parts of the Hierarchical Z-Buffer (HZB) are used sometimes
• Runtime-LOD is used as input for a simple HZB• View Frustum Culling (VFC) is almost always
used. • Hierarchical Occlusion Maps introduce too much
overhead for games, and the z-buffer is there anyway
The Real World (3)
• PSX-One doesn’t even have a z-buffer • ATI’s Radeon has parts of a HZB (Called
Hyper-Z)• GForce2 only has a z-buffer• GForce3 similar to Radeon, but supports
HZB visibility query• Dreamcasts Power-VR2 works pretty
different (Infinite planes)
Conclusions
• Visibility algorithms are used in many different applications– Occlusion culling– Shadow calculations– Radiosity– Volumetric lights
• All these fields benefit from advances in visibility techniques
Recap
• Visibility culling: don’t render what can’t be seen– Off-screen: view-frustum culling– Z-buffered away: occlusion culling
• Cells and portals– Works well for architectural models– Teller: accurate, complex, a bit slow– pfPortals: fast, cheap, easy
Hierarchical Z-Buffer
• Q: What do you think this is?
• Replace Z-buffer with a Z-pyramid– Lowest level: full-resolution Z-buffer– Higher levels: each pixel represents what?
• A: Maximum distance of geometry visible to the four pixels “underneath” it
• Q: How is this going to help?
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
• Amounts to hierarchical rasterization of the polygon, with early termination– Must update higher levels as we go
Hierarchical Z-Buffer
• Z-pyramid exploits image-space coherence: polygon occluded in one pixel is probably occluded nearby
• HZB also exploits object-space coherence: polygons near an occluded polygon are probably occluded
• Q: How might you use object-space coherence?
Hierarchical Z-Buffer
• 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• If cube faces are occluded, ignore the entire
node• Query Z-pyramid to “render” cubes
Hierarchical Z-Buffer
• Exploit temporal coherence (What?)• HZB operates at max efficiency when Z-
pyramid is already built• Idea: most polygons affecting Z-buffer
(“nearest polygons”) are the same from frame to frame
• So start by rendering the polygons (octree nodes) visible last frame
Hierarchical Occlusion MapsHierarchical Occlusion Mapsstolen by Dave Luebke from thestolen by Dave Luebke from thePh.D. Defense presentation of:Ph.D. Defense presentation of:
Hansong Zhang
Department of Computer ScienceUNC-Chapel Hill
Visibility Culling
• Discard objects not visible to the viewer
View
Point
View-frustum cullingView-frustum culling
Back-face cullingBack-face culling
Occlusion cullingOcclusion culling
ViewFrustum
Hierarchical Occlusion Maps: Overview
Blue parts: Blue parts: occludersoccluders Red parts: Red parts: occludeesoccludees
Effective Algorithms
•Generality• Arbitrary models
•Speed-up• Significant, fast culling for interactive graphics
•Portability• Few hardware assumptions
• Robustness
Thesis Statement
• By properly decomposing the occlusion-culling problem and efficiently representing occlusion, we can obtain effective algorithms and systems for occlusion culling.
Observations
• Want to handle cumulative occlusion
ViewPoint
A
B
Observations
• Want an occlusion representation (OR)– Fast to compute– Fast to use
ViewPoint
A
B
Observations
•Progressive occlusion culling
Initialize OR to nullfor each object
Occlusion test against ORif culled
Discard objectelse
Render objectUpdate OR
Observations
•Multi-pass occlusion cullingInitialize OR to null; initialize PO to emptyfor each object
Occlusion test against ORIf culled
Discard objectelse
Render objectAdd object to POif PO is large enough
Update OR with objects in PO#passes = #updates#passes = #updates
The set of The set of ppotential otential ooccludersccluders
Observations
• Special case: one-pass occlusion culling– Select occluders until PO is large enough– Update (build) occlusion representation– Occlusion culling & final rendering
Problem Decomposition
•
ViewPoint
ZX
Y
• Occlusion = depth + overlap • Occlusion = depth + overlap
Problem Decomposition
• Verifying occlusion
– Overlap tests
• Based on representations for projection
– Depth tests
• Based on representations for depth
Rendered Image Occlusion Map
Occlusion Maps
Occlusion Maps– An occlusion map
• Corresponds to a screen subdivision
• Records average opacity for each partition
– Can be generated by rendering occluders• Record pixel opacities (pixel coverage)
– Merge projections of occluders– Represent occlusion in image-space
Occlusion Map Pyramid
64 x 64 32 x 32 16 x 16
Occlusion Map Pyramid
Occlusion Map Pyramid
•Analyzing cumulative projection
– A hierarchy of occlusion maps (HOM)
– Made by recursive averaging (low-pass filtering)
– Record average opacities for blocks of pixels
– Represent occlusion at multiple resolutions
– Construction accelerated by hardware
Overlap Tests
– Problem: is the projection of tested object inside the cumulative projection of the occluders?
– Cumulative projection of occluders: the pyramid– Projection of the tested object
• Conservative overestimation– Bounding boxes (BB)
– Bounding rectangles (BR) of BB’s
Overlap Tests
• The basic algorithmGiven: HOM pyramid; the object to be testedGiven: HOM pyramid; the object to be tested• Compute BR and the initial level in the pyramidCompute BR and the initial level in the pyramid• for each pixel touched by the BRfor each pixel touched by the BR
if pixel is fully opaqueif pixel is fully opaquecontinuecontinue
else else if level = 0if level = 0
return FALSEreturn FALSEelseelse
descend...descend...
Overlap Tests
• Evaluating opacity: early termination– Conservative rejection– Aggressive approximate culling– Predictive rejection
Conservative Rejection
– A low-opacity pixel does not correspond to many high-opacity pixels at finer levels
– The transparency threshold
1 1 1 1
1 0.8 1 1
0.9 0.9 0.1 0
0.2 0.3 0 0
Aggressive Approximate Culling
•Ignoring barely-visible objects– Small holes in or among objects – To ignore the small holes
• LPF suppresses noise — holes “dissolve”
• Thresholding: regard “very high” opacity as fully opaque
– The opacity threshold: the opacity above which a pixel is considered to be fully opaque
Aggressive Approximate Culling
0 1 2 3 4
Aggressive Approximate culling
– Further descent not necessary when fully opaque • Tests terminated before holes are reached
– Need different opacity thresholds for each level
Predictive Rejection
– Terminate the test knowing it must fail later...
1 1 1 1
1 0.8 1 1
1 1 1 0
0.2 0.3 0 0
Summary: Levels of Visibility
• The continuum between being visible and non-visible
Almost transparentAlmost transparent
(low opacity)(low opacity)
Almost opaqueAlmost opaque
(high opacity)(high opacity)
Almost visibleAlmost visible
Almost non-visibleAlmost non-visible
Occlusion MapsOcclusion Maps Potential OccludeesPotential Occludees
Resolving Depth
• What’s left of the occlusion test?
BB
AA
““A occludes B” = “A’s projection contains B’s” + A occludes B” = “A’s projection contains B’s” + ??
B does not B does not occlude occlude anyany part of Apart of A
Another interpretation...Another interpretation...
Resolving Depth
• Depth representations– Define a boundary beyond which an object
overlapping occluders is definitely occluded– Conservative estimates:
• A single plane
• Depth estimation buffer
– No-background z-buffer
A single plane
The point with nearest depth
Occluders
Viewing direction
This object passes the depth test
The plane
A
Imageplane
• … at the farthest vertex of the occluders• … at the farthest vertex of the occluders
Depth Estimation Buffer
• Like a low-res depth buffer– Uniform subdivision of the screen– A plane for each partition– Defines the far boundary– Updates (i.e. computing depth representation)
• Occluder bounding rectangle at farthest depth
– Depth tests• Occudee bounding rectangle at nearest depth
Depth Estimation Buffer
Bounding Bounding rectangle at rectangle at nearest depthnearest depth
D. E. B.D. E. B.
OccludersOccluders
AA
Viewing Viewing directiondirection
Transformed view-frustumTransformed view-frustum
Bounding rectangle Bounding rectangle at farthest depthat farthest depth
BB
ImageImageplane plane
Depth Estimation Buffer
•Trade-off– Advantages
• Removes need for strict depth sorting
• Speed
• Portability
– Disadvantages• Conservative far boundary
• Requires good bounding volumes
No-Background Z-Buffer– The z-buffer from occluder rendering...
• is by itself an full occlusion representation
• has to be modified to support our depth tests
– “Removing” background depth values• Replace them the “foreground” depth values
– Captures the near boundary
No-Background Z-Buffer
D. E. BD. E. B
OccludersOccluders
N. B. ZN. B. ZAAViewing Viewing
directiondirection
Transformed view-frustumTransformed view-frustum
Objects passing Objects passing the depth teststhe depth tests
ImageImageplane plane
No-Background Z-Buffer
• Trade-off– Advantages
• Captures the near boundary
• Less sensitive to bounding boxes
– Disadvantages• Assumes quickly accessible z-buffer
• Resolution same as occlusion maps (however…)
Occluder Selection
– Occlusion-preserving simplification (OPS)
– Run-time selection
– Visibility pre-processing
OPS
– View-independent OPS
X
Z
OPS
– View-dependent OPS
OPS– In practice, use traditional, static LOD’s
• More restrictive view-independent OPS
• Well-studied and available
• Low run-time overhead
• Shared with final rendering, no extra memory
• Area-preserving [Erikson 98]
– Conservative OPS (COPS)...
Occluder selection
• At run time– Distance-based selection with a polygon budget– Temporal coherence
• Visibility sampling– Pre-compute visible objects on a 3-D grid– Facilitates run-time selection
Implementation
• A two-pass framework
ViewViewFrustumFrustumCullingCulling
Build OcclusionBuild OcclusionRepresentationRepresentation
SceneScene
DatabaseDatabase
OccluderOccluderSelectionSelection
RenderingRendering
OcclusionOcclusionCullingCulling
LODLOD
LODLOD
Implementation
• Pipelining
FinalDrawN OccDrawN
+1
OccDraw
N
FinalDrawN+1 OccDrawN+2FinalDrawN+
1
OccSelN OccSelN+1 OccSelN+2 OccSelN+3
CullN CullN+1 CullN+2
Implementation
– Uses bounding volume hierarchy– Active layers of the pyramid: 4x4 - 64x64– Resolutions
• Occluder rendering - 256x256• D. E. B. - 64x64
– Test platforms• SGI Onyx II, 4 195Mhz R10000, InfiniteReality• SGI Onyx I, 4 250MHz R4400, InfiniteReality
Results
• The city model
Results
• The city model– 312,524 polygons– Single CPU– 5,000 occluder polygons– Depth estimation buffer– Opacity thresholds 1.0– Lighting; display lists; no triangle strips
Results
0
10
20
30
40
50
60
70
80
90
1 201 401 601
Frame #
Fram
e ra
te (f
ps)
OC+VFC
VFC+Only
Results
0
20,000
40,000
60,000
80,000
100,000
120,000
140,000
160,000
180,000
200,000
220,000
240,000
260,000
280,000
300,000
320,000
1 201 401 601
Frame #
Nu
mb
er
of
rem
ain
ing
tri
an
gle
s
Total
after VFC
after VFC+OC
Ideal
Results
• Auxiliary Machine Room (AMR)
Results
•AMR– 632,252 polygons– 3 CPUs– 25,000 occluder polygons– No-background z-buffer– Approximate culling (0.85 for level 64x64)– LOD– Lighting; display lists; no triangle strips
Results
0
1
2
3
4
5
6
7
8
1 201 401
Frame #
Fra
me r
ate
(fp
s)
LOD+VFC+OC
LOD+VFC
Results
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
1 201 401
Frame #
Nu
mb
er
of
rem
ain
ing
tri
an
gle
s
Original model
After LOD
After LOD+VFC
After LOD+VFC+OC
Ideal
Results
60,000
80,000
100,000
120,000
140,000
160,000
180,000
1 201 401
Frame #
Nu
mb
er o
f tr
ian
gle
s cu
lled
by
OC
OT=1.0
OT=0.8
Results
• The power plant model
Results
•The power plant model– 15 million triangles– 3 CPUs– Visibility pre-processing on a 20x20 grid (~15min)– No-background z-buffer– 18,000 occluder polygons– opacity thresholds from 0.85 and up– LOD
Results
0
2
4
6
8
10
12
14
16
18
1 201 401
Frame #
Fra
mes
rat
e (f
ps)
LOD+VFC+OC
LOD+VFC
-
100,000
200,000
300,000
400,000
500,000
600,000
700,000
800,000
1 201 401
Frame #
Nu
mb
er o
f re
mai
nin
g p
oly
go
ns
After LOD+VFC
After LOD+VFC+OC
Ideal
11,400,000
12,400,000
13,400,000
14,400,000
1
Original model
After LOD
Conclusion
•Goals achieved– Generality
• Any model, any occluder• Occluder fusion
– Speed-up• Accelerate interactive graphics
– Ease of implementation• Configurability• Robustness
Conclusion• Main contributions:
– Problem decomposition• Overlap tests and depth tests
– Occlusion representations• Occlusion maps• Depth Estimation Buffer• No-Background Z-Buffer
Conclusion
• Main contributions– Hierarchical occlusion maps
• Analysis of occlusion at multiple resolutions• High-level opacity estimation• Aggressive approximate culling• Levels of visibility
– The first occlusion culling algorithm for general models and interactive 3-D graphics
Future Work
•Other implementations...– PC’s and games
• How much can be done in software?
– Integration into hardware• More progressive updates to occlusion representation
• Less conservative culling
– Wide-spread use of occlusion culling
Early Splat Elimination
• Need: splat visibility test– a voxel is only visible if the volume material in
front is not opaque
occluded voxel: does not pass visibility test
wall of occluding voxels
occlusion map = opacity image
screen
Visibility Test - Naive
• Check opacity of every pixel within footprint– number of pixels to be checked is large
opaque area
voxel footprint
voxel kernel
opacity buffe
r
Visibility Test - Efficient
• Compute occlusion map after each sheet-buffer compositing
opacity threshold
occlusion map
project do not project
opacity < threshold
opacity = 0
IEEE Trans. Vis. and Comp. Graph. ‘99
Early Splat Elimination - Results
standard early elim. voxels splattedHead (2563) 54.6 s 12.7 s 3 %Transp. head 35.8 s 14.8 s 21 %Nerve (512x76) 17.6 s 8.4 s 10 %Tomato (2563) 36.8 s 15.5 s 37 %