CS 476: Computer Graphics Lecture Notes

• Lecture 1
• Lecture 2
• Lecture 3
• Lecture 4
• Lecture 5
• Lecture 6
• Lecture 7
• Lecture 8
• Lecture 9
• Lecture 10
• Lecture 11
• Lecture 12
• Lecture 13
• Lecture 14
• Lecture 15
• Lecture 16
• Lecture 17
• Lecture 18
• Lecture 19
• Lecture 20
• Lecture 21

Graphics is not just rendering

• graphic design
• ray tracing and rendering
• mathematical models of places and entities within them
• graphics hardware, libraries, and window systems API's
• user interfaces and graphical input

History

• Before there was interactive computer graphics, there was non-interactive graphics with several thousands of years of experience and expertise.
• Ivan Sutherland invented a good part of modern interactive graphics for the system called "Sketchpad" that was his Ph.D. thesis. Graphics was done using vector displays and pen plotters; input with light pens.
• Much of the rest of modern interactive graphics was invented at Xerox PARC in the 1970's, especially bitmapped raster graphics, "windows", etc.

Graphics Hardware

Two of the significant changes in the past 10 years:

1. "True Color" is now ubiquitous
2. 3D graphics acceleration is now ubiquitous

Frame Buffers

Generally the operating system and/or window system limit access to the frame buffer. There is conflict between abstraction and performance. 3D graphics "accelerator" hardware capabilities are increasingly "higher level", to where writing to the frame buffer yourself makes less and less sense.

Graphics API's

lecture #2 began here

Implementing DrawPixel(w,x,y)

Homework #0 postulated the use of a primitive for setting an individual dot (pixel, picture element) on the screen, and the previous lecture described the frame buffer used to store the contents of the screen in memory. So, how do we implement DrawPixel() ? The following pseudocode fragments approximate it for a display WIDTH x HEIGHT whose frame buffer is an array of bytes for which we have a pointer named fb. Implementation for real hardware would vary depending e.g. on whether the processor was "big-endian" or "little-endian", whether a 1-bit means black or means white, etc.

Monochrome (1-bit per pixel) case

    void DrawPixel(int x, int y, int value)
    {
	int index = y * HEIGHT + x / 8;	
	int bit = y * HEIGHT + x % 8;	
	if (value) { /* set the bit on */
	   fb[index] |= 1 << bit;
	   }
        else { /* set the bit off */
	   fb[index] &= ~(1 << bit);
           }
    }
    

True Color (packed 24-bits per pixel) case

   void DrawPixel(int x, int y, int value)
   {
      int index = (y * HEIGHT + x) * 3;
      fb[index++] = value & 255;
      fb[index++] = (value>>8) & 255;
      fb[index]   = (value>>16) & 255;
   }
   

Line Drawing

Horizontal line from (x1, y) to (x2, y)

    procedure DrawHoriz(x1,x2,y) # while loop version
        x := x1
        while x <= x2 do {
           DrawPoint(x,y)
           x := x + 1
           }
    end

or

    procedure DrawHoriz(x1,x2,y) # "for"-loop version
        every x := x1 to x2 do {
           DrawPoint(x,y)
           }
    end
   

Brute force (incremental) line algorithm (based on: y = mx + B)

   # note: use real numbers and round off, to avoid numeric errors
   procedure DrawLine0(x1,y1,x2,y2)
      m := real(y2 - y1) / real(x2 - x1)
      y := real(y1)
      every x := x1 to x2 do {
         DrawPoint(x, integer(y + 0.5)) # round off
	 y +:= m
         }
   end

Midpoint algorithm (Bresenham, Pitteway, Van Aken)

Another important line algorithm was developed in the 60's and subsequently refined. Starting from the form F(x,y) = ax + by There is some cleverness here, to avoid any need for floating point numbers, which speeds things up greatly, especially on machines that do not have floating point instructions! See Figure 3.7 and read that section (3.2.2) carefully!

   procedure DrawLine1(x1,y1,x2,y2)
      dx := x2 - x1
      dy := y2 - y1
      d  := 2 * dy - dx
      incrE := 2 * dy
      incrNE := 2 * (dy - dx)
      x := x1
      y := y1
      DrawPoint(x,y)
      while x < x2 do {
         if d <= 0 then {
            d +:= incrE
            x +:= 1
            }
         else {
            d +:= incrNE
            x +:= 1
            y +:= 1
            }
         DrawPoint(x,y)
         }
    end

API parameters and graphic contexts

lecture #3 began here

Midpoint Line Algorithm Example

incrE 6 incrNE -14
x 50 y 50 d -4
x 51 y 50 d 2
x 52 y 51 d -12
x 53 y 51 d -6
x 54 y 51 d 0
x 55 y 51 d 6
x 56 y 52 d -8
x 57 y 52 d -2
x 58 y 52 d 4
x 59 y 53 d -10
x 60 y 53 d -4

Color Indices and Colormaps

Circle Drawing

To avoid the discontinuity you can write a loop that steps through small angular increments and uses sin() and cos() to compute x and y.

