Recap:
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
Recap: Image-Space
Occlusion Culling

Most general occlusion culling algorithms
use an image-space approach
– Idea: solve visibility in 2D, on the image plane
– Note: gives up view-independent visibility
Recap:
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
Recap:
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
Recap:
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 there are promising trends:
– ATI’s HYPER-Z technology: one-level HZB
– 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
Modern Occlusion Culling

GL_ARB_OCCLUSION_QUERY
– Deprecates NV_OCCLUSION_QUERY
– Fixes a potential race condition
111 uses for
NV_OCCLUSION_QUERY


Occlusion culling (duh)
Others?
–
–
–
–
–
–
Approximate culling
LOD size estimation
Lens flare effects
Transparency
Collision detection (!)
Convergence testing
NV_OCCLUSION_QUERY:
Details

Go to NVIDIA presentation…
Occlusion Culling:
Grab Bag

Portal textures
– Dan Aliaga and others

From-region visibility
– Generalizes view-independent cell-portal
problem

Linear-time view-independent portal cull
box approach?
– Nina Amenta and others

Modeling issues for cells-and-portals
– Daniel Cohen-Or and others
Advanced Texturing:
Stupid Texture Tricks
David Luebke
University of Virginia
Point Sprites

A point sprite is a screen-aligned textured quad
placed by rendering a single vertex
– Ideal for particle systems
– When GL_POINT_SPRITE_NV is enabled:



Point antialiasing state ignored – all points  quads
Points are rendered with point width as usual
Tex coords of points can be replaced by special “point sprite”
tex coords s,t,r between 0,1


–
–
Tex coord r is special, can set to zero (default) or use to ‘play
through’ an animation stored in 3D tex
– Enable this with COORD_REPLACE_NV
For hardware acceleration on GF3, set r to 0 (default) and
enable coordinate replacement for tex unit 3 only
See http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_point_sprite.txt
See http://www.codesampler.com/oglsrc.htm; search for “point sprite”
Billboards

A point sprite is a certain kind of billboard
– Billboards are textured polygons (usually
quads) that rotate to face the viewer


Build a rotation matrix for each billboard
Screen-aligned billboard: quad is parallel to the
screen and has a constant up vector




Similar to old-school 2D sprites
Useful for text, HUDs, lens flare, etc
Build rotation matrix with camera u, n = -v, r=uXv
World-oriented billboard



Sprite’s native up vector not always appropriate
World-oriented billboard: use the world up vector
Still faces viewer  n = -v, r=uXv
Billboards

Viewpoint-aligned
– v = vector to eye (Fig. 8.5)
– Resulting quads capture perspective
distortions across view-frustum
– Ex: clouds (Fig 8.6)

Axially-alligned
– Rotates around a fixed world-space axis
– Ex: trees (Fig 8.7)
– Problem: from above, look like cardboard
cutouts
Imposters

An imposter is a billboard created on the
fly to “cache” rendered imagery
– Once rendered, cost of rendering an imposter
is just a single textured quad
– Can use for a few frames before updating
– Can use for a few instances of the object


Works best on distant objects (why?)
Great example: portal textures
– But what’s wrong with this idea?
Depth Sprites

Can render an object with a depth texture,
so depth buffer affects and is affected by
the rendering (Fig 8.16)
– Can also do depth-affected lighting
– Needs to be orthogonal or nearly orthogonal
to look right
– Under the right circumstances, might allow
imposters with dynamic geometry

Ex: portal texture with monster moving around in
the textured room
Imposters Continued

Depth meshes
– UNC MMR system
Multitexturing




Modern hardware can read from multiple
textures at once, even with mipmapping
Detail texturing
Light mapping
Bump mapping