159.235 Graphics & Graphical Programming

1. 159.235 Graphics & Graphical Programming Lecture 26 - Visible & Hidden Surface Determination Graphics

2. Hidden Surface Removal • Inventing renderers led to geometric models, a call for more realism and therefore lots of polygons. • All this led to intense interest in finding efficient algorithms for hidden surface removal. • Some algorithms are more correctly called visible surface algorithms but the two names are used interchangeably. • Today we’ll look at several out of many generated during the period of intense interest (around late 60s to late 70s). Graphics

3. Visibility of primitives • We don’t want to waste time rendering primitives which don’t contribute to the final image. • A scene primitive can be invisible for 3 reasons: • Primitive lies outside field of view • Primitive is back-facing (under certain conditions) • Primitive is occluded by one or more objects nearer the viewer • How do we remove these efficiently? • How do we identify these efficiently? Graphics

4. The Visibility Problem. • Two problems remain: • (Clipping we have covered) • Removal of faces facing away from the viewer. • Removal of faces obscured by closer objects. Graphics

5. Visible Surface Algorithms Hidden/Visible Surface/Line Elimination/Determination • Requirements • Handle diverse set of geometric primitives • Handle large number of geometric primitives Classification: Sutherland, Sproull, Schumacher (1974): • Object Space • Geometric calculations involving polygons • Floating point precision: Exact • Often process scene in object order • Image Space • Visibility at pixel samples • Integer precision • Often process scene in image order Graphics

6. Back Face Culling • We saw in modelling, that the vertices of polyhedra are oriented in an anticlockwise manner when viewed from outside – surface normal N points out. • Project a polygon. • Test z component of surface normal. If negative – cull, since normal points away from viewer. • Or if N.V > 0 we are viewing the back face so polygon is obscured. • Only works for convex objects without holes, ie. closed orientable manifolds. Graphics

7. Back Face Culling • Back face culling can be applied anywhere in the pipeline: world or eye coords, NDC, image space. • Where is the best point? What portion of the scene is eliminated, on average? • Depends on application • If we clip our scene to the view frustrum, then remove all back-facing polygons – are we done? • NO! Most views involve overlapping polygons. Graphics

8. How de we handle overlapping? How about drawing the polygons in the “right order” so that we get the correct result ( eg. blue, then green, then peach)? Is it just a sorting problem ? Yes it is for 2D, but in 3D we can encounter intersecting polygons or groups of non-intersecting polygons which form a cycle where order is impossible (later). Graphics

9. Simple Z-buffering • Simple to include in scanline algorithm. • Interpolate z during scan conversion. • Maintain a depth (range) image in the frame buffer (16 or 24 bits common ). • When drawing, compare with the currently stored z value. • Pixel given intensity of nearest polygon. Graphics

10. Implementation • Initialise frame buffer to background colour. • Initialise depth buffer to z = max. value for far clipping plane, ie. LHCS • Need to calculate value for z for each pixel • But only for polygons intersecting that pixel. • Could interpolate from values at vertices. • Update both frame and depth buffer. Graphics

11. Determining Depth • Only one subtraction needed • Depth coherence. Graphics

12. Why is z-buffering so popular ? Advantage • Simple to implement in hardware. • Add additional z interpolator for each primitive. • Memory for z-buffer is now not expensive • Diversity of primitives – not just polygons. • Unlimited scene complexity • Don’t need to calculate object-object intersections. Disadvantage • Extra memory and bandwidth • Waste time drawing hidden objects • Z-precision Errors • May have to use point sampling Graphics

13. Z-compositing Colour photograph. Can use depth other than from polygons. Laser range return. Reflected laser power Data courtesy of UNC. Graphics

14. Ray Casting • Sometimes referred to as Ray-tracing. • Involves projecting an imaginary ray from the centre of projection (the viewers eye) through the centre of each pixel into the scene. Scene Eyepoint Window Graphics

15. Computing Ray-Object Intersections • The heart of ray tracing. • E.g sphere ( the easiest ! ). • Expand, substitute for x,y & z. • Gather terms in t. • Quadratic equation in t. Solve for t. • No roots – ray doesn’t intersect. • 1 root – ray grazes surface. • 2 roots – ray intersects sphere, • (entry and exit) Graphics

16. Ray-Polygon Intersection • Not so easy ! • Determine whether ray intersects polygon’s plane. • Determine whether intersection lies within polygon. • Easiest to determine (2) with an orthographic projection onto the nearest axis and the 2D point-in-polygon test. z Ray x y Graphics

17. Ray Casting • Easy to implement for a variety of primitives – only need a ray-object intersection function. • Pixel adopts colour of nearest intersection. • Can draw curves and surfaces exactly – not just triangles ! • Can generate new rays inside the scene to correctly handle visibility with reflections, refraction etc – recursive ray-tracing. • Can be extended to handle global illumination. • Can perform area-sampling using ray super-sampling. • But… too expensive for real-time applications. Graphics

18. Examples of Ray-traced images. Graphics

19. Painters Algorithm (object space) • Draw surfaces in back to front order – nearer polygons “paint” over farther ones. • Supports transparency. • Key issue is order determination. • Doesn’t always work – see image at right. Graphics

20. BSP (Binary Space Partitioning) Tree • One of class of “list-priority” algorithms – returns ordered list of polygon fragments for specified view point (static pre-processing stage). • Choose polygon arbitrarily • Divide scene into front (relative to normal) and back half-spaces. • Split any polygon lying on both sides. • Choose a polygon from each side – split scene again. • Recursively divide each side until each node contains only 1 polygon. 5 2 3 1 4 View of scene from above Graphics