Brute force circle algorithm (based on: y == +- sqrt(R^2 - x^2))

How small an angular increment is needed? our distance is 2 * pi * R pixels worth of drawing; we need angular increments R small enough to make these adjacent. 1/R radians gives a nice solid circle; angular steps twice as large still look like a connected, thinner circle.

   procedure DrawCircle0(x,y,R)
      every angle := 0.0 to 2 * &pi by 1.0 / R do {
	 px := x + sin(angle) * R
	 py := y + cos(angle) * R
	 DrawPoint(px,py)
         }	
   end

8 Way Symmetry

Symmetry can speed up and simplify computations. We can do 1/8 as many calls to sin(), cos(), etc. This code also relies on "translation" of coordinates from (0,0) to an origin of (x0,y0). Translation is the first of many coordinate transformations you will see.

   procedure CirclePoints(x0, y0, x, y)
      DrawPoint(x0 + x, y0 + y)
      DrawPoint(x0 + y, y0 + x)
      DrawPoint(x0 + y, y0 - x)
      DrawPoint(x0 + x, y0 - y)
      DrawPoint(x0 - x, y0 - y)
      DrawPoint(x0 - y, y0 - x)
      DrawPoint(x0 - y, y0 + x)
      DrawPoint(x0 - x, y0 + y)
   end

Mid-point (or Bresenham) circle algorithm

Like the mid-point line algorithm, it is possible to do a much more efficient incremental job of drawing a circle. See Fig 3.14. The procedure is very similar to the Mid Point line algorithm.

   procedure DrawCircle1(x0,y0,R)
      x := 0
      y := R
      d := 5.0 / 4.0 - R
      CirclePoints(x0, y0, x, y)
      while (y > x) do {
         if d < 0 then {
            d +:= 2.0 * x + 3.0
            }
         else {
	    d +:= 2.0 * (x - y) + 5.0
            y -:= 1
            }
         x +:= 1
	 CirclePoints(x0, y0, x, y)
         }
   end

Raster Operations

The most interesting raster operation is probably XOR. It has the property that XOR'ing a pixel value a second time restores the pixel to its former contents, giving you an easy "undo" for simple graphics. On monochrome displays XOR works like a champion, but on color displays it is less useful, because the act of XOR'ing in a pixel value may produce seemingly random or indistinct changes, especially on color index displays where the bits being changed are not color intensities. If a color display uses mostly a foreground color being drawn on a background color, drawing the XOR of the foreground and background colors in XOR mode works pretty much the way regular XOR does on monochrome displays.

An Overview of Icon's Graphics Facilities

WOpen(), WClose()

Bg(), Fg(), WAttrib()

DrawPoint(), DrawLine()

{Draw,Fill}{Arc,Circle,Polygon,Rectangle}

DrawCurve()

Event()

Pixel()

Region Filling

The border that defines a region may be 4-connected or 8-connected. 4-connected regions do not consider diagonals to be adjacent; 8-connected regions do. The following algorithms demonstrate brute force filling. The foreground color is presumed to be set to "new".

# for interior-defined regions. old must not == new
procedure floodfill_4(x,y,old,new)
   if Pixel(x,y,1,1) === old then {
      DrawPoint(x,y)
      floodfill_4(x,y-1,old,new)
      floodfill_4(x,y+1,old,new)
      floodfill_4(x-1,y,old,new)
      floodfill_4(x+1,y,old,new)
      }
end

# for boundary-defined regions.  the new color may be == to the boundary
procedure boundaryfill_4(x, y, boundary, new)
   p := Pixel(x,y,1,1) # read pixel
   if p ~== boundary & p ~== new then {
      DrawPoint(x,y)
      boundaryfill_4(x,y-1,boundary,new)
      boundaryfill_4(x,y+1,boundary,new)
      boundaryfill_4(x-1,y,boundary,new)
      boundaryfill_4(x+1,y,boundary,new)
      }
end

lecture #5 began here

More reading the frame buffer with Pixel()

Pixel(x,y,w,h) asks for all the pixels in a rectangular region with a single network transaction, which will be must faster than reading each pixel individually. In general, client-side "image" structures are not interchangeable with server-side "pixmap" and "window" structures, but this is an unfortunate limitation of their design.

How, how do you store a local (client-side) copy of a window in order to work with it efficiently? There are many ways you can represent an image, but we will start with a couple of brute force representations using lists of lists and tables of tables.

Faster Fills

1. Eliminate recursion, replace it with list operations and loops
2. Reduce the number of redundant checks on each pixel
3. Think in terms of line segments instead of individual pixels when possible.

# nonrecursive boundary fill.  the new color may be == to the boundary
procedure nr_boundaryfill_4(x, y, boundary, new)
   L := [x, y]
   while *L > 0 do {
      x := pop(L)
      y := pop(L)
      p := Pixel(x,y,1,1) # read pixel
      if p ~== boundary & p ~== new then {
         DrawPoint(x,y)
	 put(L, x, y-1)
	 put(L, x, y+1)
	 put(L, x-1, y)
	 put(L, x+1, y)
         }
      }
