Transcript Visibility CS 445/645 Introduction to Computer Graphics David Luebke, Spring 2003

Visibility
CS 445/645
Introduction to Computer Graphics
David Luebke, Spring 2003
David Luebke
1
5/23/2016
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
2
5/23/2016
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
3
5/23/2016
Recap: Back-Face Culling
● On the surface of a closed manifold, polygons whose
normals point away from the camera are always
occluded:
Note: backface culling
alone doesn’t solve the
hidden-surface problem!
David Luebke
4
5/23/2016
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
5
5/23/2016
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
6
5/23/2016
Painter’s Algorithm: Problems
● Intersecting polygons present a problem
● Even non-intersecting polygons can form a cycle with
no valid visibility order:
David Luebke
7
5/23/2016
Recap:
Analytic Visibility Algorithms
● Early visibility algorithms computed the set of visible
polygon fragments directly, then rendered the
fragments to a display:
David Luebke
8
5/23/2016
Recap:
Analytic Visibility Algorithms
● Minimum worst-case cost of computing the
fragments for a scene composed of n polygons: O(n2)
David Luebke
9
5/23/2016
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
10
5/23/2016
BSP Trees: Objects
9
6
8
7
5
4
1
David Luebke
2
3
11
5/23/2016
BSP Trees: Objects
9
6
8
7
5
6
7
8
9
1
2
3
4
5
4
1
David Luebke
2
3
12
5/23/2016
BSP Trees: Objects
9
6
8
7
5
7
4
1
David Luebke
2
8
9
5
6
2
3
4
1
3
13
5/23/2016
BSP Trees: Objects
9
6
8
7
5
1
4
1
David Luebke
2
3
8
14
7
9
6
5
3
2
4
5/23/2016
BSP Trees: Objects
9
6
8
7
5
1
4
1
2
3
8
6
7
David Luebke
15
9
5
3
2
4
5/23/2016
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
16
5/23/2016
Rendering BSP Trees
9
6
8
7
5
1
4
1
2
3
8
6
7
David Luebke
17
9
5
3
2
4
5/23/2016
Rendering BSP Trees
9
6
8
7
5
1
4
1
2
3
8
6
7
David Luebke
18
9
5
3
2
4
5/23/2016
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
19
5/23/2016
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
20
5/23/2016
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:
Ouch
■ Worst case: can create up to O(n3) objects!
David Luebke
21
5/23/2016
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
22
5/23/2016
BSP Demo
● Nice demo:
■ http://symbolcraft.com/graphics/bsp/index.html
■ Also has a link to the BSP Tree FAQ
David Luebke
23
5/23/2016
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
24
5/23/2016
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
25
5/23/2016
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
26
5/23/2016
Warnock’s Algorithm
● What is the
terminating
condition?
● How to determine
the correct visible
surface in this
case?
David Luebke
27
5/23/2016
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
28
5/23/2016
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
29
5/23/2016
The Z-Buffer Algorithm
● We know how to rasterize polygons into an image
discretized into pixels:
David Luebke
30
5/23/2016
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
31
5/23/2016
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:
1
0
M 
0

0
David Luebke
0
0
1
0
1
0
1  zmin
0
1
32

0 
 zmin

1  zmin 
0 
0
5/23/2016
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
33
5/23/2016
Interpolating Z
● 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
David Luebke
34
5/23/2016
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?
David Luebke
35
5/23/2016