Last time, we look at the instance transformation: translate, rotate and scale, to place on object in the scene. The following discussion is about more complex sequences and nested transformations.

Sequences of Transformations

How is the barn like a picket of a fence? They're certainly different in size, and of course a picket is tall and skinny, while a barn is relatively squat. But these are just scalings. In other words, other than a scale transformation, the barn is the same as a picket. So, we can make a picket fence by drawing the barn many times!

Notice the transformations in the 03-Fence.cc code. (There will be other aspects of the code that we haven't discussed yet, so don't worry about that: just look at the glTranslatef, glRotatef and glScalef calls. In this program, each section of fence is drawn by a series of translations of 5 units each, drawing one picket with each translation.

Notice where the glPushMatrix() and glPopMatrix() calls are. Recall that glPushMatrix() says "save the current coordinate system on a stack," and glPopMatrix() says "pop the stack and restore that coordinate system."

Oh, and notice the computation of the sky color. Division of integers in C is usually not what you want, so add the ".0"

Representing an Affine Transformation

How does OpenGL represent an affine transformation? When it's deep in one of those loops that draw a section of fence, is it remembering each transformation call, or is it somehow able to remember just the aggregate? It's the latter, but we need to do some work first to see why.

Because there's a fair amount of math, I wrote the next part of the reading in LaTeX, so please read the following PDF file:

affine math

Even though we won't typically be working directly with matrices in our programs, there are still good reasons to learn this math:

• If you don't understand the concepts behind the math, you won't understand the terminology that OpenGL uses (matrices? CTM? homogeneous coordinates?)
• Seeing how the major operations are defined as matrix multiplications is pretty cool.
• Homogeneous coordinates are a neat trick.

Strategy

The strategy for building an interesting object is to choose a coordinate system that is convenient for it.

• The convenient coordinate system for the cube had the origin at the center and the sides aligned with the major axes
• The convenient coordinate system for a GLUT cone has the point of the cone on the Z axis and the base in the Z=0 plane.
• The convenient coordinate system for the barn put the origin at the lower left corner, and the sides aligned with the major axes

A synomym for a coordinate system is a frame. Technically, a coordinate system is the directions that the x, y, and z axes point, and a frame is a coordinate system plus a location for the origin, but we will be less formal about it.

In OpenGL, we can use as many transformations as we want, and we can keep a stack of ``saved'' frames, up to 32 of them.

Another aspect of a frame for an object is to make it easy for others to use the object: the origin should be someplace convenient. For example, it might be convenient when building the teddy bear to put the origin in the center of the bear's belly, but that's an inconvenient location when you want to place the bear onto the bed. Then, it would be nicer to have the origin at a corner of the bounding box, say.

You should definitely think in terms of different coordinate systems when building complex objects. Each part of an object can have its own coordinate system, and you can combine the parts using more transformations.

The Teddy Bear

Note the use of affine transformations in the code for the Teddy Bear: 03-TeddyBear.cc. It's made just with spheres and cylinders. Spend some time looking at the construction bounding box for the Teddy Bear, because the mathematics is worth remembering and, more importantly, it's worth practicing visualizing these movements.

• There's a frame for the bear as a whole. Origin at the center of the belly; x towards its left arm, y up through the top of the head, z forward out the belly button.
• Notice that there are two consecutive rotations for the legs. Rotations are not commutative! (Neither is matrix multiplication, unlike scalar multiplication!)
• Could we do the leg positioning with a single rotation? We'll solve this later, but it's worth pondering now.
• A separate frame for the head.
• What do you think of the frame for the eyes? Would it be better to be more "modular"?
• The bounding box has strange dimensions. Should we make it easier? Why or why not?

The Mobile

Note the use of affine transformations in the code for the mobile: 04-Mobile.cc. Each part of the mobile is in its own frame, so the parts can be conveniently placed.

• What would be involved with swapping different parts of the mobile around?
• How does the coding strategy support this?

Display Lists

We know that the graphics card does the rendering for some vertices and then forgets about them. However, it can be made to "remember" them using display lists.

(The reasons for the name are historical; they are not lists in any usual sense. It comes from the fact that, back in olden times, the graphics system would be given a list of commands to draw a scene and it would continually "refresh" the picture by re-executing the commands.)

Why use them? Efficiency. They are cached partway down the pipeline, so using display lists saves a little work.

How to use them:

• Use glNewList() to notify OpenGL that you will create one, identified with an arbitrary but unique integer of your choice.
• Use the commands. These will not result in any rendering (yet)!
• Close the list with glEndList();
• Execute the list using glCallList(ID);

Note how we use a display list to draw a picket of the fence. Thus, drawing a picket is much more efficient than if we sent colors, transformations and vertices down the pipeline each time.

New Code

We have some other new functions as well.

• To set the color, you can define a twTriple (an array of three GLfloats: you can find the definition in tw.h. The last two arguments are ignored unless we're using material and lighting, which we'll do in a few weeks.

  twColor(twTriple,int,int);
  

• To draw the base of the bounding box (the one for the entire scene) in the current color, you can use the following function:

  twGround();
  

• To draw all the other walls of the bounding box (for the scene) in the current color, use the following. It makes the walls transparent from outside, so you can see the scene through the near wall, but the far wall is opaque and you see the sky color. It looks pretty cool.

  twSky();