end

Backing Store and Expose Events

Under these various circumstances, window systems may discard part or all of an application's screen contents, and ask the application to redraw the needed portion of the screen later, when needed. A window system tells an application to redraw its screen by sending it an "expose" or "paint" event. Some applications just maintain a data structure containing the screen contents and redraw the screen by traversing this data structure; this is the raster graphics analog of the old "display list" systems used in early vector graphics hardware. But clients are complicated unnecessarily if they have to remember what they have already done. The obvious thing to do, and the thing that was done almost immediately, was to add to the window system the ability to store screen contents in an off-screen bitmap called a backing store, and let it do its own redrawing. Unfortunately, evil software monopolists at AT&T Bell Labs such as Rob Pike patented this technique, despite not having invented it, and despite its being obvious. This leaves us in the position of violating someone's patent whenever we use, for example, the X Window System.

Smooth Curves

Contexts and Cloning

• colors: fg, bg, reverse, drawop, gamma
• text: font, fheight, ...
• drawing: fillstyle, linestyle, linewidth, pattern
• clipping: clipx, clipy, clipw, cliph
• translation: dx, dy

• window: label, image, canvas, pos, posx, posy
• size: resize, size, height, width, rows, columns
• icon: iconpos, iconlabel, iconimage
• text: echo, cursor, x, y, row, col
• pointer: pointer, pointerx, pointery, pointerrow, pointercol
• screen: display, depth, displayheight, displaywidth

Clipping

Fonts

Fonts have: height, width, ascent, descent, baseline. Font portability is one of the major remaining "issues" in Icon's graphics facilities. There are four "portable font names": mono, typewriter, sans, serif, but unless/until these become bit-for-bit identical, programs that use text require care and/or adjustment in order to achieve portability. You can "fish for a font" with something like:

   Font(("Frutiger"|"Univers"|"Helvetica"|"sans") || ",14")

Proportional width fonts may be substantially more useful, but require substantially more computation to use well than do fixed width fonts. TextWidth(s) tells how many pixels wide string s is in a window's current font. Here is an example that performs text justification.

procedure justify(allwords, x, y, w)
   sofar := 0
   thisline := []
   while word := pop(allwords) do {
      if sofar + TextWidth(word) + (*thisline+1) * TextWidth(" ") > w then {
         setline(x, y, thisline, (w - sofar) / real(*thisline))
         thisline := []
         sofar := 0
	 y +:= WAttrib("fheight")
         }
      }
end
procedure setline(x,y,L,spacing)
   while word := pop(L) do {
      DrawString(x,y,word)
      x +:= TextWidth(s) + spacing
      }
end

Curve Drawing

brute force

You can just represent the curve with every point on it, or with very tiny polylines. This method is memory intensive and makes manipulating the curve untenably tedious. The remaining options represent the curve with mathematical function(s) that approximate the curve.

explicit functions y=f(x)

does not handle curves which "double back"

implicit equations f(x,y)=0

hard to write equations for parts of curves, hard to sew multiple curves together smoothly

parametric equations x=x(t) y=y(t)

avoids problems with slopes; complex curves are sewn together from simpler ones; usually cubic polynomials are sufficient for 3D. See equations 11.5-11.7.

Sewing together curves is a big issue: the "slope" (endpoint tangent vectors are used to track these) of both curves must be equal at the join point.

Splines

Smooth Curves - an algorithm

record Point(x,y)
procedure gencurve(p)

#   float  ax, ay, bx, b_y, stepsize, stepsize2, stepsize3;
#   float  x, dx, d2x, d3x, y, dy, d2y, d3y;


   every i := 4 to *p do {
      #
      # build the coefficients ax, ay, bx and b_y, using:
      #                             _              _   _    _
      #   i                 i    1 | -1   3  -3   1 | | Pi-3 |
      #  Q (t) = T * M   * G   = - |  2  -5   4  -1 | | Pi-2 |
      #               CR    Bs   2 | -1   0   1   0 | | Pi-1 |
      #                            |_ 0   2   0   0_| |_Pi  _|
      #

      ax := p[i].x - 3 * p[i-1].x + 3 * p[i-2].x - p[i-3].x
      ay := p[i].y - 3 * p[i-1].y + 3 * p[i-2].y - p[i-3].y
      bx := 2 * p[i-3].x - 5 * p[i-2].x + 4 * p[i-1].x - p[i].x
      b_y := 2 * p[i-3].y - 5 * p[i-2].y + 4 * p[i-1].y - p[i].y

      #
      # calculate the forward differences for the function using
      # intervals of size 0.1
      #
      steps := max(abs(p[i-1].x - p[i-2].x), abs(p[i-1].y - p[i-2].y)) + 10

      thepoints := [ ]

      stepsize := 1.0 / steps
      stepsize2 := stepsize * stepsize
      stepsize3 := stepsize * stepsize2

      x := p[i-2].x
      y := p[i-2].y
      put(thepoints, x, y)
      dx := (stepsize3*0.5)*ax + (stepsize2*0.5)*bx +
	   (stepsize*0.5)*(p[i-1].x-p[i-3].x)
      dy := (stepsize3*0.5)*ay + (stepsize2*0.5)*b_y +
	   (stepsize*0.5)*(p[i-1].y-p[i-3].y)
      d2x := (stepsize3*3) * ax + stepsize2 * bx
      d2y := (stepsize3*3) * ay + stepsize2 * b_y
      d3x := (stepsize3*3) * ax
      d3y := (stepsize3*3) * ay

      # calculate the points for drawing (this piece of) the curve

      every 1 to steps do {
	 x   +:= dx
	 y   +:= dy
	 dx  +:= d2x
	 dy  +:= d2y
	 d2x +:= d3x
	 d2y +:= d3y
	 put(thepoints, x, y)
         }
      DrawLine ! thepoints
      }
