CS 324: Computer Graphics Lecture Notes

tangibleassistantSoftware and s/w Development

Dec 3, 2013 (3 years and 4 months ago)


CS 324: 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

Lecture 22

Lecture 23

Lecture 24

Lecture 25

Lecture 26

Lecture 27

Lecture 28

Lecture 29

Lecture 30

Lecture 31

Lecture 32

Lecture 33

Lecture 34

Lecture 35

Lecture 36

lecture #1 began here

Pick up your supplemental text...

Please stop by JEB B26 to pickup your copy of the supplemental text.

Graphics is not just rendering

Computer graphics is a broad area of computer science, incorporating elements of:

graphic design

ray tracing and rendering

mathematical models of place
s and entities within them

graphics hardware, libraries, and window systems API's

user interfaces and graphical input


It would be stoopid for Dr. J to summarize the development of the entire field of computer
graphics in one bullet list, so her
e goes:

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 in the 1960's 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 modern interactive graphics was invented at Xerox PARC in the 1970's,
especially bitmapped raster graphics, "windows", etc. Englebart invents mouse at
Stanford. Graphics bought on $30,000
200,000+ workstations by mil
industrial complex
giants and t
op architects/designers.

1980's were full of hot graphics developments:


Early PC's were monochrome and had no graphics capabilities. 12" is a common
screen size.


Competing lower
end machines offered easy color graphics (Radio Shack, Apple,
, Atari, ...). 256x192 is a common screen size.


PC graphics becomes common on Hercules, EGA, and VGA graphics, and an
idyllic open system for developers spawns hundreds of small startups, many of
which produce spectacular new kinds of software and turn
young software
engineers fresh out of school into millionaires.


MIT introduces multi
platform portable graphics (X Window System). It was
kinda slow at first.


Microsoft and Apple majorly fail to adopt X, slowing progress of entire industry
several years
. X gets better slowly. A German undergraduate produces the first
"good" PC X server (UNIX/Linux).


Apple Macintosh was retro (tiny screen, monochrome) but successfully
popularized Xerox
style WIMP interface and the mouse input device.


Microsoft's Window
s seems to painfully imitate Mac.
Lawsuits ensue


Programmer documentation for Mac, Windows, and X11 all seem eerily derived
(at least in part) from some common Xerox ancestor (In fa
ct, Xerox did license
some UI features to Apple and Microsoft).


API's for graphics programming go from easy (Coco) to nightmarish. Partly the
new hardware capabilities challenge API designers, partly monopolies
deliberately act to extend their hegemonies.

Learning to program a Mac or
Windows box is a 6
12 month task.


Microsoft makes Windows programming difficult enough to wipe out its
competition in every app market it chooses to enter. "Undocumented Windows"
books explain what microsoft apps do that othe
rs can't. From now on, the main
way to become a young millionaire is to go work for Microsoft; BillG gets a piece
of all those young millionaires' action.


Silicon Graphics corporation becomes a market leader in 3D workstations, with
particularly fine soft
ware. Big digital divide between haves and have

1990's were even fuller of hot graphics developments:


20" CRT becomes a popular $1000 option. 1024x768 is a good resolution; up to
1600x1200 is fairly common.


DOOM proves huge market for 3D immersive

(desktop VR) graphics.


Graphics hardware "accelerators" implement 2D and then 3D graphics in
hardware. A $200 add
on allows a PC's to do what $200,000 workstations did a
few years previous.


OpenGL becomes the first widely adopted 3D standard API. Micr
osoft pledges
eternal allegiance in order to kill the workstation industry, especially market
leaders SGI and Sun.


Java capitalizes on need for portable graphics

2008 are simply screaming:


