More on Primitives and Rasterization

• There are usually at least three primitives in a graphics package
  • Points
  • Lines
  • Triangles.
• Sometimes there are other primitives
  • Circles
  • Bezier curves
• Simply drawing the primitives usually not enough.
  • Everything should have an associated color.
  • Points might have a "width"
  • Lines might have
    • A width or thickness
    • A pattern (dashed, dot dash, ...)
    • Antialised or not
    • End style.
  • Triangles also have various attributes (we will be there)
• Specifying attributes becomes a problem.
  • In our line example, we have 10 parameters.
  • We need at least four
  • But we might also need to add pattern, end style, ...
  • We could build a line object that we pass back an forth
    • This makes sense (sort of) in our object oriented world.
    • But is probably a memory hog, which turns into a communications hog in the graphics world.
    • And doesn't work with non object oriented languages (like C)
  • So packages like OpenGL use a "state machine" approach.
    • There is a current drawing color
      • Everything is drawn in this color until the default color is changed.
      • If a line is drawn, the color of each endpoint is recorded and used when drawing the line.
    • old OpenGL looked like this

      glBegin(GL_LINES);
         glColor3F(255,0,0);
         glVertex(20,20,0);
         glColor3F(0,255,0);
         glVertex(50,50,0);
      glEnd();
      	      

    • In this example, the data points and the attributes are described in separate commands.
    • Antialiasing is turned on and off in a single command

      glEnable(GL_LINE_SMOOTH);
      // all lines are drawn after this are drawn with antialiasing
      glDisable(GL_LINE_SMOOTH);
      // all lines are drawn after this are drawn without antialiasing
      

  • In some sense, you turn "on" or "off" an attribute switch.
  • And all actions are performed with this setting until it is changed.
  • In a system like svg
    • The attributes are tacked onto the command
    • Like we do in HTML

      <line x1="0" y1="0" x2 = "100" y2="100"  style="stroke: black; stroke-dasharray:9, 3, 5; stroke-width: 2;"/>
      <path d="M 300 300, 299.732 299.951,
      ...
      700.268, 700 700" style="fill:cyan;stroke:black;"/>
      

    • A line with multiple attributes
    • A path is a polyline
      • The M says to move to the coordinates and begin drawing
• Point size.
  • Old OpenGL, the user specified a float point size.
  • Note, OpenGL considers pixel coordinates at the CENTER of the pixel.
  • So 1/2 coordinates will lie on the corners of a pixel.
  • The manual states:

    the actual size is determined by rounding the supplied size to the nearest 
    integer. (If the rounding results in the value 0, it is as if the point 
    size were 1.) If the rounded size is odd, then the center point 
    (x, y) of the pixel fragment that represents the point is computed as
    
    xw + .5 yw + .5
    
    where w subscripts indicate window coordinates. All pixels that lie within
    the square grid of the rounded size centered at (x, y) make up the 
    fragment. If the size is even, the center point is
    
    xw + .5 yw + .5
    
    and the rasterized fragment's centers are the half-integer window 
    coordinates within the square of the rounded size centered at (x, y).
    All pixel fragments produced in rasterizing a nonantialiased point are
    assigned the same associated data, that of the vertex corresponding 
    to the point.
    	 

  • 
  • How would we properly accomplish a pixel width in our system?
  • Line width is accomplished in a similar manner.
• Antialiasing
  • As we saw last time, Bresenham's produces lines with the "jaggies"
  • This is because we are drawing in the discrete world of the frame buffer.
  • Some frame buffers allow sub pixel sampling, but we need to handle the case where this is not true.
  • And the solution will be the same...
  • One algorithm is Wu's line algorithm
    • Slower than Bresenham's
      • Gives up on the integer only computation.
    • But draws "smooth" lines.
      • These are usually described as "ropey"
    • Can handle lines with non-integer endpoints.
    • The basic idea
      • Just draw the endpoints.
      • For each other point, use the distance between the two possible pixels to compute a "shade" for each.
      • 
      • Stolen from wikipedia.
      • In the code, gradient is the slope or 1/m
      • fpart is the fractional part of a number.
      • rfpart is 1-fpart
      • These are the distances (d1 and d2) from yesterday.
      • They are how far the line is from this pixel and the one beside it.
      • They are used to compute how "bright" a pixel should be displayed.
      • The heart of the algorithm is :

      • for (x = xPixel1 +1; x < xPixel2; x++) {
             this.SetPoint(ipart(y), x,r1,g1,b1,rfpart(y));
             this.SetPoint(ipart(y)+1, x,r1,g1,b1,fpart(y));
             y = y + gradient;
        }
        
        

      • It was too late when I discovered why I was not darkening my pixels to "white",
      • So I swapped the background to be black.
      • A real fix would be convert to hsl, move UP the l value by a given percent and return to rgb.
      • See this demo