end

Smooth Curves - a slight embarassment

After my first pass, it was obvious some pixels seem to be missing, not just from the Icon version, but from the "official" built-in version! Some missing pixels were filled in by adding another line segment to the end of each step:

To fill in more pixels, I traced the actual execution behavior, and saw some pixels in the generated output not showing up! Pixels in green are generated by the algorithm but not shown in the drawn curve:

Images

• file formats
• window system native (in X11, server side)
• client-side image manipulation

Window system native manipulation starts with off-screen invisible windows you can draw on, and copy to visible windows from. A window opened with "canvas=hidden" in Icon can be used for this purpose; CopyArea(w1,w2,x,y,wd,ht,x2,y2) or WAttrib("canvas=normal") are examples of ways to get hidden graphics onto the screen.

lecture #9 began here

Client Side Image Manipulation in Icon

"width,palette,data"

a color or gray scale image, each data char represents one pixel.

"width,#data"

a bilevel image, bits from data are interpreted as fg and bg colors.

Gamma Correction

2D Geometrical Transformations

lecture #10 (virtual lecture) began here

Window-to-Viewport (from CG section 5.4)

A second set of transformations is applied to the graphics primitives to get to the "physical coordinates", or "viewport" of whatever hardware is rendering the graphics. The viewport's physical coordinates might refer to screen coordinates, printer device coordinates, or the window system's window coordinates.

If the world coordinates and the physical coordinates do not have the same height-width aspect ratio, the window-to-viewport transformation distorts the image. Avoiding distortion requires either that the "world-coordinate window" rectangles match the viewport rectangles' shapes, or that part of the viewport pixels go unused and the image is smaller.

Matrix Representations of 3D Coordinate Transformations

Translation is extended from the 2D case:

T(dx,dy,dz) =	1 0 0 dx 0 1 0 dy 0 0 1 dz 0 0 0 1

Scaling is similarly extended:

S(dx,dy,dz) =	Sx 0 0 0 0 Sy 0 0 0 0 Sz 0 0 0 0 1

Rotation is a little more interesting; the rotation around the origin that we did before now becomes rotation around the z-axis with the following matrix:

Rz(θ) =	cos θ -sin θ 0 0 sin θ cos θ 0 0 0 0 1 0 0 0 0 1

But there are two more axes one might want to rotate about:

Rx(θ) =	1 0 0 0 0 cos θ -sin θ 0 0 sin θ cos θ 0 0 0 0 1

Ry(θ) =	cos θ 0 sin θ 0 0 1 0 0 -sin θ 0 cos θ 0 0 0 0 1

Composition of 3D Transformations (CG section 5.7)

Change in Coordinate Systems

lecture #11 (virtual lecture) began here

All About Colors

We have some basic introduction to color earlier, namely the RGB color coordinate system commonly used on computer monitors. Computer hardware commonly uses 24-bits to express color information for each pixel, while software may use another coordinate system, such as X11's 48-bit system.

It may surprise you to hear that RGB color coordinates are a relatively new invention, constructed solely as a by-product of the hardware used in color monitors. RGB is not used in traditional color disciplines such as photography or print shops. Interestingly, RGB is not even capable of expressing many colors that humans recognize. We will see aspects of that and other issues in this talk.

Intensity

The truth is that humans vary a fair amount in their perception, ranging from those who are blind to those who can see details far more precisely than average. As was mentioned in the discussion of gamma correction, human perception of brightness is on a log scale; we perceive ratios of intensity, not absolute values. Having appropriate gamma correction might affect how many intensities are needed in a given application.

Hue

Saturation

Additive and Subtractive Color Models

For colors that are formed by subtracting (filtering) out of white light from what will be reflected, the colors cyan, magenta, and yellow are subtractive primary colors; they are complements of red (cyan="no red"), green (magenta="no green"), and blue (yellow="no blue"). CMY coordinates are commonly used on color printers. Adding a fourth color (pure black) typically improves the quality and reduces ink costs by giving blacker blacks than the dull gray you get from using all three CMY inks to produce "black" by regular subtraction.

There are other significant color models in wide use; for example color TV signals use a model (YIQ) that emphasizes intensity but also tacks on hue and saturation using a lower amount of bandwidth. YIQ uses twice as much bandwidth for intensity as for all other color information, and is mapped onto both monochrome and color (RGB) TV sets.

