(c) 2002 University of Wisconsin, CS559 Last Time Line drawing An intro to polygon filling 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Today Polygon Fill Some methods for hidden surface removal Homework 4 is online It’s due two days before the midterm, but we will grade it in time and it’s useful study material Midterm info 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Sweep Fill Algorithms Algorithmic issues: Reduce to filling many spans Which edges define the span of pixels to fill? How do you update these edges when moving from span to span? What happens when you cross a vertex? 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Spans Process - fill the bottom horizontal span of pixels; move up and keep filling Have xmin, xmax for each span Define: floor(x): largest integer < x ceiling(x): smallest integer >=x Fill from ceiling(xmin) up to floor(xmax) Consistent with convention 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Algorithm For each row in the polygon: Throw away irrelevant edges Obtain newly relevant edges Fill span Update current edges Issues: How do we update existing edges? When is an edge relevant/irrelevant? All can be resolved by referring to our convention about what polygon pixel belongs to 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Updating Edges Each edge is a line of the form: Next row is: So, each current edge can have it’s x position updated by adding a constant stored with the edge Other values may also be updated, such as depth or color information 03/07/02 (c) 2002 University of Wisconsin, CS559

When are Edges Relevant (1) Use figures and convention to determine when edge is irrelevant For y<ymin and y>=ymax of edge Similarly, edge is relevant when y>=ymin and y<ymax of edge What about horizontal edges? m’ is infinite 03/07/02 (c) 2002 University of Wisconsin, CS559

When are Edges Relevant (2) Convex polygon: Always only two edges active 2 1,2 1 1,3 3 3,4 4 03/07/02 (c) 2002 University of Wisconsin, CS559

When are Edges Relevant (3) Horizontal edges? 2 2? 1 3 1,3 4? 4 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Sweep Fill Details Maintain a list of active edges in case there are multiple spans of pixels - known as Active Edge List. For each edge on the list, must know: x-value, maximum y value of edge, m’ Maybe also depth, color… Keep all edges in a table, indexed by minimum y value - Edge Table For row = min to row=max AEL=append(AEL, ET(row)); remove edges whose ymax=row sort AEL by x-value fill spans update each edge in AEL 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Edge Table Row: 6 6 5 5 4 4 5 5 6 4 3 3 2 2 1 2 5 6 6 1 6 6 1 2 3 4 5 6 ymax xmin 1/m 03/07/02 (c) 2002 University of Wisconsin, CS559

Active Edge List (shown just before filling each row) 6 5 6 6 6 5 2 5 4 5 5 6 6 6 4 2 5 6 6 3 2 5 6 6 2 2 5 6 6 1 1 2 3 4 5 6 6 6 ymax x 1/m 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Edge Table Row: 6 6 5 5 4 4 3 3 2 2 1 2 1 5 6 -1 5 1 6 6 1 2 3 4 5 6 ymax xmin 1/m 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Active Edge List Row: 6 6 5 5 4 3 -1 5 5 1 5 4 3 4 1 5 4 -1 5 3 2 3 1 5 5 -1 5 2 1 2 1 5 6 -1 5 1 6 6 1 2 3 4 5 6 ymax x 1/m 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Comments Sort is quite fast, because AEL is usually almost in order Use bubble sort or insertion sort OpenGL limits to convex polygons, meaning two and only two elements in AEL at any time, and no sorting Can generate memory addresses (for pixel writes) efficiently Does not require floating point - next slide 03/07/02 (c) 2002 University of Wisconsin, CS559

Dodging Floating Point (for integer endpoints) For edge, m=x/y, which is a rational number View x as xi+xn/y, with xn<y. Store xi and xn Then x->x+m’ is given by: xn=xn+x if (xn>=y) { xi=xi+1; xn=xn- y } Advantages: no floating point can tell if x is an integer or not, and get floor(x) and ceiling(x) easily, for the span endpoints 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Anti-Aliasing Recall: We can’t sample and then accurately reconstruct an image that is not band-limited Infinite Nyquist frequency Attempting to sample sharp edges gives “jaggies”, or stair-step lines Solution: Band-limit by filtering (pre-filtering) What sort of filter will give a band-limited result? But when doing computer rendering, we don’t have the original continuous function 03/07/02 (c) 2002 University of Wisconsin, CS559

