Date post: | 17-Jan-2016 |
Category: |
Documents |
Upload: | todd-russell |
View: | 223 times |
Download: | 0 times |
David Luebke 1 04/21/23
Visibility
CS 445/645Introduction to Computer Graphics
David Luebke, Spring 2003
David Luebke 2 04/21/23
Admin
● Assignment 3 ■ Postponed to Wed Mar 26■ Minor changes made as detailed in e-mail■ Do the Phong model first, then the Blinn model for (a little)
extra credit○ Difference is described nicely in textbook Ch 14.
● I’ll be leaving town…schedule in flux, stay tuned
David Luebke 3 04/21/23
Recap: Visibility
● Why might a polygon be invisible?■ Polygon outside the field of view■ Polygon is backfacing■ Polygon is occluded by object(s) nearer the viewpoint■ Other reasons:
○ Too small to be seen○ Obscured by fog or haze○ Too transparent ○ Too dark
● For both efficiency and correctness reasons, we need to know when polygons are invisible
David Luebke 4 04/21/23
Recap: Back-Face Culling
● On the surface of a closed manifold, polygons whose normals point away from the camera are always occluded:
Note: backface cullingalone doesn’t solve the
hidden-surface problem!
David Luebke 5 04/21/23
Recap: Back-Face Culling
● By not rendering backfacing polygons, we improve performance by roughly 2x
● Can only use backface culling when objects are known to be solid■ Closed, orientable manifolds■ Meaning “well behaved” meshes that partition space into “inside”
and “outside” the object
● In practice, performed by transforming vertices and testing clockwise or counter-clockwise screen order■ In principle, happens after xform, before lighting & rasterization■ In practice, xform & lighting are linked
David Luebke 6 04/21/23
Recap: Painter’s Algorithm
● Simple approach: render the polygons from back to front, “painting over” previous polygons:
■ Draw blue, then green, then pink
David Luebke 7 04/21/23
Painter’s Algorithm: Problems
● Intersecting polygons present a problem● Even non-intersecting polygons can form a cycle with
no valid visibility order:
David Luebke 8 04/21/23
Recap:Analytic Visibility Algorithms
● Early visibility algorithms computed the set of visible polygon fragments directly, then rendered the fragments to a display:
David Luebke 9 04/21/23
Recap:Analytic Visibility Algorithms
● Minimum worst-case cost of computing the fragments for a scene composed of n polygons: O(n2)
David Luebke 10 04/21/23
Binary Space Partition Trees (1979)
● BSP 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
David Luebke 11 04/21/23
BSP Trees: Objects
1 2 3
45
6 78
9
David Luebke 12 04/21/23
BSP Trees: Objects
1 2 3
45
6 78
9
5 6 7 8 9 1 2 3 4
David Luebke 13 04/21/23
BSP Trees: Objects
1 2 3
45
6 78
9
5 67 8 9 2 3 4 1
David Luebke 14 04/21/23
BSP Trees: Objects
1 2 3
45
6 78
9
1
3 2 456978
David Luebke 15 04/21/23
BSP Trees: Objects
1 2 3
45
6 78
9
1
3568
7 9 2 4
David Luebke 16 04/21/23
Rendering BSP Trees
renderBSP(BSPtree *T)
BSPtree *near, far;
if (eye on left side of T->plane)
near = T->left; far = T->right;
else
near = T->right; far = T->left;
renderBSP(far);
if (T is a leaf node)
renderObject(T)
renderBSP(near);
David Luebke 17 04/21/23
Rendering BSP Trees
1 2 3
45
6 78
9
1
3568
7 9 2 4
David Luebke 18 04/21/23
Rendering BSP Trees
1 2 3
45
6 78
9
1
3568
7 9 2 4
David Luebke 19 04/21/23
Polygons: BSP Tree Construction
● 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
David Luebke 20 04/21/23
Polygons: BSP Tree Traversal
● 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->plane
nearchild->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
David Luebke 21 04/21/23
Discussion: BSP Tree Cons
● No bunnies were harmed in my example● But what if a splitting plane passes through an object?
■ Split the object; give half to each node:
■ Worst case: can create up to O(n3) objects!
Ouch
David Luebke 22 04/21/23
BSP Trees
● A BSP Tree increases storage requirements by splitting polygons■ What is the worst-case storage cost of a BSP tree on n
polygons?
● But rendering a BSP tree is fairly efficient■ What is the expected cost of a single query, for a given
viewpoint, on a BSP tree with m nodes?
David Luebke 23 04/21/23
BSP Demo
● Nice demo:■ http://symbolcraft.com/graphics/bsp/index.html ■ Also has a link to the BSP Tree FAQ
David Luebke 24 04/21/23
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)
David Luebke 25 04/21/23
Summary: BSP Trees
● 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
David Luebke 26 04/21/23
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
David Luebke 27 04/21/23
Warnock’s Algorithm
● What is the terminating condition?
● How to determine the correct visible surface in this case?
David Luebke 28 04/21/23
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
David Luebke 29 04/21/23
The Z-Buffer Algorithm
● Both BSP trees and Warnock’s algorithm were proposed when memory was expensive■ Example: first 512x512 framebuffer > $50,000!
● Ed Catmull (mid-70s) proposed a radical new approach called z-buffering■ (He went on to help found a little company named Pixar)
● The big idea: resolve visibility independently at each pixel
David Luebke 30 04/21/23
The Z-Buffer Algorithm
● We know how to rasterize polygons into an image discretized into pixels:
David Luebke 31 04/21/23
The Z-Buffer Algorithm
● What happens if multiple primitives occupy the same pixel on the screen? Which is allowed to paint the pixel?
David Luebke 32 04/21/23
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
100
0010
0001
min
min
min z
z
z
M
David Luebke 33 04/21/23
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
David Luebke 34 04/21/23
● 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
David Luebke 35 04/21/23
The Z-Buffer Algorithm
● To think about:■ 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 polgyons traverse?
○ What does this imply for the front of the pipeline?○ How does Z-buffer load scale with visible polygons? With
framebuffer resolution?