lecture #12 began here

Introducing OpenGL

OpenGL actually consists of two libraries (GL and GLU), and to use it you must either write window system code yourself (X11 or Win32) or use a third party library such as "glut" to handle window creation and user input. Here is a sample Makefile for compiling an OpenGL program (simple.c) on our local linux environment:

LDLIBS = -L/local/Mesa4.01/lib -lglut -lGLU -lGL -L/usr/X11R6/lib -lXmu -lX11 -lm
INCL = -I/local/Mesa4.01/include -I/usr/X11R6/include
simple: simple.c
	cc -o simple $(INCL) simple.c $(LDLIBS)

In addition to this makefile, it turns out that you will need a LD_LIBRARY_PATH environment variable in order for the system to find your glut shared library. This is set in your .cshrc file with something like:

setenv LD_LIBRARY_PATH /local/Mesa4.01/lib

Compared with the earlier Icon 2D interface we have seen, OpenGL has many more features, and more complexity, for 3D programming. The glut library which interfaces OpenGL to the host window system is simple and easy to use, but limited and restrictive in its capabilities.

Callbacks

Composing graphics primitives

glBegin glVertex+ glEnd

This lecture is presenting selected material from the OpenGL Primer, chapter 2.

A Bevy of OpenGL and GLUT Functions

int glutCreateWindow(char *title)

Regarding window creation with glutCreateWindow(), I need to emphasize the point that you can create multiple windows, each call will return a separate integer "identifier". The example simple.c is slightly misleading since it uses old-style K&R C, implying glutCreateWindow() returns void. Since the OpenGL functions don't take a window argument, you can expect to find another helper function down the road which sets which window subsequent calls are directed to, stored in some hidden global variable.

void glutDisplayFunc(void (*func)(void))

As the book emphasizes, your callback takes no parameters, so expect to use a lot of global variables in your opengl programs.

glVertex*

There are 3 X 4 X 2 = 24 versions of this function! It may be moderately inefficient to call this function 100 times in order to specify a single, 100-vertex polygon. You should be looking for whether there is any mechanism to streamline this.

glFlush()

Most graphics systems buffer output even heavily, just as standard file I/O systems do. In particular X11 buffers output to reduce the number of network packets it uses.

glutInitWindowPosition(x,y), glutInitWindowSize(width, height)

Most applications will use these typical convenience functions. They store values in global variables for later use. Call them before glutCreateWindow().

Color in OpenGL

Consider now the task of setting the foreground color with which objects are drawn. Although colors are real numbers between 0 and 1, you can use almost any numeric type to supply RGB values; integer values are converted into fractions of the maximum value, so for example many programmers who are used to working with 8 bits each of R, G, and B, can call a function that takes values like (255, 127, 0) and internally this is converted to the equivalent (1.0, 0.5, 0).

So, like the glVertex family, there are many (28) functions in the families that set the foreground color, glColor*. An example call would be: glColor3f(1.0, 0.5, 0.0). Apparently they didn't bother to make 28 functions for setting the background color with glClearColor(), because that operation is far less common.

This discussion of color is well and good, but tragically it all becomes meaningless as you transition from "toy" programs to more realistic ones, because once you introduce lighting into your application, glColor*() has no effect! When lighting is introduced, the color of objects becomes a function of the color of light and the reflective properties of the objects, specified by "materials". We will see lighting in detail a little later.

Cameras, take one

OpenGL Transformation Matrices

When you use gluOrtho2D() you are manipulating the projection matrix. Functions like gluOtho2D modify (i.e. to a matrix multiply into) whatever is in the matrix already, and if you want to start from a known position, you need to reset the matrix to the identity matrix with glLoadIdentity(), so the complete code to specify a 2D window on the world in OpenGL looks like

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(x1,x2,y1,y2);

More OpenGL Graphic Primitives

Points

GL_POINTS are not usually very interesting in 3D graphics, but opengl supports them and even has a "point size" attribute (set by function glPointSize()) that says how large (in pixels) plotted points should appear. Are points round, or square? Are they really spheres in a 3D scene? The fact that their "size" is given in pixels is at odds with the world coordinates used to specify position, so you can be suspicious that points are a "special case" hack in OpenGL.

Lines

There are three opengl primitives for depicting lines, similar to the two primitives used in Icon's 2D graphics. GL_LINES draws disconnected segments between pairs of points, similar to Icon's DrawSegment(), while GL_LINE_STRIP draws lines between every adjacent pair of points, forming a single connected object. GL_LINE_LOOP also the first and last points specified, for people too lazy to repeat the first point at the end. Lines have a color, a thickness (glLineWidth()), and a so-called stipple pattern that let's you specify dashes or dots in the lines you draw. But, you can only use these line styles if you call glEnable(GL_LINE_STIPPLE).

Triangles, Triangle Strips, Triangle Fans