Pre-Filtered Primitives We can simulate filtering by rendering “thick” primitives, with , and compositing Expensive, and requires the ability to do compositing Hardware method: Keep sub-pixel masks tracking coverage Filter =1/6 1/6 =2/3 2/3 over =1/6 =1/6 1/6 =2/3 =1/6 Ideal Pre-Filtered and composited 03/07/02 (c) 2002 University of Wisconsin, CS559

Post-Filtering (Supersampling) Sample at a higher resolution than required for display, and filter image down Two basic approaches: Generate extra samples and filter the result (traditional super-sampling) Generate multiple (say 4) images, each with the image plane slightly offset. Then average the images Requires general perspective transformations Can be done in OpenGL using the accumulation buffer Issues of which samples to take, and how to average them Method used in most current hardware Note that anti-aliasing costs 4x regular rendering for 2x2 box filtering 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Where We Stand At this point we know how to: Convert points from local to window coordinates Clip polygons and lines to the view volume Determine which pixels are covered by any given line or polygon Anti-alias Next thing: Determine which polygon is in front 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Visibility Given a set of polygons, which is visible at each pixel? (in front, etc.). Also called hidden surface removal Very large number of different algorithms known. Two main classes: Object precision: computations that decompose polygons in world to solve Image precision: computations at the pixel level All the spaces in the viewing pipeline maintain depth, so we can work in any space World, View and Canonical Screen spaces might be used Depth can be updated on a per-pixel basis as we scan convert polygons or lines 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 Visibility Issues Efficiency – it is slow to overwrite pixels, or scan convert things that cannot be seen Accuracy - answer should be right, and behave well when the viewpoint moves Must have technology that handles large, complex rendering databases In many complex worlds, few things are visible How much of the real world can you see at any moment? Complexity - object precision visibility may generate many small pieces of polygon 03/07/02 (c) 2002 University of Wisconsin, CS559

Painters Algorithm (Image Precision) Choose an order for the polygons based on some choice (e.g. depth to a point on the polygon) Render the polygons in that order, deepest one first This renders nearer polygons over further Difficulty: works for some important geometries (2.5D - e.g. VLSI) doesn’t work in this form for most geometries - need at least better ways of determining ordering Fails zs Which point for choosing ordering? xs 03/07/02 (c) 2002 University of Wisconsin, CS559

The Z-buffer (1) (Image Precision) For each pixel on screen, have at least two buffers Color buffer stores the current color of each pixel The thing to ultimately display Z-Buffer stores at each pixel the depth of the nearest thing seen so far Also called the depth buffer Initialize this buffer to a value corresponding to the furthest point (z=1.0 for screen and window space) As a polygon is filled in, compute the depth value of each pixel that is to be filled if depth < z-buffer depth, fill in pixel color and new depth else disregard 03/07/02 (c) 2002 University of Wisconsin, CS559

(c) 2002 University of Wisconsin, CS559 The Z-buffer (2) Advantages: Simple and now ubiquitous in hardware A z-buffer is part of what makes a graphics card “3D” Computing the required depth values is simple Disadvantages: Over-renders - worthless for very large collections of polygons Depth quantization errors can be annoying Can’t easily do transparency or filtering for anti-aliasing (Requires keeping information about partially covered polygons) 03/07/02 (c) 2002 University of Wisconsin, CS559

Z-Buffer and Transparency Must render in back to front order Otherwise, would have to store first opaque polygon behind transparent one Front Partially transparent 3rd 1st or 2nd 3rd: To know what to do now Opaque 2nd Opaque 1st 1st or 2nd Recall this color and depth 03/07/02 (c) 2002 University of Wisconsin, CS559