Presentation is loading. Please wait.

Presentation is loading. Please wait.

David Luebke 1 12/8/2015 Visibility CS 445/645 Introduction to Computer Graphics David Luebke, Spring 2003.

Similar presentations


Presentation on theme: "David Luebke 1 12/8/2015 Visibility CS 445/645 Introduction to Computer Graphics David Luebke, Spring 2003."— Presentation transcript:

1 David Luebke 1 12/8/2015 Visibility CS 445/645 Introduction to Computer Graphics David Luebke, Spring 2003

2 David Luebke 2 12/8/2015 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

3 David Luebke 3 12/8/2015 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

4 David Luebke 4 12/8/2015 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!

5 David Luebke 5 12/8/2015 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

6 David Luebke 6 12/8/2015 Recap: Painter’s Algorithm ● Simple approach: render the polygons from back to front, “painting over” previous polygons: ■ Draw blue, then green, then pink

7 David Luebke 7 12/8/2015 Painter’s Algorithm: Problems ● Intersecting polygons present a problem ● Even non-intersecting polygons can form a cycle with no valid visibility order:

8 David Luebke 8 12/8/2015 Recap: Analytic Visibility Algorithms ● Early visibility algorithms computed the set of visible polygon fragments directly, then rendered the fragments to a display:

9 David Luebke 9 12/8/2015 Recap: Analytic Visibility Algorithms ● Minimum worst-case cost of computing the fragments for a scene composed of n polygons: O(n 2 )

10 David Luebke 10 12/8/2015 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

11 David Luebke 11 12/8/2015 BSP Trees: Objects 1 2 3 4 5 6 7 8 9

12 David Luebke 12 12/8/2015 BSP Trees: Objects 1 2 3 4 5 6 7 8 9 5 67 89123 4

13 David Luebke 13 12/8/2015 BSP Trees: Objects 1 2 3 4 5 6 7 8 9 56 789 2 3 41

14 David Luebke 14 12/8/2015 BSP Trees: Objects 1 2 3 4 5 6 7 8 9 1 3 2 4 56978

15 David Luebke 15 12/8/2015 BSP Trees: Objects 1 2 3 4 5 6 7 8 9 1 3 568 7924

16 David Luebke 16 12/8/2015 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);

17 David Luebke 17 12/8/2015 Rendering BSP Trees 1 2 3 4 5 6 7 8 9 1 3 568 7924

18 David Luebke 18 12/8/2015 Rendering BSP Trees 1 2 3 4 5 6 7 8 9 1 3 568 7924

19 David Luebke 19 12/8/2015 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

20 David Luebke 20 12/8/2015 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

21 David Luebke 21 12/8/2015 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(n 3 ) objects! Ouch

22 David Luebke 22 12/8/2015 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?

23 David Luebke 23 12/8/2015 BSP Demo ● Nice demo: ■ http://symbolcraft.com/graphics/bsp/index.html http://symbolcraft.com/graphics/bsp/index.html ■ Also has a link to the BSP Tree FAQ

24 David Luebke 24 12/8/2015 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)

25 David Luebke 25 12/8/2015 Summary: BSP Trees ● Cons: ■ Computationally intense preprocess stage restricts algorithm to static scenes ■ Worst-case time to construct tree: O(n 3 ) ■ Splitting increases polygon count ○ Again, O(n 3 ) worst case

26 David Luebke 26 12/8/2015 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

27 David Luebke 27 12/8/2015 Warnock’s Algorithm ● What is the terminating condition? ● How to determine the correct visible surface in this case?

28 David Luebke 28 12/8/2015 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

29 David Luebke 29 12/8/2015 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

30 David Luebke 30 12/8/2015 The Z-Buffer Algorithm ● We know how to rasterize polygons into an image discretized into pixels:

31 David Luebke 31 12/8/2015 The Z-Buffer Algorithm ● What happens if multiple primitives occupy the same pixel on the screen? Which is allowed to paint the pixel?

32 David Luebke 32 12/8/2015 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:

33 David Luebke 33 12/8/2015 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

34 David Luebke 34 12/8/2015 ● 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

35 David Luebke 35 12/8/2015 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?


Download ppt "David Luebke 1 12/8/2015 Visibility CS 445/645 Introduction to Computer Graphics David Luebke, Spring 2003."

Similar presentations


Ads by Google