21. 5 5a 5b 2 3 1 4 3 back front 1 2 5a 4 5b BSP Tree • Choose polygon arbitrarily • Divide scene into front (relative to normal) and back half-spaces. • Split any polygon lying on both sides. • Choose a polygon from each side – split scene again. • Recursively divide each side until each node contains only 1 polygon. Graphics

22. BSP Tree 5 5a 5b 2 • Choose polygon arbitrarily • Divide scene into front (relative to normal) and back half-spaces. • Split any polygon lying on both sides. • Choose a polygon from each side – split scene again. • Recursively divide each side until each node contains only 1 polygon. 3 1 4 3 back front 2 4 5b front 5a 1 Graphics

23. 5 5a 5b 2 3 1 4 3 back front 2 4 front 5a 1 5b BSP Tree • Choose polygon arbitrarily • Divide scene into front (relative to normal) and back half-spaces. • Split any polygon lying on both sides. • Choose a polygon from each side – split scene again. • Recursively divide each side until each node contains only 1 polygon. Graphics

24. BSP Tree 5 2 • Choose polygon arbitrarily • Divide scene into front (relative to normal) and back half-spaces. • Split any polygon lying on both sides. • Choose a polygon from each side – split scene again. • Recursively divide each side until each node contains only 1 polygon. 3 1 4 5 back 4 back Alternate formulation starting at 5 3 front 1 back 2 Graphics

25. Displaying a BSP Tree • Once we have the regions – need priority list • BSP tree can be traversed to yield a correct priority list for an arbitrary viewpoint. • Start at root polygon. • If viewer is in front half-space, draw polygons behind root first, then the root polygon, then polygons in front. • If polygon is on edge – either can be used. • Recursively descend the tree. • If eye is in rear half-space for a polygon – then can back face cull. Graphics

26. BSP Tree • A lot of computation required at start. • Try to split polygons along good dividing plane • Intersecting polygon splitting may be costly • Cheap to check visibility once tree is set up. • Can be used to generate correct visibility for arbitrary views.  Efficient when objects don’t change very often in the scene. Graphics

27. Warnock’s Algorithm • Elegant hybrid of object-space and image-space. • Uses standard graphics solution:- if situation too complex then subdivide problem. • Start with root window: • If zero or one intersecting, contained or surrounding polygon then scan convert window • Else subdivide window as quadtree • Recurse until zero or one polygon, or some set depth • Depth may be pixel resolution, display nearest polygon Graphics

28. Warnock’s Example Graphics

29. Warnock Performance Measure • Warnock’s algorithm: • Screen-space subdivision (screen resolution, r = w*h) hybrid object-space & image-space algorithm good for relatively few static primitives, precise. • Working set size (memory requirement): O(n) • Storage overhead (over & above model): O(n lg r) • Time to resolve visibility to screen precision: O(n*r) • Overdraw (depth complexity – how often a typical pixel is written by rasterization process): none Graphics

30. BSP Performance Measure • Tree construction and traversal (object-space ordering algorithm – good for relatively few static primitives, precise) • Working set size (depends on application): O(1), O(lg n) • Storage overhead: O(n2) • Time to resolve visibility to screen precision: O(n2) • Overdraw: maximum Graphics

31. Z-buffer Performance • Brute-force image-space algorithm scores best for complex scenes – not very accurate but is easy to implement and is very general. • Working set size: O(1) • Storage overhead: O(1) • Time to resolve visibility to screen precision: O(n) • Overdraw: maximum • But even O(n) is now intolerable! Graphics

32. Example Architectural scenes Here there can be an enormous amount of occlusion Graphics

33. Occlusion at various levels Graphics

34. A B C D E Cells & Portals (object-space) D F • Model scene as a graph: • Nodes: Cells (or rooms) • Edges: Portals (or doors) • Graph gives us: • Potentially visible set • Superset of visible polygons • Room to room visibility • Not a complete solution ! C B E A G Graphics

35. Example Application : Quake game engine • Calculates visibility separately for environment and objects. • Environment • Use portals to determine potentially visible set • Use BSP-tree to order polygons front-back. • Scan-convert polygons maintaining order. Graphics

36. Example : Quake Game Engine • Scan converting polygons • Maintain front-back ordering. • Use visibility mask on scanline. F • - Create active edge list for polygons F & B. • - Write in front-back order. • Mask values once written to buffer. • Write colour to framebuffer • - Write z to z-buffer Scanline B Graphics

37. Example : Quake Game Engine • Calculates visibility separately for environment and objects. • Environment • Use portals to determine potentially visible set • Use BSP-tree to order polygons front-back. • Scan-convert polygons maintaining order. • Maintain colour and z buffers. • Objects. • Use Z-buffer from environment stage. Graphics

38. Other Applications • Outdoor environments: • Urban regions, forests, natural scenes in general • Or very complex assemblies: mechanical CAD parts (Boeing 777 engine block) • Molecular visualization Very hard and still not solved problem Graphics

39. Z-Buffer & BSP Not Only Approaches • Other approaches: • Depth sort – Newell, Newell & Sancha • Scan-line algorithms • Weiler-Atherton subdivision on polygon edges Graphics

40. Visible Surfaces - Summary • Visible and Hidden Surfaces • Z-Buffering • BSP • Acknowledgments - thanks to Eric McKenzie, Edinburgh, from whose Graphics Course some of these slides were adapted. Graphics