David Luebke5/11/2015 CS 551 / 645: Introductory Computer Graphics David Luebke

David Luebke5/11/2015 Administrivia l Note changes on homework web page –We were always drawing the icosahedron inside out…oops

David Luebke5/11/2015 Recap: Visible Surface Determination l Reasons for invisible polygons: –Polygon outside the field of view –Polygon is backfacing –Polygon is occluded by object(s) nearer the viewpoint l Algorithms for determining which potions of which polygons are visible (unoccluded) are known as visible surface algorithms

David Luebke5/11/2015 Recap: Occlusion l For most interesting scenes, some polygons will overlap: l To render the correct image, we need to determine which polygons occlude which

David Luebke5/11/2015 Recap: Painter’s Algorithm l Simple approach: render the polygons from back to front, “painting over” previous polygons: l Doesn’t work in general case –Intersecting polygons –Visibility cycles:

David Luebke5/11/2015 Recap: Binary Space Partition (BSP) Trees l Fuchs et al, 1980 l Assumptions: –Static scene –Moving camera l Commonly used in 3-D video games (e.g., Quake), but going out of style l Still a very powerful, general idea, used in many graphics algorithms

David Luebke5/11/2015 Recap: BSP Trees –Preprocess: overlay a binary (BSP) 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 n Splitting planes can be arbitrarily oriented n Notice: nodes are always convex

David Luebke5/11/2015 Recap: BSP Trees

David Luebke5/11/2015 Recap: BSP Trees

David Luebke5/11/2015 Recap: BSP Trees

David Luebke5/11/2015 Recap: BSP Trees

David Luebke5/11/2015 Recap: BSP Trees

David Luebke5/11/2015 Recap: Rendering BSP Trees renderBSP(BSPtree *T) BSPtree *near, far; if (T is a leaf node) renderObject(T) if (eye on left side of T->plane) near = T->left; far = T->right; else near = T->right; far = T->left; renderBSP(far); renderBSP(near);

David Luebke5/11/2015 Recap: Rendering BSP Trees

David Luebke5/11/2015 Recap: Rendering BSP Trees

David Luebke5/11/2015 Recap: BSP Tree Cons l No bunnies were harmed in my example l 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

David Luebke5/11/2015 BSP Demo l Really cool demo:

David Luebke5/11/2015 Warnock’s Algorithm (1969) l 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: n Clip objects to viewport n If number of objects incident to viewport is zero or one, visibility is trivial n Otherwise, subdivide into smaller viewports, distribute primitives among them, and recurse

David Luebke5/11/2015 Warnock’s Algorithm l What is the terminating condition? l How to determine the correct visible surface in this case?

David Luebke5/11/2015 Warnock’s Algorithm l Pros: –Very elegant scheme –Extends to any primitive type l Cons: –Hard to embed hierarchical schemes in hardware –Complex scenes usually have small polygons and high depth complexity n Thus most screen regions come down to the single-pixel case

David Luebke5/11/2015 The Z-Buffer Algorithm l Both BSP trees and Warnock’s algorithm were proposed when memory was expensive –Example: first 512x512 framebuffer > $50,000! l Ed Catmull (mid-70s) proposed a radical new approach called z-buffering. l The big idea: resolve visibility independently at each pixel

David Luebke5/11/2015 The Z-Buffer Algorithm l We know how to rasterize polygons into an image discretized into pixels:

David Luebke5/11/2015 The Z-Buffer Algorithm l What happens if multiple primitives occupy the same pixel on the screen? Which is allowed to paint the pixel?

David Luebke5/11/2015 The Z-Buffer Algorithm l Idea: retain depth (Z in eye coordinates) through projection transform –Recall canonical viewing volumes (see slide) –Can transform canonical perspective volume into canonical parallel volume with:

David Luebke5/11/2015 The Z-Buffer Algorithm l 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 n “More distant”: greater than or less than, depending

David Luebke5/11/2015 Interpolating Z l Edge equations: Z is just another planar parameter: z = Ax + By + C –Look familiar? –Total cost: n 1 more parameter to increment in inner loop n 3x3 matrix multiply for setup –See interpolating color discussion from lecture 10 l Edge walking: just interpolate Z along edges and across spans

David Luebke5/11/2015 The Z-Buffer Algorithm l How much memory does the Z-buffer use? l Does the image rendered depend on the drawing order? l Does the time to render the image depend on the drawing order? l 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 Luebke5/11/2015 Z-Buffer Pros l Simple!!! l Easy to implement in hardware l Polygons can be processed in arbitrary order l Easily handles polygon interpenetration l Enables deferred shading –Rasterize shading parameters (e.g., surface normal) and only shade final visible fragments –When does this help?

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