I total = k a I ambient + I i ( - PowerPoint PPT Presentation

University of British Columbia Clarification: Blinn-Phong Model Reading for Hidden Surfaces CPSC 314 Computer Graphics • only change vs Phong model is to have the specular • FCG Sect 8.2.3 Z-Buffer Jan-Apr 2013 ( h • n ) ( v • r ) calculation to use instead of • FCG Sect 12.4 BSP Trees Tamara Munzner • (8.1, 8.2 2 nd ed) • full Blinn-Phong lighting model equation has ambient, diffuse, specular terms • FCG Sect 3.4 Alpha Compositing Hidden Surface Removal # lights k d ( n • l i ) + k s ( n • h i ) n shiny ) • (N/A 2 nd ed) � Hidden Surfaces I total = k a I ambient + I i ( i = 1 • just like full Phong model equation # lights k d ( n • l i ) + k s ( v • r i ) n shiny ) � I total = k a I ambient + I i ( http://www.ugrad.cs.ubc.ca/~cs314/Vjan2013 i = 1 2 3 4 Occlusion Painter ’ s Algorithm Painter ’ s Algorithm: Problems Analytic Visibility Algorithms • simple: render the polygons from back to • early visibility algorithms computed the set of visible polygon • for most interesting scenes, some polygons • intersecting polygons present a problem fragments directly, then rendered the fragments to a display: front, “ painting over ” previous polygons overlap • even non-intersecting polygons can form a cycle with no valid visibility order: • draw blue, then green, then orange • to render the correct image, we need to • will this work in the general case? determine which polygons occlude which 5 6 7 8 Analytic Visibility Algorithms Analytic Visibility Algorithms Binary Space Partition Trees (1979) Creating BSP Trees: Objects • what is the minimum worst-case cost of • so, for about a decade (late 60s to late 70s) • BSP Tree: partition space with binary tree of computing the fragments for a scene there was intense interest in finding efficient planes composed of n polygons? algorithms for hidden surface removal • idea: divide space recursively into half-spaces • answer: • we ’ ll talk about one: by choosing splitting planes that separate objects in scene O( n 2 ) • Binary Space Partition (BSP) Trees • preprocessing: create binary tree of planes • runtime: correctly traversing this tree enumerates objects from back to front 9 10 11 12 Creating BSP Trees: Objects Creating BSP Trees: Objects Creating BSP Trees: Objects Creating BSP Trees: Objects 13 14 15 16

Splitting Objects Traversing BSP Trees Traversing BSP Trees BSP Trees : Viewpoint A • tree creation independent of viewpoint • no bunnies were harmed in previous example query: given a viewpoint, produce an ordered list of (possibly • preprocessing step split) objects from back to front: • but what if a splitting plane passes through • tree traversal uses viewpoint renderBSP(BSPtree *T) an object? • runtime, happens for many different viewpoints BSPtree *near, *far; • each plane divides world into near and far • split the object; give half to each node if ( eye on left side of T->plane ) • for given viewpoint, decide which side is near and which is far near = T->left; far = T->right; else • check which side of plane viewpoint is on independently for each tree vertex Ouch near = T->right; far = T->left; • tree traversal differs depending on viewpoint! renderBSP(far); • recursive algorithm if ( T is a leaf node ) • recurse on far side renderObject(T) • draw object renderBSP(near); • recurse on near side 17 18 19 20 BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A N F N N N N F F F F F F F F F N N N N N F F N F N N  decide independently at each tree vertex 21  not just left or right child! 22 23 24 BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A F F F N N N N N F F F F 1 1 1 1 N N F F F F F N 2 N 2 N 2 N N F N N F F N N F F N N F F N 1 1 2 N F 1 2 N F 1 2 25 26 27 28 BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A BSP Trees : Viewpoint A F 3 3 F N 3 F N 3 N N N N F F F F 1 1 1 1 5 5 4 4 4 N F F F F F 2 N 2 N 2 N 2 N N 8 7 N F F N N F F N N F F N N F F N N F 6 9 6 F N F 1 2 N F 1 2 N F 1 2 N F 1 2 N 9 5 5 3 4 3 4 3 4 3 8 7 29 30 31 32

BSP Trees : Viewpoint B BSP Trees : Viewpoint B BSP Tree Traversal: Polygons BSP Demo • split along the plane defined by any polygon • useful demo: from scene http://symbolcraft.com/graphics/bsp 7 • classify all polygons into positive or negative F F N N 5 6 half-space of the plane 9 F F F N N F N N • if a polygon intersects plane, split polygon into 8 4 two and classify them both F F N N F N 2 N N F N 1 F F • recurse down the negative half-space 1 3 N F N F • recurse down the positive half-space N F 9 8 N F 5 2 7 6 4 3 33 34 35 36 BSP Demo Summary: BSP Trees The Z-Buffer Algorithm (mid-70 ’ s) The Z-Buffer Algorithm • order of insertion can affect half-plane extent • pros: • we know how to rasterize polygons into an • BSP trees proposed when memory was • simple, elegant scheme image discretized into pixels: • correct version of painter’s algorithm back-to-front rendering expensive approach • first 512x512 framebuffer was >$50,000! • was very popular for video games (but getting less so) • cons: • Ed Catmull proposed a radical new • slow to construct tree: O(n log n) to split, sort approach called z-buffering • splitting increases polygon count: O(n 2 ) worst-case • the big idea: • computationally intense preprocessing stage restricts algorithm to static scenes • resolve visibility independently at each pixel 37 38 39 40 The Z-Buffer Algorithm The Z-Buffer Algorithm The Z-Buffer Algorithm Interpolating Z • augment color framebuffer with Z-buffer or • what happens if multiple primitives occupy • idea: retain depth after projection transform • barycentric coordinates depth buffer which stores Z value at each the same pixel on the screen? • each vertex maintains z coordinate • interpolate Z like other pixel planar parameters • which is allowed to paint the pixel? • relative to eye point • at frame beginning, initialize all pixel depths • can do this with canonical viewing volumes to ∞ • when rasterizing, interpolate depth (Z) across polygon • check Z-buffer before storing pixel color in framebuffer and storing depth in Z-buffer • don’t write pixel if its Z value is more distant than the Z value already stored there 41 42 43 44 Z-Buffer Depth Test Precision Depth Test Precision Depth Test Precision • store (r,g,b,z) for each pixel • therefore, depth-buffer essentially stores 1/z, • low precision can lead to depth fighting for far objects • reminder: perspective transformation maps eye-space (view) z to NDC z rather than z! • two different depths in eye space get mapped to same • typically 8+8+8+24 bits, can be more depth in framebuffer � � � Ex � � • issue with integer depth buffers z + Az � � � � • which object “wins” depends on drawing order and scan- for all i,j { � E 0 A 0 � � x � � Ex + Az � � � • high precision for near objects � � conversion Depth[i,j] = MAX_DEPTH � � � � � � � Fy � � � � 0 F B 0 y Fy + Bz Image[i,j] = BACKGROUND_COLOUR z + Bz � � • low precision for far objects • gets worse for larger ratios f:n � � � � � � = = � � � � } � 0 0 C D � � z � � Cz + D � � � • rule of thumb: f:n < 1000 for 24 bit depth buffer for all polygons P { � C + D � � � � � � � � z NDC � � 0 0 � 1 0 1 � z � � for all pixels in P { � � � � � � • with 16 bits cannot discern millimeter differences in � z � � � if (Z_pixel < Depth[i,j]) { 1 � � objects at 1 km distance Image[i,j] = C_pixel � � Depth[i,j] = Z_pixel z NDC = � C + D • thus: • demo: sjbaker.org/steve/omniv/ � � } � � z eye love_your_z_buffer.html � � } } -z eye -n -f 45 46 47 48