Painter s Algorithm: Problems

Transcription

1 Universit of British Columbia CPSC Computer Graphics Jan-Apr 0 Tamara Munzner Hidden Surfaces Clarification: Blinn-Phong Model onl change vs Phong model is to have the specular calculation to use (h n) instead of (v r) full Blinn-Phong lighting model equation has ambient, diffuse, specular terms # lights I total = k a I ambient + " I i ( k d (n l i ) + k s (n h i ) nshin ) i= Reading for Hidden Surfaces CG Sect.. Z-Buffer CG Sect. BSP Trees (.,. nd ed) CG Sect. Alpha Compositing (/A nd ed) Hidden Surface Removal just like full Phong model equation # lights I total = k a I ambient + " I i ( k d (n l i ) + k s (v r i ) nshin ) i= Occlusion Painter s Algorithm Painter s Algorithm: Problems Analtic Visibilit Algorithms for most interesting scenes, some polgons overlap simple: render the polgons from back to front, painting over previous polgons intersecting polgons present a problem even non-intersecting polgons can form a ccle with no valid visibilit order: earl visibilit algorithms computed the set of visible polgon fragments directl, then rendered the fragments to a displa: to render the correct image, we need to determine which polgons occlude which draw blue, then green, then orange will this work in the general case? Analtic Visibilit Algorithms Analtic Visibilit Algorithms Binar Space Partition Trees () what is the minimum worst-case cost of computing the fragments for a scene composed of n polgons? answer: O(n ) so, for about a decade (late 0s to late 0s) there was intense interest in finding efficient algorithms for hidden surface removal we ll talk about one: Binar Space Partition (BSP) Trees BSP Tree: partition space with binar tree of planes idea: divide space recursivel into half-spaces b choosing splitting planes that separate objects in scene preprocessing: create binar tree of planes runtime: correctl traversing this tree enumerates objects from back to front 0

2 Splitting Objects Traversing BSP Trees no bunnies were harmed in previous example but what if a splitting plane passes through an object? Traversing BSP Trees tree creation independent of viewpoint preprocessing step tree traversal uses viewpoint renderbsp(bsptree *T) BSPtree *near, *far; if (ee 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); runtime, happens for man different viewpoints each plane divides world into near and far split the object; give half to each node for given viewpoint, decide which side is near and which is far check which side of plane viewpoint is on independentl for each tree vertex tree traversal differs depending on viewpoint! Ouch quer: given a viewpoint, produce an ordered list of (possibl split) objects from back to front: recursive algorithm recurse on far side draw object recurse on near side 0 decide independentl at each tree vertex not just left or right child! 0