3D Graphics chips (GPU's) outpace CPU's in rate of prog


Big video memories, "true color" displays are ubiquitous.


Researchers work on how to use GPU's to speedup general
purpose computation.


Fixed pipeline model gives way to programmable shader model and shading


Motion picture industry switches all animation to computers; CG achieves lifelike
detail in non
time on giant server farms


Videogame industry chases behind with very detailed, real
time on a single PC.


24" LCD becomes a popular $500 option.


e monitors, and resolutions > 1600x1200 become common.


Microsoft quietly tries to derail OpenGL and own the standard (D3D, DirectX)


Two vendors dominate hardware (NVIDIA and ATI). NVIDIA embraces Linux
and OpenGL. ATI is eaten by AMD.


4x3 aspect ratio
gives way to 16x9 aspect ratio, spurred by HDTV

lecture #2 began here

When you read chapter #1...

Be sure to pay good attention to section 1.3.

Rationale for the


Section 2.1.3 of your book gives an INCOMPLETE "hello world"
style program for getting a
basic drawing canvas working using OpenGL and the evil "glut". As written (incomplete) it is 14
long, ugly lines of glut calls, with no opengl. It is missing the #incl
udes and four functions you
must write. By the way, OpenGL does not include support for fonts, so "hello, world" will take a
bit more effort than you think.

My past experience with glut has been poor. Also, it is not really part of OpenGL

orms that provide OpenGL do not provide glut. They all provide "gl" and "glu", the OpenGL
utilities library. So the text uses glut and we will use UIGUI ("oowee gooey", standing for "UI
GUI"). It is fine if you want to learn GLUT as well; go right ahead. W

be learning a lot of
"gl" and "glu" in a few weeks.



// #includes

void main(ing arc, char **argv)






glutCreateWindow("my first attempt");






#include "uigui.h"

int main()




writes("Hello, world");



Homework #1

Note that it is due a week from today.

Graphics Hardware

Graphics hardware has been developing at a very rapid pace, perhaps faster than Moore's Law.
This did not come about due to the civilian population benefitting from the research dollars spent
by our military. The driving application domain: computer games.

Without games, graphics on
PC's would still be primeval. If you are not a gamer, please put up with gamer references in this
class; if you use or profit from computer graphics, you owe the game industry at this point.

Frame Buffers

Bitmapped raster graphics is founded on the notion of some big hunk of physical memory being
mapped directly to pixels. It is common to use 1,4,8,15,16,24, or 32 bits per pixel. Writing
directly to memory is fast. Coding tends to be a mess of bitwise opera

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 fr
ame buffer yourself makes less and less

Graphics API's

Vendor specific API's have tended to be complex (400
800 functions, 50
100 complex structure
types). Portable graphics API's were slow and not widely accepted, more or less until the
I was developed. Reputable sources have claimed 3
6 months' training are required
to achieve reasonable mastery of a major API.

Implementing DrawPixel(w,x,y)

In this course we consider not just the application programmer's point of view, but the graphics

package implementor's point of view. Many of the fundamental algorithms implemented within
existing graphics packages are presented to enhance your understanding and use of these

Homework #0 postulated the use of a primitive for setting an indi
vidual 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
. Implementation for real hardware would
vary depending e.g. on whether the processor was "big
endian" or "little
endian", whether a 1
means black or means whit
e, 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 bi
t 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;


Note that memory is cheap and writing 32
bits at a time has compelling advantages, so many
frame buffers are organized as 32
bits per pixel instead of 24, even though they only offer 24 bits
of colo
r. Some use the extra 8 bits, others ignore them.

lecture #3 began here

Happy Labor Day

Try to remember not to come to class this coming Monday. See you next Wednesday. Hint: do
not put off your homeworks until the night before they are due!

UIGUI stat

No one has complained yet, but I won't believe that this library will work for Anyone But Me
until I start hearing reports. Do not wait for classtime, send me e
mail with positive or negative
experiences. Today's update: Win32 and Linux 64
bit librarie
s now available; demo of same.

Line Drawing

OK, so we can draw pixels. How do we get from there to more complex graphic objects, such as
lines, rectangles, etc.? We need algorithms. 15 years ago graphics packages implemented these
algorithms in software
the same way you and I would, but nowadays most graphics hardware
implements many graphics algorithms directly. Pseudocode here switches to Icon as a way of
passively introducing the notation. It is inconvenient to postulate a window, and we are

we are writing to the framebuffer, so let us say that the window is a global (default)

Draws a horizontal line from (x1, y) to (x2, y):

while loop



x := x1

while x <= x2 do {


x := x + 1


every x :=
x1 to x2 do {



every DrawPoint(x1 to x2, y)

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


y := real(y1)

every x := x1 to x2 do {

DrawPoint(x, integer(y + 0.5)) # round off

y +:= m



Midpoint algorithm (Bresenham, Pitteway, Van Aken)

Another important line algorithm was d
eveloped 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 instr

procedure DrawLine1(x1,y1,x2,y2)

dx := x2


dy := y2


d := 2 * dy


incrE := 2 * dy

incrNE := 2 * (dy


x := x1

y := y1


while x < x2 do {

if d <= 0 th
en {

d +:= incrE

x +:= 1


else {

d +:= incrNE

x +:= 1

y +:= 1





Midpoint Line Algorithm Example

The best way to get a feel for Bresenham/Midpoint in action is to see it. Here are the
incrE and incrNE, and the value of x, y, and d for the line segment from (50,50) to

incrE 6 incrNE

x 50 y 50 d

x 51 y 50 d 2

x 52 y 51 d

x 53 y 51 d


x 54 y 51 d 0

x 55 y 51 d 6

x 56 y 52 d

x 57 y 52 d

x 58 y 52 d 4

x 59 y 53 d

x 60 y 53 d

API parameters and graphic contexts

From skimming our text you should notice that a host of attributes (line width and style,
color, etc) are applied in any given graphic output command. Some API's use separate
parameters for each such "dimension", leading to very large parameter lists. In t
he design
of the X Window System, this was avoided in order to reduce network traffic. Instead,
resources for drawing attributes are preallocated on the display server in a large data
structure called a graphics context. The X graphics context is not entir
ely complete (e.g.
it doesn't include fonts) and other API's subdivide the graphics context further into
specific abstractions such as "pen" and "brush".

Color Indices and Colormaps

So far we have mainly considered monochrome and "true color" frame buffe
rs. 15

bits per pixel color displays are available that closely approximate "true color" in
behavior. You should learn of at least one very different method of organizing a frame
buffer, commonly used for 4

and 8
bits per pixel color displays. Ins
tead of literally
representing intensity of color, the frame buffer bits on these displays are often used as
subscripts into an array (called a colormap) whose elements are color intensities. The
"array" may be hardwired to a specific set of colors, or mod
ifiable. If it is modifiable, the
colormap provides a level of indirection that enables clever (and non
portable) tricks to
be played, where modifying a single array element instantaneously changes the color for
many (possibly hundreds of thousands) pixels

Circle Drawing

Circles obey the an equation such as x

+ y

= R
. If you can draw a good quarter circle,
you can draw the rest of the circle by symmetry. If you try to draw a quarter circle by
advancing x each step and solving the equation for y (y ==



) from the
earlier equation. But besides being slow, for part of the circle pixels will not touch
because the slope is too steep, similar to the problem we saw drawing very "steep" lines
looping on the x coordinate.

To avoid the discontinui
ty 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 == +



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

procedure DrawCircle0(x,y,R)

every angle := 0.0 t
o 2 * &pi by 1.0 / R do {

px := x + sin(angle) * R

py := y + cos(angle) * R




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 wil
l see.

procedure CirclePoints(x0, y0, x, y)

DrawPoint(x0 + x, y0 + y)

DrawPoint(x0 + y, y0 + x)

DrawPoint(x0 + y, y0


DrawPoint(x0 + x, y0



x, y0



y, y0



y, y0 + x)


x, y0 + y)


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

procedure DrawCircle1(x0,y0,R)

x := 0

y := R

d := 5.0 / 4.0


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

:= 1


x +:= 1

CirclePoints(x0, y0, x, y)



lecture #4 began here

rk #1

and Check Out
HW #2

Restating the Homework Platforms

For doing graphics homeworks, your options are:

1. download and install the necessary graphics libraries and header files to a local

To run locally, you will have to download an appropriate libuigui.a and uigui.h in order
for your C programs to compile. In fact, you will have to do this a few
times this semester
(as libuigui gets "fleshed out". In order to use icon/unicon you would similarly need to
download and install unicon from unicon.org, but that is not required for CS 324.

2. ssh into a CS machine.

For this option, the recommended mach
ine is wormulon.cs.uidaho.edu. The ssh must be
told to support X11 graphics connections. The command to do this is "ssh
X" from
Linux. From Windows the correct command to do X window forwarding depends on
which ssh client you use, but on the one from ssh.
com you would go into the Edit menu,
choose the Settings dialog, click open the Profile Settings, Connection, and Tunneling
tabs, and click the "Tunnel X11 connections" checkbox. From what I have seen, this
option works reasonably well for students at pres
ent, and allows me to update libraries
without you having to download them again. But once we get to assignments where
performance matters, being able to run locally will become a big advantage.

Clarifications on Bresenham/Midpoint Algorithms from Last Le

See the book, pages 467
472 for another explanation of Bresenham's algorithm.

See the
wikipedia article on Bresenham's circle algorithm

for a better description of that
algorithm, using integer
only operations. An example program

is worth playing

Raster Operations

Our hardware lesson for today is ye
t another nuance of frame buffer manipulation.
Consider the frame buffer as an array of bits in memory. When you are "drawing" on the
frame buffer, you are writing some new bits out to that memory. You have the option of
just replacing and discarding what
used to be there, but there are other possibilities that

the new value with the old. Each bit of the current contents could be
combined using AND, OR, and NOT with corresponding bits being output. These
different boolean combinations of c
urrent frame buffer with new output pixel values are
called 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 eas
"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
e 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 monoc
hrome displays.

Major Concepts from Hill/Kelley Chapter 2

Note: chapter 2 contains a bunch of introduction to OpenGL, covering various functions,
mainly from the gl and glut libraries. In some sense it is profoundly overcomplicated.
Absorb what you can,
and ask what you want, while we use our much simpler library for

absolute vs. relative coordinates

compare DrawPoint(x1,y1,x2,y3) with DrawTo(xNew, yNew), where xOld and yOld are
an implicit "current drawing position".

window coordinates vs. scr
een coordinates

pixel coordinates are generally relative to a current window...

normalized coordinates

going from (0.0,0.0) to (1.0,1.0) gives device independence

aspect ratio

width/height matters. For example drawings in normalized coordinates may lo
ok funny if
computed with different aspect ratio than displayed.

driven programming

give up on your ownership of control flow, for most of the semester, you write function
bodies that get called when the graphics system feels like it. In UIGUI this

is "optional"
but in OpenGL and most GUI class libraries it is mandatory. Creates problems for
novices (need to "think backwards"; can't use program counter to remember where you
are any more). Remember where you are by using a state machine (state variab
le(s)). For
your functions to get called by the graphics system, you have to tell the system about
them (register).

lecture #5 began here

Here's the

Check it out; it provides some useful information on our current labs.

An Overview of UIGUI's Graphics Primitives

Note: uigui.h and libuigui.a were updated last night for all platforms to add the
DrawLine() primitive. More to come!

Icon/Unicon 2D facili
ties consist of around 45 functions in total. There is one new data
type (Window) which has around 30
, manipulated using strings. Most graphics
API's introduce a few hundred functions and several dozens of new typedefs and struct
types that you
must memorize. UIGUI will eventually have around 90 if each of the 45
requires two C versions.

These facilities are mainly described in Chapters 3 and 4 of the Icon Graphics Book. Here
are some of my favorite functions you should start with. The main differences between
Icon/Unicon and UIGUI: the C functions are not able to take an optional initial
parameter, and do not yet support multiple primitives with a single call. This is less
useful in C than in Icon anyhow, since C does not have an "apply" operator. An initial
"working set" of UIGUI primitives will consist of just under half of the whole 2D

WOpen(), WClose()

Open and close the default window. Stickiness around the issue of initial attributes.

WAttrib(), Fg(), Bg()

Get/set an attribute. Fg() and Bg() are common special cases

DrawPoint(), DrawLine()

We have seen these by now.


8 functions for other common 2D primitives. In Icon; forthcoming in UIGUI. Built
ins in
underlying Xlib/Win32/hardware.


A smooth curve algorithm with nice properties. In Icon; forthcoming in UIGUI.
nted in software.


read a keyboard OR mouse event. In another lecture or two we will get around to
discussing the extra information available about an event beyond its return value "code".
Especially: mouse location.


Read the contents of

a screen pixel (in Icon: a rectangular region). In Icon; forthcoming

Region Filling

Suppose you want to fill in a circle or rectangle you've just drawn using one of the last
few algorithms we've discussed? Starting from a point inside the obje
ct to be filled, one
can examine pixels, and set all of them to a new color until one hits the border color of
the object.

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

# for interior
defined regions. old must not == new

procedure floodfill_4(x,y,old,new)

if Pixel(x,y,1,1) === old then {








For the example we started with (filling in one of our circles) only slightly more is

# for boundary
defined regions. the new color may be == to the

procedure boundaryfill_4(x, y, boundary, new)

p := Pixel(x,y,1,1) # read pixel

if p ~== boundary & p ~== new then {








The main limitation of these brute
force approaches is that the recursion is deep, slow,
and heavily redundant. One

way to do better is to fill all adjacent pixels along one
dimension with a loop, and recurse only on the other dimension.

More reading the frame buffer with Pixel()

If you try one of the fill algorithms above, they do genuinely recurse crazily enough to
get stack overflows. Another reason they are sooo slow is because of the X11 window
system architecture, which does not support reading the frame buffer as efficiently

writing to it; in particular, to ask for the contents of a window in general you must send a
network message and wait for a reply.

Pixel(x,y,w,h) asks for all the pixels in a rectangular region with a single network
transaction, which will be must fas
ter than reading each pixel individually. In general,
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
de) 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.

lecture #6 began here

Where we are at in t
he Course

I've given you reading assignments in chapter 2, but about half of that chapter is gross,
level OpenGL details that I want to you to skim over, and half are important and
useful ideas and principles I want you to "get". This week we will plo
w on into Chapter


Q: What is the default window size under UIGUI?

A: 80 columns, 12 rows, in the system default "fixed" font.

Q: function watt() doesn't work, what up?

A: watt() supported most context attributes out of the box, but needed some
more code to
catch canvas attributes such as size=. Code has been added; new library build will come

Parameterizing Figures

Textbook example 2.3.3 illustrates an important concept, which is to code generic
graphics and the apply them in different

situations using different parameters to modify
details. A 5
vertex house shape with a 4
vertex chimney are "parameterized" with a
translation (peak.x,peak.y) and a scale (given as a width and height). This is a precursor
of things to come (transformation
s, Hill chapter 5). If you push this "add flexibility to my
graphics code" theme farther you end up with "write generic code that reads all the data
from a file", another theme that Hill promotes. Anyhow, let's do a house shape using
normalized coordinates

and apply translation and scaling, as an exercise.

Convex Polygons

While we're discussing region filling, I mentioned that the 3D facilities (in OpenGL)
support FillPolygon, but the polygons must be convex. See your Hill textbook, page 69
for a discussi
on of this and a definition of convex polygons. We'll come back to the topic
in the 2nd half of the course.

Golden Rectangle

The Hill text page 86
87 has a discussion of the "golden rectangle". Following the golden
ratio, 1.618033989... Note that the HDT
V aspect ratio of 16:9 is closer to the golden ratio
than the old 4:3 aspect ratio, but it sure is wider/skinnier than the real thing.

Faster Fills

To speedup the fill algorithm, one can


Eliminate recursion, replace it with list operations and loops


Reduce the number of redundant checks on each pixel


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 {


put(L, x, y

put(L, x, y+1)

put(L, x
1, y)

put(L, x+1, y)




Backing Store and Expose Events

Using UIGUI we operate under the illusion that each on
screen canvas is a chunk of the
frame buffer that we control as long as our program requires it. In reality, window
systems are sharing and coordinating use of the frame buffer much as operating system
schedule the CPU. In particular, moving, resizing, overlapping, minimizing and
maximizing windows all point out the fact that an application doesn't have exclusive or
continuous access to the frame buffer.

Under these various circumstances, window syste
ms 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. Som
e 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 a
re 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
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 violatin
g someone's patent whenever we use, for example, the X Window

Contexts and Cloning

Last lecture we introduced (via whiteboard) the concepts of graphics contexts, and
cloning the context. This is an expanded treatment of that. With certain limits,

you can
have multiple contexts associated with a canvas, or can use a context on multiple
canvases. Clone(w) creates an additional context on window w. Attributes in a context

colors: fg, bg, reverse, drawop, gamma

text: font, fheight, ...

wing: fillstyle, linestyle, linewidth, pattern

clipping: clipx, clipy, clipw, cliph

translation: dx, dy

In contrast, canvas attributes:

window: label, image, canvas, pos, posx, posy

size: resize, size, height, width, rows, columns

icon: iconpos, icon
label, iconimage

text: echo, cursor, x, y, row, col

pointer: pointer, pointerx, pointery, pointerrow, pointercol

screen: display, depth, displayheight, displaywidth

lecture #7 began here


Class canceled; homework due date extended

Offhand, it looks like I will be unable to teach on Wednesday 9/10. HW#2 is due Friday.

MW next week you have guest lectures

My excellent doctoral student Jafar will tell you a bit about our graphics
related research.
He is a more bona
fide OpenGL guru t
han I, so check out his cool stuff.

lecture #8 began here

Check Out HW#3

"World Window" and "Viewport"

These Hill Ch. 3 concepts are important. The world window specifies what portion of a
scene is to be rendered. Things outside the world window must be

removed at some point
from the calculations of what to draw. The viewport defines where on the physical
display this world window is to appear. Rectangles are usually used for both of these, and
if their aspect ratios do not match, interesting stretching
may occur.

"World coordinates" are coordinates defined using application domain units. Graphics
application writers usually find it far easier to write their programs using world
coordinates. Within the "world", the graphics application presents one or mo
re rectangle
views, denoted "world
coordinate windows", that thanks to translation, scaling, and
rotation, might show the entire world, or might focus on a very tiny area in great detail.

A second set of transformations is applied to the graphics primitiv
es 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 worl
d coordinates and the physical coordinates do not have the same height
aspect ratio, the window
viewport transformation distorts the image. Avoiding
distortion requires either that the "world
coordinate window" rectangles match the
viewport rectan
gles' shapes, or that part of the viewport pixels go unused and the image is


"xlsfonts" reports 5315 fonts on the Linux system in my office. Windows systems vary
even more than X11 systems, since applications often install their own 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
bit ide
ntical, 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 use
ful, 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

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")




procedure setline(x,y,L,spacing)

while word := pop(L) do {


x +:= TextWidth(s) + spacing



Smooth Curves

DrawCurve(x1,y1,...,xN,yN) draws a smooth curve. If firs
t and last points are the same,
the curve is closed and is smooth around this boundary point. The algorithm used in
UIGUI comes from [Barry/Goldman 88] in the SIGGRAPH 88 conference proceedings.
Let's see how much we can derive from principles.

How do you draw smooth curves? You can approximate them with "polylines" and if you
make the segments small enough, you will have the desired smoothness property. But
how do you calculate the polylines for a smooth curve?

brute force

You can just represe
nt 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

cit 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; comp
lex curves are sewn together from simpler ones;
usually cubic polynomials are sufficient for 3D.

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.


In the real world, a spline is a metal strip that can be bent into various shapes by pulling
specific points on the strip in some direction with some amount of force. The
mathematical equivalent is a continuous cubic polynomial that passes through a set
control points. There are lots of different splines with interesting mathematics behind
them. Catmull
Rom splines are one popular family of splines, with the property that the
slopes as the curve passes through each point will be parallel to the surroun
ding points
(Figure 11.32). Icon's DrawCurve() function uses the Catmull
Rom splines, specifically
the algorithm cited in CG as [BARR88b]: Barry, Phillip J., and Goldman, Ronald N.
(1988). A Recursive Evaluation Algorithm for a class of Catmull
Rom Splines
SIGGRAPH'88 conference, published in Computer Graphics 22(4), 199

Smooth Curves

an algorithm

You stitch together the whole curve by doing one chunk at a time; that is, each outer step
of the algorithm draws the spline between two adjacent points

of the supplied vertices.
Within that outer step, there are guts to setup the matrices for this spline segment, and a
loop to plot the points.

Since we are drawing a smooth curve piecewise, to do the curve segment between p


you need four points actually; you need the points p

and p

in order to do the job.
The algorithm will step through the i's starting with i=4 (3 if you were C language going
0..3 as your first 4 points), and counting i that way as the point


two points whose
segment we are drawing, the steps will actually render the curve between p

and p

The data type used in the Icon implementation is a record Point with fields x and y.
Under X11 you could use XPoint and under MS Windows, POINT would

denote the
same thing (duh).

record Point(x,y)

There are interesting questions at the endpoints! The algorithm always needs some p

and p

so at the endpoints one must supply them somehow. Icon, Unicon, and UIGUI
use the following rule:

if p

== p


add p

before p

and p

after p


duplicate p

and p

at their respective ends.

Consequently, I have added this to the front of the gencurve() procedure for the lecture

# generate a smooth curve between a list of points

dure gencurve(p)

if (p[1].x == p[
1].x) & (p[1].y == p[
1].y) then { # close

push(p, copy(p[

put(p, copy(p[2]))


else { # replicate




Now to draw every segment between p

and p
. This is a "for" loop:

every i := 4 to *p do {

Build the coefficients ax, ay, bx and b_y, using: (note: b_y not "by", because by is an
Icon reserved word). This part is "magic": you have to lookup M

and G

in the journal
article yourself.

_ _ _ _

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 _|

Given the magic, it is clear how the ax/ay/bx/b_y are calculated:

ax :=

3].x + 3 * p[i

3 * p[i
1].x + p[i].x

ay :=

3].y + 3 * p[i

3 * p[i
1].y + p[i].y

bx :=

2 * p[i

5 * p[i
2].x + 4 * p[i


b_y := 2 * p[i

5 * p[i
2].y + 4 * p[i


Calculate the forward differences for the (parametric) function using parametric intervals.
These used to be intervals of size 0.1 along the total curve; that wasn't smooth enough for
large curves, so they were expanded to max(x or y axis difference). This

is a Bug! It is
not always big enough! What is the correct number to use??

steps := max(abs(p[i

2].x), abs(p[i

+ 10

stepsize := 1.0 / steps

stepsize2 := stepsize * stepsize

stepsize3 := stepsize * step

thepoints := [ ]

From here on out as far as Dr. J is concerned this is basic calculus and can be understood
by analogy to physics. dx/dy are velocities, d2x/d2y are accelerations, and d3x/d3y are
the changes in those accelerations... The 0.5's
and the applications of cubes and squares
are from the "magic matrix"...

x := p[i

y := p[i

put(thepoints, x, y)

dx := (stepsize3*0.5)*ax + (stepsize2*0.5)*bx +


dy := (stepsize3
*0.5)*ay + (stepsize2*0.5)*b_y +


d2x := (stepsize3*3) * ax + stepsize2 * bx

d2y := (stepsize3*3) * ay + stepsize2 * b_y

d3x := (stepsize3*3) * ax

d3y := (stepsize3*3) * ay

The "inner for loop" calculates the points for drawing (this piece of) the curve, broken
into steps.

every 1 to steps do {

x +:= dx

y +:= dy

dx +:= d2x

dy +:= d2y

d2x +:= d3x

d2y +:= d3y

put(thepoints, x, y)


DrawLine i
s used instead of DrawPoints in order to avoid holes and get working
linwidth/linestyle, but this turns out to be a mixed bag...

DrawLine ! thepoints



Smooth Curves

a slight embarassment

The following figures depict the behavior of the

smooth curves algorithm on the curve
through points. In each figure the top picture is the algorithm as given, and the bottom is
the built
in drawcurve, which is (should be) doing the same algorithm in C.

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:

Ways to fix: make the stepsize smaller? Change
from DrawLine to DrawPoint as
DrawCurve's underlying primitive? Using lines instead of points was perhaps done in the
first place to avoid gaps in drawn output, but some API's (X11?) exclude the endpoints of
lines being drawn... However, DrawLine is potent
ially nicer than DrawPoint from the
standpoint that it will use the "linewidth" (handy) and "linestyle".

drawCurve() C implementation

This code is where the Icon code above came from, except for the begin
point and end
point duplication shown above and n
ot given here.


* genCurve

draw a smooth curve through a set of points.

* Algorithm from Barry, Phillip J., and Goldman, Ronald N. (1988).

* A Recursive Evaluation Algorithm for a class of Catmull

* Computer Graphics 22(4), 199


void genCurve(w, p, n, helper)

wbp w;

XPoint *p;

int n;

void (*helper)

(wbp, XPoint [], int);


int i, j, steps;

float ax, ay, bx, by, stepsize, stepsize2, stepsize3;

float x, dx, d2x, d3x, y, dy,
d2y, d3y;

XPoint *thepoints = NULL;

long npoints = 0;

for (i = 3; i < n; i++) {


* build the coefficients ax, ay, bx and by, 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


ay = p[i].y

3 * p[i
1].y + 3 * p[i


bx = 2 * p[i

5 * p[i
2].x + 4 * p[i


by = 2 * p[i

5 * p[i
2].y + 4 * p[i



* calculate the forward differences for the function using

* intervals of size 0.1


#ifndef abs

#define abs(x) ((x)<0?


#ifndef max

#define max(x,y) ((x>y)?x:y)


steps = max(abs(p[i

2].x), abs

2].y)) +

if (steps+4 > npoints) {

if (thepoints != NULL) free(thepoints);

thepoints = (XPoint *)malloc((steps+4) * sizeof(XPoint));

npoints = steps+4;


stepsize = 1.0/steps;

stepsize2 = stepsize * stepsize;

stepsize3 = stepsize * stepsize2;

x = thepoints[0].x = p[i

y = thepoints[0].y = p[i

dx = (stepsize3*0.5)*ax + (stepsize2*0.5)*bx +

dy = (s
tepsize3*0.5)*ay + (stepsize2*0.5)*by +

d2x = (stepsize3*3) * ax + stepsize2 * bx;

d2y = (stepsize3*3) * ay + stepsize2 * by;

d3x = (stepsize3*3) * ax;

d3y = (stepsize3*3) * ay;

/* calculat
e the points for drawing the curve */

for (j = 0; j < steps; j++) {

x = x + dx;

y = y + dy;

dx = dx + d2x;

dy = dy + d2y;

d2x = d2x + d3x;

d2y = d2y + d3y;

thepoints[j + 1].x = (int)x;

thepoints[j + 1].y = (int)y;


helper(w, thepoints, steps + 1);


if (thepoints != NULL) {


thepoints = NULL;



static void curveHelper(wbp w, XPoint *thepoints, int n)



* Could use drawpoints(w, thepoints,

* but that ignores the linewidth and linestyle attributes...

* Might make linestyle work a little better by "compressing"

* sections produced by genCurve into single drawline points.


drawlines(w, thepoints, n);



* draw a smooth curve through the array of points


void drawCurve(w, p, n)

wbp w;

XPoint *p;

int n;


genCurve(w, p, n, curveHelper);



Image manipulation involves three areas

file formats

window system native (in X11, server side)

side image manipulation

File formats are numerous; these are things like GIF, JPG, BMP, PNG. They vary
according to compression size, lossiness, and portability. Icon does GIF on all platforms,
plus whatever formats are built
in to the Window syste
m (e.g. BMP and XBM). GIF is
not very suitable due to patent encumbrances, and Icon really needs to add PNG and JPG

Window system native manipulation starts with off
screen invisible windows you can
draw on, and copy to visible windows from. A wi
ndow 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

lecture #10 (virtual lecture) began here

Lectures 9 and 10 were taught by Jafar. Any questions?
lecture #11 began here

Gamma Correction

The eye is more sensitive to ratios of intensity levels, rather than absolute values of
intensity. Intensity levels should be spaced logarithmically rather than linearly, to achieve
equal levels of brightness. Hill Section ??.? gives an overview of gamma c
without gamma correction your range of color values will not be spread out smoothly.
Some hardware has gamma correction built
in, and some operating systems (e.g. MacOS)
implement gamma correction uniformly at the system level. For the rest, you

may have
reasonable default behavior but it may be to your advantage to allow the user to modify
the default gamma correction value for their nonstandard CRT's.

Review of Vector & Matrix Math

Please help Dr. J re
learn some of his vector and matrix math

from Hill Chapter 4 and
sites such as




lecture #12 began here

Once again with
Catmull Rom

Check out the

ve we Talked about Pixel() and WAttrib() enough yet

Pixel() really returns a pointer to (an array of) unsigned char RGB triplets, WAttrib()
returns a char * also.

2D Geometrical Transformations

Please absorb Chapter 4 in detail, the 2D part for starters
. Don't you just love those
homogeneous coordinates! Dr. J's thoughts: you can do 2D scaling and rotation with 2x2
matrices, that is as simple as anything here is going to get. To toss translation into the
mix, you resort to those pesky homogeneous coordin
ates, i.e. 3x3 matrices and a clever
trick to allow 2D translation, scaling, and rotation all at once. Although these are 3x3,
their bottom row tends to be dull; I am not sure how many libraries exploit that.

For 3D we end up with 4x4 matrices, employing
the same tricks. For exams (midterm,
final, etc.) you will have to know your matrix transforms down cold! Should we do a
pencil and paper homework?

Remember: matrices compose nicely, but not all transforms are commutative. Plan ahead
for the old translate
origin, rotate, and translate
back trick.

Cornellian lecturenotes


lecture #13

began here

Read Chapter 5

We still need to hit one topic in Chapter 4, but we are obviously in Chapter 5 today.

Matrix Representations of 3D Coordinate Transformations

3D transformations can be represented by 4x4 matrices using homogeneous coordinates
(x, y, z, W), or (x/W, y/W, z/W, 1) for W != 0.

Translation is extended from the 2D case:

T(dx,dy,dz) =

















Scaling is similarly extended:

S(dx,dy,dz) =

















Rot at i on i s a l i t t l e more i nt erest i ng; t he rot at i on around t he ori gi n t hat we di d before now
becomes rot at i on around t he z
axi s wi t h t he fol l owi ng mat ri x:

Rz(θ) =

cos θ
sin θ
sin θ
cos θ

But t here are t wo more axes one mi ght want t o rot at e about:

Rx(θ) =






cos θ
sin θ
sin θ
cos θ

Ry(θ) =

cos θ
sin θ
sin θ
cos θ

Composition of 3D Transformations (Hill 5.2.5 )

As was the case for 2D, 3D translation, scaling, and rotation can be composed as much as
you want, and reduced via matrix multiplication to a single matrix to apply to all points
that need transforming. Typi
cal will be a translation to the origin, a scaling, and as many
rotations as are needed to orient the object in the right direction.

Change in Coordinate Systems

One way to view transformations is as a "coordinate system conversion" similar to

temperature from Fahrenheit to Celsius. To render a scene in world
coordinates you are changing world coordinates into "window" (logical) coordinates, and
then changing "window" coordinates into "viewport" (physical) coordinates. This same
approach, and t
he application of transformations to accomplish conversions, may be
extended into the application domain, allowing objects to express their coordinate
systems relative to whatever near neighbors are most logical, instead of expressing them
as absolute posi
tions relative to some world origin which is arbitrary.

All About Colors

This talk is based on material in [Foley/VanDam/Feiner/Hughes Chapter 13] and GB
Chapter 7. Hill Chapter 11 talks about color in some detail.

We have some basic introduction to col
or 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 m
ay 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.


Color is the perception of light, and the first coordinate that applies to all perception of
light is how much

light is seen: this is called intensity, luminance, lightness or brightness.
Intensity may range from 0 (black) through the grays up to infinity (white). Intensity
beyond a certain amount will cause blindness, so almost any upper bound of intensity that
s whiter than everything else might be considered white for a given view. Aside from
common binary systems (light vs. no light, a.k.a. monochrome), the question is: how
many different levels of brightness does the hardware support, and how many levels of
ntensity would be required for us to see it as a smooth continuum. One answer, from
Figures 13.1
13.6, is that 32 levels might be sufficient for practical purposes; Table 13.1
suggests that in real life the upper bound for most media are in the 400
500 int
range. If resolution is lower, more intensities may help, while higher resolution can
compensate somewhat for having fewer intensities. You can trade resolution for more
intensities using so
called half
toning and dithering techniques, especially
if you have
more resolution than you need, or are willing to stand viewers far away from what they
are looking at.

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 prec
isely 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 ne
eded in a given application.


For those viewers who are not color blind, the thing that determines perception of color is
the "dominant wavelength", ranging through the visible spectrum from the (ultra)violet
through the (infra)red. The term "hue" is
commonly used for this aspect of color. The
main thing for me to mention regarding hue is that although the spectrum occupies a
linear progression through wavelengths, humans do not perceive this linearity, if they
recognize a progression from violet to re
d it is learned artificially.


It is quite rare for you to perceive "pure" light, almost all colors you see are mixtures.
Mixtures of specific colors may be averaged out to an intermediate color as a "dominant
wavelength", but for any color you

see we can generically ask how much white random
light is mixed in with whatever dominant colors are to be seen. If the answer is: 0% white
light, we would say the color is 100% saturated. If the answer is: 100% white light, we
have fully unsaturated ligh
t which will be seen as a gray (or white, or black) based on
intensity. Saturated colors are very vivid, while the more unsaturated would be
considered "washed out" or "pale".

Additive and Subtractive Color Models

The traditional coordinates for colors in some disciplines are HSV for Hue, Saturation,
and Value (=Intensity). But the "Hue" coordinate is not very easy to work, so other color
models are common. For hardware where colors are formed by adding light togeth
er, the
dominant coordinates RGB, and the "color cube" makes sense.

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
ents 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

the dull gray you get from using all three CMY inks to produce "black" by regular

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 satura
tion 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 #14 began here.

UIGUI Mouse x,y

We can't say &x and &y in C, so

we say Mx and My.

Quick thought on event
driven coding in UIGUI

You must call a GUI
event reading function constantly, or suffer dire consequences.
During any longer computations, call pollevent().


Note: this lecture is a bit out of order, it should have been done earlier. In UIGUI,
Clip(x,y,wd,ht) clips all output to a specified rectangle in the window.

Hill Sections 3.3 and 4.7 talk about how clipping can be implemented. Let's see how
much we can
get from principles. The first clipping algorithm to do is: clipping lines.
Suppose we have to implement a function


that draws a line from x1,y1 to x2,y2, except skipping anything that is outside of
(x,y,wd,ht). How can
we write that procedure? Let's first dismiss some trivial cases. Can
we tell whether any clipping is needed at all? Yes, it is easy:

procedure DrawClipped(x1,y1,x2,y2,x,y,wd,ht)

if x <= x1 <= x+wd & x <= x2 <= x+wd &

y <= y1 <= y+ht & y <= y2 <=
y+ht then {

# draw the whole line, no clipping needed

return DrawLine(x1,y1,x2,y2)


# else some clipping is actually needed.


Now, how can we tell what clipping is needed? Here is Totally Easy Clipping:

if x1 < x & x2 <

x then return

if x1 > x+wd & x2 > x+wd then return

if y1 < y & y2 < y then return

if y1 > y+ht & y2 > y+ht then return

This narrows down the problem to: either one end needs to be clipped and the other
doesn't, or both ends need to be clipped. If

both ends need to be clipped, there are still
cases where the entire line is outside our drawing rectangle and needs to be clipped.

All of this up to now is totally obvious common sense, but it is also the start of the Cohen
Sutherland clipping algorithm
. It must be that what you do next is what makes Cohen
Sutherland interesting. Let's pretend that Dr. J hasn't read or doesn't remember Cohen
Sutherland even a bit. What options do I have?

Look for intersections between the (x1,y1) and the four line segme
nts of the

Divide line segment in half and apply clipping recursively

... other ideas?

Suppose we do the recursive thing:

procedure DrawClipped(x1,y1,x2,y2,x,y,wd,ht)

if x <= x1 <= x+wd & x <= x2 <= x+wd &

y <= y1 <= y+ht & y <= y2
<= y+ht then {

# draw the whole line, no clipping needed

return DrawLine(x1,y1,x2,y2)


# else some clipping is actually needed.

if x1 < x & x2 < x then return

if x1 > x+wd & x2 > x+wd then return

if y1 < y & y2 <

y then return

if y1 > y+ht & y2 > y+ht then return

# else: divide and conquer




Does it work? If you try this out, you will most likely get a
segmentation fault, because
we haven't adequately handled the base case (when is DrawClipped handling segments so
small that no recursion makes sense?). Cohen
Sutherland differs in that it isn't dividing in
half, but rather, looks to chop at the actual int
ersection points.

procedure clipSegment(x1,y1, x2,y2, x,y,wd,ht)

repeat {

p1_inside := (x <= x1 <= x+wd & y <= y1 <= y+ht) | &null

p2_inside := (x <= x2 <= x+wd & y <= y2 <= y+ht) | &null

p1_inside &
p2_inside then {

# draw the whole l
ine, no clipping needed

return DrawLine(x1,y1,x2,y2)


# else some clipping is actually needed.

if x1 < x & x2 < x then return

if x1 > x+wd & x2 > x+wd then return

if y1 < y & y2 < y then return

if y1 > y+ht & y2 >

y+ht then return

if /p1_inside then { # p1 not inside, fix p1

if x1 < x then { # p1 to the left, chop left edge


else if x1 > x+wd then { # p1 to the right, chop right edge


else if y1 < y then { # p1 above,

chop against top edge


else if y1 > y+ht then { # p1 below, chop against bottom edge



else { # p2 not inside, fix p2




class exercise: how to do the chopping?

If x1 < x, compute new x1,y1 inte
rsecting with x: slope m of segment is (y2
y1) / (x2
x1). New intersection point is (x, y1 + (x
x1) * m)

Check out my


There is a lot more to say about clip
ping, especially in 3D. We will revisit this topic as
time allows.

Introducing OpenGL

OpenGL is public, standard C language 3D graphics API based on an earlier, proprietary
standard developed by SGI. OpenGL is a state machine of sorts, that takes in requests for
graphics primitives, processes them through a rendering pipeline, and produces
2D pixel
images as output.

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.

In ord
er to compile OpenGL programs, you may have to install whatever packages are
needed for GL and GLU libraries and headers (libGL and libGLU in .so or .a forms, and
various <GL/*.h> files under some header directory such as /usr/include,
/usr/openwin/include, or whatever. You generally have to learn your
compiler's options for specifying where to look for these libraries (
L and

In addition to these headers and libraries for linking, which you normally specify in a
makefile, you may
need a LD_LIBRARY_PATH environment variable in order for the
system to find one or more of your shared libraries at program load time in order to run it.
Note that you may already have an LD_LIBRARY_PATH, and you should just add your
OpenGL (e.g. Mesa) dir
ectory to your existing path if you have one.

Compared with the earlier Icon/UIGUI 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 claims

to be simple and easy to use, but is
limited and restrictive in its capabilities. Last time I taught this course, students
complained bitterly about glut. Your options in this course are basically: glut or UIGUI


Most graphics API's are "ev
driven", meaning that an application is written as a set of
functions which are called by the window system in response to user input or when other
services are required. glut follows this model in a strong sense; callback functions are
"registered" wi
th glut, after which glut's main loop owns the control flow of your
program. Under glut(), you do not draw your graphics output in your main() procedure,
you draw it in a "display callback" function that is invoked whenever the window needs
to be redrawn.

UIGUI does this sort of stuff for you under the hood; if you use it, your graphics
primitives get saved in a data structure, and the UIGUI library registers its display
callback function to walk and redraw that data structure. But for everything to work,
have to read a GUI input function or call pollevent() more or less constantly.

Composing graphics primitives

OpenGL graphics primitives are generally composed using a series of functions
expressed by the pattern:

glBegin glVertex+ glEnd

The glBegin(
type_of_object) function specifies what primitive is being depicted, and the
glVertex family of functions allow any number of (x,y,z) coordinates in a variety of types
and dimensions. This lecture is presenting selected material from the OpenGL Primer,
pter 2.

lecture #15 began here

By the way... wormulon/eternium do not have glut?

At least, I do not see them, does anybody else? If not, this is part of what I was telling
you about. Ouch! I guess I had better ask Larry to put them up...

Looking at the
HW#3 "Solutions"

You are graded relative to your peers, but HW#3 results are pretty brutal so far. Let's take
a look.

A Bevy of OpenGL and GLUT Functions

In addition to the core graphics functions, there are a lot of helper functions in the
OpenGL API; we will present a few more details of these helper functions that you may
find useful.

int glutCreateWindow(char *title)

Regarding window creation with glu
tCreateWindow(), I need to emphasize the point that
you can create multiple windows, each call will return a separate integer "identifier". The

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.


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


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 g

Color in OpenGL

OpenGL supports "RGB" (true color) and "color index" (color map) modes; writing an
application that will run on either is a bit awkward, and color index display hardware is
vanishing, so it is reasonable to consider only the RGB color mode. Colors are spec
in real numbers between 0.0 and 1.0. Some displays (notably, current generation Macs)
support degrees of transparency for superimposing multiple images on screen, and use a
fourth color component (alpha) where 1.0 means the color is solid and 0.0 mea
ns the
color is invisible.

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 fr
actions 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
r(), 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, g
lColor*() 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

penGL allows you good control over what "window on the world coordinates" will be
visible in your scene. In the general case, you will be able to specify viewing from an
arbitrary (x,y,z) location, in an arbitary (x,y,z) direction, as well as how wide and
your field of view is. Section 2.8 mentions the 2D special case of this,
gluOrtho2D(x1,x2,y1,y2); if you ever use it, beware the surprising parameter order, and
note that OpenGL's world coordinates are based on classic cartesian coordinates, not the
ypical physical coordinates in which y grows going down.

lecture #16 began here

OpenGL Transformation Matrices

The translation, scaling, and rotation used in converting objects' world coordinates to
their on
screen pixel locations is done automatically b
y OpenGL. Two transformation
matrices are maintained by OpenGL (in global variables) and combined to perform
rendering: the model
view matrix and the projection matrix. The same set of functions
are used for manipulating both matrices, so you start by spec
ifying which matrix you are
working on, by calling glMatrixMode(GL_PROJECTION) (or GL_MODELVIEW).

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 mat
rix 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




Later on, we will see that you frequently compose these matrices, especially the model
view matrix, while drawing a complex scene. From one transformation corresponding to
a given "parent" coordinate system, if yo
u have several "child" coordinate systems whose
coordinates are relative to the parent, each child will need to save the parent
transformation, make changes and then draw their objects, and then restore the parent.
When object hierarchies are multiple leve
ls deep, a special type of stack is natural.
OpenGL provides a built
in stack mechanism, in which the "push" operation copies the
top stack element, to which the child may then apply transformations for their coordinate
system relative to the parent coordi
nates. glPushMatrix() and glPopMatrix() are used in
this way, and they operate on whichever current matrix you have specified using

More OpenGL Graphic Primitives


GL_POINTS are not usually very interesting in 3D graphics, but open
gl 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.


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 s
pecified, 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
ports 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
out 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 p
revious 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.