Triangles get a lot of attention in 3D graphics because they are the smallest number of points necessary to specify a portion of a solid object's surface. 3D graphics hardware supports the rendering of triangles directly, while more complex surfaces are usually composed of many many (possibly millions) triangles. In addition to GL_TRIANGLES, are are cleverly optimized ways to specify sequences of physically connected triangles without having to specify the vertices they have in common multiple times. The net effect is only having to specify one new vertex per triangle. GL_TRIANGLE_STRIP connects each vertex with the previous two, while GL_TRIANGLE_FAN connects each vertex with the previous one, and the first vertex.

Quads and Quad Strips

Four vertex objects are also common, and may be rendered in hardware or broken up into triangles for rendering. GL_QUAD_STRIP defines each new quad using the last two vertices and two new vertices, costing new vertices per quad. As an afterthought, OpenGL also supports conventional 2D rectangles with the glRect* family.

Polygons

GL_POLYGON is the most general of these primitives, and is typically broken down into triangles during rendering. It is analogous to FillPolygon() in Icon's graphics. It is worth mentioning a few extra items relating to polygons. If their vertices cross, OpenGL's semantics are not guaranteed, implementations can handle them however they please. And convex polygons are MUCH easier and faster to render. If you use multiple colors in the middle of a glBegin/glEnd pair, opengl will use interpolation to gradually change the colors. You can specify glShadeModel(GL_FLAT) if you want each primitive to be a single color instead of an interpolation of the varying colors of its vertices.

Viewports

glViewport(x, y, w, h) maps the current projection onto a specific region within the selected window. lecture #14 began here.

Reshape and Idle callbacks

Keyboard and Mouse

Display Lists

glNewList(myhandle, GL_COMPILE);
glPushAttrib(CL_CURRENT_BIT);
glColor3f(1.0,0.0,0.0);
glRectf(-1.0,0.0,0.0);
glPopAttrib();
glEndList();
...
glCallList(myhandle);

Selection Mode

void mouse(int button, int state, int x, int y)
{
...
glInitNames();
glPushName(0);
glSelectBuffer(SIZE, nameBuffer);
glGetIntegerv(GL_VIEWPORT, viewport);
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
gluPickMatrix((GLdouble)x,(GLdouble)(viewport[3]-y),N,N,viewport);
gluOrtho2D(xmin,xmax,ymin,ymax);

draw_objects(GL_SELECT);
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glFlush();

hits = glRenderMode(GL_RENDER);
processHits(hits, nameBuffer);
glutPostRedisplay();
}

   glClear(GL_COLOR_BUFFER_BIT);
   draw_objects(GL_RENDER);
   glFlush();

void draw_objects(GLenum mode)
{
   if (mode == GL_SELECT) glLoadName(1);
   glColor3f(1.0,0.0,0.0);
   glRectf(-0.5,-0.5,1.0,1.0);
   if (mode == GL_SELECT) glLoadName(2);
   glColor3f(0.0,0.0,1.0);
   glRectf(-1.0,-1.0,0.5,0.5);
}

void processHits(GLint hits, GLuint buffer[])
{
   unsigned int i, j;
   GLuint names, *ptr;
   printf("hits = %d\n", hits);
   ptr = (GLuint *) buffer;

   for (i = 0; i < hits; i++) {
      names = *ptr;
      ptr += 3; /* skip over number of names and depths */
      for (j = 0; j < names; j++) {
         if (*ptr == 1) printf("red rectangle\n");
         else printf("blue rectangle\n");
         ptr ++;
      }
   }
}

Cameras

orthographic projection

camera is at infinity, projection plane is near the objects

glOrtho(left,right,bottom,top,near,far)

3D orthographic projection defines a viewable box

gluLookAt(ex,ey,ez,ax,ay,az,ux,uy,uz)

Specify eye position and orientation.

gluPerspective(yangle, aspectratio, near, far)

3D perspective projection, defines a viewable box

Building objects

void cube()
{
  glColor3f(1.0,0.0,0.0);

  glBegin(GL_POLYGON);
  glVertex3f(-1.0,-1.0,-1.0);
  glVertex3f(-1.0,1.0,-1.0);
  glVertex3f(-1.0,1.0,1.0);
  glVertex3f(-1.0,-1.0,1.0);
  glEnd();
  /* other 6 faces similar) */
}

Hidden Surface Removal

OpenGL uses z-buffers, or depth buffers, which are extra memory buffers, to track different objects' relative depths. This is built-in, but you have to turn it on to get its benefits. Also, if any of your objects are see-through, you will need to read more details on z-buffering in the OpenGL references.

glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH);
glEnable(GL_DEPTH_TEST);
...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

GLU and GLUT objects

OpenGL Transformations

• Points and directions (vectors) may be represented similarly, but they aren't the same.
• translating to a positive z value may move an object behind the camera in its default location.
• typical translation example:

     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glTranslatef(0.0, 0.0, -1.0); /* move object away/in front of camera*/
  

• multiple objects, independent world coordinates

     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glTranslatef(0.0, 0.0, -1.0); /* move object 1 */
     glutWireTetrahedron();
     glLoadIdentity();
     glTranslatef(0.0, 0.0, -3.0); /* move object 2, further away */
     glutWireCube();   
  