3 BSP Trees : Viewpoint B BSP Trees : Viewpoint B BSP Tree Traversal: Polgons BSP Demo split along the plane defined b an polgon from scene classif all polgons into positive or negative half-space of the plane if a polgon intersects plane, split polgon into two and classif them both recurse down the negative half-space recurse down the positive half-space useful demo: BSP Demo Summar: BSP Trees (mid-0 s) order of insertion can affect half-plane extent pros: simple, elegant scheme correct version of painter s algorithm back-to-front rendering approach was ver popular for video games (but getting less so) cons: slow to construct tree: O(n log n) to split, sort splitting increases polgon count: O(n ) worst-case computationall intense preprocessing stage restricts algorithm to static scenes BSP trees proposed when memor was expensive first x framebuffer was >$0,000! Ed Catmull proposed a radical new approach called z-buffering the big idea: resolve visibilit independentl at each pixel we know how to rasterize polgons into an image discretized into pixels: 0 Interpolating Z what happens if multiple primitives occup the same pixel on the screen? which is allowed to paint the pixel? idea: retain depth after projection transform each vertex maintains z coordinate relative to ee point can do this with canonical viewing volumes augment color 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 polgon 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 alread stored there barcentric coordinates interpolate Z like other planar parameters Z-Buffer store (r,g,b,z) for each pixel tpicall +++ bits, can be more for all i,j { Depth[i,j] = MAX_DEPTH Image[i,j] = BACKGROUD_COLOUR for all polgons P { for all pixels in P { if (Z_pixel < Depth[i,j]) { Image[i,j] = C_pixel Depth[i,j] = Z_pixel reminder: perspective transformation maps ee-space (view) z to DC z # ) " Ex # E 0 A 0& # x& # Ex + Az& z + Az,& +.( * - ( ( ( 0 B 0 ( ( = + Bz ( " ( ) = z + Bz, +.( * -( 0 0 C D( z( Cz + D ( ( ( ( ) $ 0 0 " 0' $ ' $ "z ' " + C + D, (. ( * z - ( $ ' # thus: z DC = " C + D & $ z ( ee ' therefore, depth-buffer essentiall stores /z, rather than z! issue with integer depth buffers high precision for near objects low precision for far objects z DC low precision can lead to depth fighting for far objects two different depths in ee space get mapped to same depth in framebuffer which object wins depends on drawing order and scanconversion gets worse for larger ratios f:n rule of thumb: f:n < 000 for bit depth buffer with bits cannot discern millimeter differences in objects at km distance demo: sjbaker.org/steve/omniv/ love_our_z_buffer.html -n -f -z ee

4 More: Integer Depth Buffer Z-Buffer Algorithm Questions Z-Buffer Pros Z-Buffer Cons reminder from picking discussion depth lies in the DC z range [0,] format: multipl b ^n - then round to nearest int where n = number of bits in depth buffer bit depth buffer = ^ =,, possible values small numbers near, large numbers far consider depth from VCS: (<<) * ( a + b / z ) = number of bits of Z precision a = zar / ( zar - zear ) b = zar * zear / ( zear - zar ) z = distance from the ee to the object how much memor 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 does Z-buffer load scale with visible polgons? with framebuffer resolution? simple!!! eas to implement in hardware hardware support in all graphics cards toda polgons can be processed in arbitrar order easil handles polgon interpenetration enables deferred shading rasterize shading parameters (e.g., surface normal) and onl shade final visible fragments poor for scenes with high depth complexit need to render all polgons, even if most are invisible ee shared edges are handled inconsistentl ordering dependent 0 Z-Buffer Cons Hidden Surface Removal Object Space Algorithms Image Space Algorithms requires lots of memor (e.g. 0x0x bits) requires fast memor Read-Modif-Write in inner loop hard to simulate translucent polgons we throw awa color of polgons behind closest one works if polgons ordered back-to-front extra work throws awa much of the speed advantage two kinds of visibilit algorithms object space methods image space methods determine visibilit on object or polgon level using camera coordinates resolution independent explicitl compute visible portions of polgons earl in pipeline after clipping requires depth-sorting painter s algorithm BSP trees perform visibilit test for in screen coordinates limited to resolution of displa Z-buffer: check ever pixel independentl performed late in rendering pipeline Projective Rendering Pipeline Rendering Pipeline Back-ace Culling glvertexf(x,,z) object world viewing alter w OCS WCS VCS glrustum(...) modeling viewing projection transformation transformation transformation clipping gltranslatef(x,,z) glulookat(...) glrotatef(th,x,,z) / w CCS... perspective OCS - object coordinate sstem division normalized glutinitwindowsize(w,h) WCS - world coordinate sstem glviewport(x,,a,b) DCS VCS - viewing coordinate sstem viewport transformation CCS - clipping coordinate sstem DCS - normalized coordinate sstem DCS Geometr Database normalized DCS DCS Scan Conversion object world viewing OCS WCS VCS (D) Model/View Texturing Lighting Depth Test Perspective screen SCS (D) clipping CCS (D) Clipping ramebuffer /w Backface Culling on the surface of a closed orientable manifold, polgons whose normals point awa from the camera are alwas occluded: note: backface culling alone doesn t solve the hidden-surface problem! DCS - coordinate sstem 0 Back-ace Culling Back-ace Culling Back-ace Culling Back-face Culling: VCS not rendering backfacing polgons improves performance b how much? reduces b about half the number of polgons to be considered for each pixel optimization when appropriate most objects in scene are tpicall solid rigorousl: orientable closed manifolds orientable: must have two distinct sides cannot self-intersect a sphere is orientable since has two sides, 'inside' and 'outside'. a Mobius strip or a Klein bottle is not orientable closed: cannot walk from one side to the other sphere is closed manifold plane is not examples of non-manifold objects: a single polgon a terrain or height field polhedron w/ missing face anthing with cracks or holes in boundar one-polgon thick lampshade z ee first idea: cull if Z < 0 sometimes misses polgons that should be culled

5 Back-face Culling: DCS Invisible Primitives VCS DCS z ee wh might a polgon be invisible? polgon outside the field of view / frustum solved b clipping polgon is backfacing solved b backface culling polgon is occluded b object(s) nearer the viewpoint solved b hidden surface removal ee z works to cull if Z > 0 Geometr Database Scan Conversion Rendering Pipeline Model/View Texturing Lighting Depth Test Perspective Clipping ramebuffer Alpha and Premultiplication specif opacit with alpha channel α α=: opaque, α=.: translucent, α=0: transparent how to express a pixel is half covered b a red object? obvious wa: store color independent from transparenc (r,g,b,α) intuition: alpha as transparent colored glass 00 transparenc can be represented with man different RGB values pixel value is (,0,0,.) upside: eas to change opacit of image, ver intuitive downside: compositing calculations are more difficult - not associative elegant wa: premultipl b α so store (αr, αg, αb,α) intuition: alpha as screen/mesh RGB specifies how much color object contributes to scene alpha specifies how much object obscures whatever is behind it (coverage) alpha of. means half the pixel is covered b the color, half completel transparent onl one -tuple represents 00 transparenc: (0,0,0,0) pixel value is (., 0, 0,.) upside: compositing calculations eas (& additive blending for glowing!) downside: less intuitive 0 Alpha and Simple Compositing is foreground, B is background, over B premultipl math: uniform for each component, simple, linear R' = R +(-A )*R B G' = G +(-A )*G B B' = B +(-A )*B B A' = A +(-A )*A B associative: eas to chain together multiple operations non-premultipl math: trickier R' = (R *A + (-A )*R B *A B )/A' G' = (G *A + (-A )*G B *A B )/A' B' = (B *A + (-A )*B B *A B )/A' A' = A +(-A )*A B don't need divide if or B is opaque. but still oof! chaining difficult, must avoid double-counting with intermediate ops Alpha and Complex Compositing foreground color A, background color B how might ou combine multiple elements? Compositing Digital Images, Porter and Duff, Siggraph ' pre-multiplied alpha allows all cases to be handled simpl Alpha Examples blend white and clear equall (0 each) white is (,,,), clear is (0,0,0,0), black is (0,0,0,) premultiplied: multipl componentwise b 0 and just add together (.,.,.,.) is indeed half-transparent white in premultipl format -tuple would mean half-transparent gre in non-premultipl format premultipl allows both conventional blend and additive blend alpha 0 and RGB nonzero: glowing/luminescent (nice for particle sstems, sta tuned) for more: see nice writeup from Alv Ra Smith technical academ award for Smith, Catmull, Porter, Duff