Post on 23-Feb-2016
description
transcript
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.