• multiple objects, 2nd object relative to first. Note transformations are concatenated/composed together by default.

     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glTranslatef(0.0, 0.0, -1.0); /* move object 1 */
     glutWireTetrahedron();
     glTranslatef(0.0, 0.0, -2.0); /* move object 2, -2 further than object 1 */
     glutWireCube();   
  

• positive rotation == counterclockwise. Rotation's fixed point is the origin.
• the last transformation specified in the program is the first one applied.
• typical rotation:

     glMatrixMode(GL_MODELVIEW);
     glLoadIdentity();
     glTranslatef(x, y, z); /* move object back from origin */
     glRotatef(angle, dx, dy, dz); /* rotate about axis specified by vector */
     glTranslatef(-x, -y, -z); /* move object to origin */
  

• glScalef(sx,sy,sz) works very much like you think it would

Hierarchical Model Example

void base()
{
   glPushMatrix(); /* make our local copy */
   glRotatef(-90.0, 1.0, 0.0, 0.0);
   gluCylinder(p, BASE_RADIUS, BASE_RADIUS, BASE_HEIGHT, 5, 5);
   glPopMatrix();
}
void lower_arm()
{
   glPushMatrix(); /* make our local copy */
   glTranslate(0.0,0.5*LOWER_ARM_HEIGHT,0.0); /* translate to our center */
   glScalef(LOWER_ARM_WIDTH, LOWER_ARM_HEIGHT, LOWER_ARM_WIDTH);
   glutWireCube(1.0);
   glPopMatrix();
}
void upper_arm()
{
   glPushMatrix(); /* make our local copy */
   glTranslate(0.0,0.5*UPPER_ARM_HEIGHT,0.0); /* translate to our center */
   glScalef(UPPER_ARM_WIDTH, UPPER_ARM_HEIGHT, UPPER_ARM_WIDTH);
   glutWireCube(1.0);
   glPopMatrix();
}
void display()
{
   glClear(GL_COLOR_BUFFER_BIT);
   glMatrixMode(GL_MODELVIEW);
   glLoadIdentity();
   glColor3f(1.0,0.0,0.0); /* isn't this poor way to say "red" ? */  
   glRotatef(theta[0], 0.0, 1.0, 0.0);
   base();
   glTranslatef(0.0,BASE_HEIGHT,0.0);
   glRotate(theta[1], 0.0, 0.0, 1.0);
   lower_arm();
   glTranslatef(0.0,LOWER_ARM_HEIGHT,0.0);
   glRotatef(theta[2], 0.0, 0.0, 1.0);
   upper_arm();
   glutSwapBuffers();
}

typedef struct treenode {
  GLfloat m[16];
  void (*f)();
  struct treenode *sibling, *child;
} treenode;

void traverse(treenode *root)
{
   if (root == NULL) return;
   glPushMatrix();
   glMultMatrix(root->m);
   root->f();
   traverse(root->child);
   glPopMatrix();
   traverse(root->sibling);
}

void display()
{
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   glMatrixMode(GL_MODELVIEW);
   glLoadIdentity();
   traverse(torso_root);
   glutSwapBuffers();
}

where

treenode *torso_root = malloc(sizeof(treenode));
torso_root->f = torso;
glLoadIdentity();
glRotatef(theta[0], 0.0, 1.0, 0.0);
glGetFloatv(GL_MODELVIEW_MATRIX, torso_root->m);
torso_root->sibling = NULL;
torso_root->child = head_node;
... etc.

lecture #17 began here

Lighting

In OpenGL, light calculations are done on a polygon by polygon basis. To get more realistic shading, break your objects into more polygons.

Phong Model

Diffuse reflection

These are dull surfaces that spread their light fairly evenly. They absorb some of the light (different percents for R, G, and B)

Specular reflection

Shiny surfaces reflect strongly along the angle of reflection; how much light reaches the viewer depends on whether they are on or near the angle of reflection or not.

Ambient reflection

Ambient light is light from so many sources and so many reflective surfaces that it doesn't appear to have any particular direction to it.

Emission

Light sources themselves may be visible in a scene, and they may reflect light in addition to whatever light they themselves emit.

OpenGL Light Sources

glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);

To specify a light source, you call glLight*(light, param, value) where light is an integer code (which light) param is what to set, and value is the value for that param. For example, the (x,y,z) location of light 0 would be

GLfloat a[] = {1.0, 2.0, 3.0, 1.0};
glLightfv(0, GL_POSITION, a);

Materials

typedef struct material {
  GLfloat ambient[4];
  GLfloat diffuse[4];
  GLfloat specular[4];
  GLfloat shininess;
} material;

material redPlastic = {
  {0.3, 0.0, 0.0, 1.0},
  {0.6, 0.0, 0.0, 1.0},
  {0.8, 0.6, 0.6, 1.0},
  32.0
} rp;
...
glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT, rp.ambient);
glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, rp.diffuse);
glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, rp.specular);
glMaterialf (GL_FRONT_AND_BACK, GL_SHININESS, rp.shininess);
glNormal3f(nx, ny, nz); /* unit normal appropriate for this object */
glBegin(...);
...red plastic object
glEnd();

