CS 445: Introduction to Computer GraphicsDavid LuebkeUniversity of Virginia

Visibility: The Z-bufferVisibility Culling

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

– Sample solution (partial) on web

Demo Videos

Recap: Painter’s Algorithm

Simple approach: render the polygons from back to front, “painting over” previous polygons:

– Draw blue, then green, then pink

Recap: Painter’s Algorithm

Intersecting polygons present a problem Even non-intersecting polygons can form a cycle with no valid

visibility order:

Even without such a cycle, not obvious how to sort (ex: cube)

Recap: Analytic Visibility Algorithms

Early visibility algorithms computed the set of visible polygon fragments directly, then rendered the fragments to a display:

– Now known as analytic visibility algorithms

Recap: Analytic Algorithms Worst Case

Minimum worst-case cost of computing the fragments for a scene composed of n polygons: O(n2) visible fragments

Recap: Analytic Visibility Algorithms

So, for about a decade (late 60s to late 70s) there was intense interest in finding efficient algorithms for hidden surface removal

We’ll talk about two: – Binary Space-Partition (BSP) Trees– Warnock’s Algorithm

Recap: BSP Trees Binary Space Partition tree: organize all of space (hence

partition) into a binary tree– Preprocess: overlay a binary tree on objects in the scene– Runtime: correctly traversing this tree enumerates objects

from back to front– Idea: divide space recursively into half-spaces by choosing

splitting planes Splitting planes can be arbitrarily oriented Notice: nodes are always convex

Recap: BSP Trees

1 2 3

45

6 78

9

1

3568

7 9 2 4

Recap: BSP Tree Construction for Polygons

Split along the plane containing any polygon Classify all polygons into positive or negative half-space

of the plane– If a polygon intersects plane, split it into two

Recurse down the negative half-space Recurse down the positive half-space

Recap: BSP Tree Traversal for Polygons

Query: given a viewpoint, produce an ordered list of (possibly split) polygons from back to front:

BSPnode::Draw(Vec3 viewpt)Classify viewpt: in + or - half-space of node->plane?// Call that the “near” half-space

farchild->draw(viewpt);render node->polygon; // always on node->planenearchild->draw(viewpt);

Intuitively: at each partition, draw the stuff on the farther side, then the polygon on the partition, then the stuff on the nearer side

BSP Demo Nice demo:

– http://symbolcraft.com/graphics/bsp/index.html – Also has a link to the BSP Tree FAQ

Summary: BSP Trees Pros:

– Simple, elegant scheme– Only writes to framebuffer (i.e., painters algorithm)

Thus once very popular for video games (but no longer, at least on PC platform)

Still very useful for other reasons (more later) Cons:

– Computationally intense preprocess stage restricts algorithm to static scenes

– Worst-case time to construct tree: O(n3)– Splitting increases polygon count

Again, O(n3) worst case

Ouch

Warnock’s Algorithm (1969)

Elegant scheme based on a powerful general approach common in graphics: if the situation is too complex, subdivide– Start with a root viewport and a list of all primitives– Then recursively:

Clip objects to viewport If number of objects incident to viewport is zero or one, visibility

is trivial Otherwise, subdivide into smaller viewports, distribute

primitives among them, and recurse

Warnock’s Algorithm What is the

terminating condition?

How to determine the correct visible surface in this case?

Warnock’s Algorithm Pros:

– Very elegant scheme– Extends to any primitive type

Cons:– Hard to embed hierarchical schemes in hardware– Complex scenes usually have small polygons and high

depth complexity Thus most screen regions come down to the

single-pixel case

The Z-Buffer Algorithm Both BSP trees and Warnock’s algorithm were proposed

when memory was expensive Ed Catmull (mid-70s) proposed a radical new approach

called the z-buffer– (He went on to help found a little company named Pixar)

The big idea: resolve visibility independently at each pixel

The Z-Buffer Algorithm We know how to rasterize polygons into an image

discretized into pixels:

The Z-Buffer Algorithm What happens if multiple primitives occupy the same

pixel on the screen? Which is allowed to paint the pixel?

The Z-Buffer Algorithm Idea: retain depth (Z in eye coordinates) through

projection transform– Recall canonical viewing volumes– Can transform canonical perspective volume into canonical

parallel volume with:

010011

10000100001

min

min

min zz

zM

The Z-Buffer Algorithm Augment framebuffer with Z-buffer or depth buffer which

stores Z value at each pixel– At frame beginning initialize all pixel depths to – When rasterizing, interpolate depth (Z) across polygon and

store in pixel of Z-buffer– Suppress writing to a pixel if its Z value is more distant than

the Z value already stored there “More distant”: greater than or less than, depending

Edge equations: Z is just another planar parameter:z = Ax + By + C

– Look familiar?– Total cost:

1 more parameter to increment in inner loop

3x3 matrix multiply for setup– See interpolating color

discussion from lecture 10 Edge walking: can interpolate

Z along edges and across spans

Interpolating Z

The Z-Buffer Algorithm How much memory does the Z-buffer use? Does the image rendered depend on the drawing order? Does the time to render the image depend on the

drawing order? How much of the pipeline do occluded polygons

traverse?– What does this imply for the front of the pipeline?– How does Z-buffer load scale with visible polygons? With

framebuffer resolution?

Z-Buffer Pros Simple!!! Easy to implement in hardware Polygons can be processed in arbitrary order Easily handles polygon interpenetration Enables deferred shading

– Rasterize shading parameters (e.g., surface normal) and only shade final visible fragments

– When does this help?

Z-Buffer Cons Lots of memory (e.g. 1280x1024x32 bits) Read-Modify-Write in inner loop requires fast memory Hard to do analytic antialiasing Hard to simulate translucent polygons Precision issues (scintillating, worse with perspective

projection)

Visibility Culling 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 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

Visibility Culling The remainder of this talk will cover:

– View-frustum culling (briefly)– Occlusion culling in architectural environments – General occlusion culling

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

– 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 the 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.