Images (chapter 7)

There is a "raster position", or pixel cursor, set using glRasterPos(), and a function

 glBitmap(height, width, x, y, x2, y2, bits)

Reading and Writing Pixels

glDrawPixels(height, width, GL_RGB, GL_UNSIGNED_BYTE, imagebits)

glReadPixels(0,0,rows,columns,GL_RGB,GL_UNSIGNED_BYTE, imagebits)

glCopyPixels(x,y,w,h, GL_COLOR)

Intro to Texture Mapping

• Identify/create an image
• Define parameters to apply the texture
• Define "texture coordinates" for vertices in graphics primitives

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 64, 64, 0, GL_RGB, GL_UNSIGNED_BYTE, imagebits);

Textures are applied to geometric primitives by defining the mapping between texel coordinates and vertices:

glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0);
glVertex3f(vertex[0]);
glTexCoord2f(0.0, 1.0);
glVertex3f(vertex[1]);
glTexCoord2f(1.0, 1.0);
glVertex3f(vertex[2]);
glTexCoord2f(1.0, 0.0);
glVertex3f(vertex[3]);
glEnd();

glTexParameter*(target, name, value)

glTextParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTextParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);

Texture Examples

lecture #20 began here

If we set the texture to replace, rather than mix, with the vertex colors, we will get an image that is closer to what we expected:

 glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE); 

Width and height of a texture must be powers of 2! You should set your source (.jpg, .gif, whatever) to be a power of 2 in the first place, but there is a glScaleImage() function that you can use to changes its dimensions if it is not.

Mipmaps

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST_MIPMAP_NEAREST);

Texture Coordinate Generation

 gluQuadricTexture(GLUquadricObj *obj, GLboolean); 

GLfloat plane_s = {0.5, 0.0, 0.0, 0.5};
GLfloat plane_t = {0.0, 0.5, 0.0, 0.5};
...
glEnable(GL_TEXTURE_GEN_S);
glEnable(GL_TEXTURE_GEN_T);
...
glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_OBJECT_LINEAR);
...
glTexGenfv(GL_S, GL_OBJECT_LINEAR, plane_s);
glTexGenfv(GL_T, GL_OBJECT_LINEAR, plane_t);

Texture Objects

To get a "handle" in which you can place a texture.

glGenTextures(1, &i);

To assign the current texture to handle i:

glBindTexture(target, i);

lecture #21 began here

Curves and Surfaces

Evaluators

For curves, this is done with glMap1f(entity, u0, u1, stride, order, data). A subsequent call to glEvalcoord1*() replaces calls to glVertex*(). Example:

glBegin(GL_LINE_STRIP);
   for(i=0;i<20;i++) glEvalCoord1f(u0 + i * (u1-u0)/ 20.0);
glEnd();

Evaluators can be used for curves, surfaces, normals, colors, and textures. For any of these to work, you have to enable them e.g. glEnable(GL_MAP1_VERTEX_33)

For equally spaced values of u (such as the 21 values above) there is special support via:

glMapGrid1f(21,u0,u1);
glEvalMesh1(GL_LINE, 0, 20);

2D Evaluators

Interactive Curve Example

Other Curves

There were a few class periods devoted to examples, in particular, there were texture and lighting examples. We grabbed a chainmail texture off a random image in a random website, converted it into a PPM and read the PPM and used it in an OpenGL program. And we looked at the "lighting lab" example, which also demonstrated several materials. We looked at a student example which moved the camera point (eye position) and played with orthographic versus perspective projection. lecture #2X+1 began here

Program Visualization

The big problem which PV addresses, compared with textual techniques, is the Volume Problem. You can capture most any aspect of program behavior textually, but the resulting log files easily grow to megabytes and beyond, for all but the smallest toy programs.

In addition to using graphics to deal with volume, PV tools must also solve two other hard problems: intrusion (observing some behavior modifies it), and access to program behavior.

Kinds of Program Visualization

• Algorithm animation
• Data visualization
  • Data structure visualization
  • Heap and stack visualization; variable usage patterns
  • Database visualization, file system visualization, etc.
• Machine/hardware visualization

Biggest needs

• Legible - if user can't interpret it its useless. Graphic design helps. Using familiar metaphors helps. Tieing results back to program source code helps.
• Scalable - handling volumes of data requires 1 or more strategies such as navigation through large data spaces, fisheye views, use of logarithmic scales...
• Automated - PV tools that know and look for common problems, and can be used without substantial manual investment on each application

What does program visualization build on?

Maps (5000+ years)

Statistical graphs (350 years)

The early work in this area relies on analogies to the physical world.

Data graphics (200 years)

More abstract, relational views of data (scatterplot, bar chart, pie chart, etc.)

Visualization (20 years)

Scientific visualization, modern computer graphics. Low resolution and small screenspace. Animation, color, and sound.

Principles of Graphic Excellence