Graphics Programming with OpenGL

Course Notes #1

Notes for 1/9/96

Introduction.

Computer graphics is primarily a means of communication. We are expressive beings, and we can create some wonderful worlds within the realm of the computer. However, we need a visual form of communication between the computer and the user. Computer graphics is that form of communication. It provides a way to stimulate the human visual senses in such a way that it brings up a "window" on the virtual world. It provides a link between cyberspace and real space.

Graphics is not just about creating little 3-eyed aliens. ALL aspects of computer data storage, from scientific visualization, to 3D modeling, to statistical results can be expressed in a graphical sense. We need to transform data from the computer domain to the user domain. This transformation can easily be accomplished in the realm of computer graphics.

As graphics programmers, our job is to enhance that link to such a extent that the result looks near-realistic. We want to make this link work as well as possible, so that the user will have a clear, unconfused picture of what's going on with respect to the worlds we create.

OpenGL is a software interface for graphics hardware. It is primarily used for creating interactive 3-D applications. It reduces the amount of work a programmer needs to do -- instead of stressing over weeks about a function, the developer can simply call 2 or 3 OpenGL-specific commands. In fact, there are more than 120 OpenGL commands at the developer's disposal.

OpenGL is special in that it is designed for a client-server model. The OpenGL application can be running on one computer, and the OpenGL server can be running on another. The client will send OpenGL commands to the server to be executed remotely. For most of us, these two client and servers will run on the same machine. But keep in mind that there is a clear schism between the client side of things and the server side of things.

OpenGL is hardware-independent -- it provides a layer of abstraction above the graphics hardware. In this way, we can write OpenGL programs and be reasonably well-assured that it will run on any platform which supports OpenGL. Because OpenGL is optimized for every setup, one program that we write in OpenGL will harness the full power of whatever platform it is running on, whether a 80386 or a SGI Onyx supercomputer.

Even though OpenGL is relatively easy-to-use, it is also relatively low-level in program design. You can't tell OpenGL, "OK, create a chair for me." OpenGL deals best with basic, pure polygons. It's best at throwing polygons around and transforming them. That's what it does best. It's up to you, as the programmer, to harness this basic functionality and to get this basic platform to do what you want it to. If you're interested in higher-up things, you can start to look into things like Open Inventor, which is modeling-based, instead of polygon-based, or IRIS Performer, which is best at creating real-time simulations. Both of these packages run on top of OpenGL however, in much the same way that your applications that you write in this class will run on top of OpenGL.

Having said all that, why are we using OpenGL? The answer is that it provides a easy-to-use, relatively high-level (w.r.t. to the graphics hardware) interface for graphics operations. Things that students wrestle with for weeks in CS 174 can be done in 2-3 lines of code in OpenGL. Because of this added functionality and horsepower, we can create stunning programs. Plus, it looks good on your resume.

There are other alternatives to OpenGL -

3DR. This is a graphics API developed by Intel and can be obtained for free from them. It is optimized for Pentium platforms. However, it has a steep learning curve.
Reality Lab, by Microsoft. This API is very fast, but it has a large fee to obtain the libraries.
Others, like Direct3D and others, are still in development.

OpenGL is good for us because it is freely supported, is relatively easy to use, and very powerful. It delivers the best of all worlds to us.

Class Administration Issues.

The prerequisite for this class is a knowledge of C and/or C++. Some graphics exposure will help. The required book is the "OpenGL Programming Guide", as listed in the syllabus. Projects, quizzes, and the course outline (all of which is on the syllabus) were discussed.

Graphics Review

The main, common core concept of computer graphics is that of a transformation. A transformation performs an operation on a vertex so that it ends up somewhere else. There are three major forms of transformations:

Translation. This transformation takes a point and moves it somewhere else in space. Think of picking up a Coke can and sliding it somewhere else in space.
Scaling. This takes a point and scales it relative to the origin of a coordinate system. Think of taking a Coke can and making it bigger or smaller, relative to its center. (Wherever you choose the "relative" point is the center of the coordinate system the object is relative to.)
Rotation. This takes a point and rotates it around a given vector in space. This vector may or may not be one of the coordinate axes.

All transformations in computer graphics may be represented as a 4x4 matrix. This matrix, when multiplied by a 4-tuple vector, will result in another 4-tuple vector, which is the transformed vertex. (vertices can be represented as (x,y,z,w) where w is the homogeneous coordinate. For more information about homogeneous coordinates, see Appendix G in the book.)

By transforming points in space, we can make certain changes to a 3-D world, which will eventually lead to a 2-D representation of that 3-D world on our computer screen. We can do this by forming the concept of a frustum, which defines what a certain viewpoint can see. It consists of a truncated pyramid-like structure. We truncate it because we create near and far clipping planes, to cut out elements of the 3-D world which are either too far away to see, or too close in that it will block everything else.

This leads us to the main graphics pipeline. This is the sequence of steps a graphical system must follow to go from 3-D object to 2-D screen. These stages are:

Modeling coordinates. In this stage, the 3-D object is constructed relative to some coordinate system which is convenient for an object. (For a Coke can, it probably would be the center of the can).
World coordinates. We transform objects in modeling coordinates to some place in world coordinates. This is equivalent to "placing" an object in the 3-D world.
View coordinates. We now transform the entire 3-D world so that it is relative to some coordinate system convenient to our eyepoint. (Usually, this is where the x-y plane is parallel to our face and the z-coordinate defines where we look. We look down the negative z-coordinate - remember, we're using the right hand rule)
Normalized coordinates. We "squish" the entire frustum to a 1x1x1 box, to perform the perspective calculations and also for ease in clipping, etc. (Dealing with a 1x1x1 box is much simpler than a general, any-sized frustum)
Device coordinates. We strip out the z-coordinate (doing hidden surface removal, if required) and create a coordinate system where the x-y plane corresponds to our monitor. We may need to flip the coordinate system to obtain this stage (Windows, for example, measures x along the top edge and y downwards along the left edge)

By following these steps, we can create any 2-D projection of any 3-D scene from any viewpoint. We can add in neat features like clipping, depth focusing, fog, etc. relatively easily with this setup.

The OpenGL Pipeline

The internal pipeline that OpenGL uses to draw things is very similar to the pipeline discussed above. It takes in vertices, from you, the programmer. It performs transformations on these vertices, while performing lighting and coloring operations. It generates texture coordinates (advanced topic) and puts these vertices into polygonal objects. It does all necessary transformations and ends up with things called fragments, which just means a point on-screen and all its assocated information. It performs clipping, rasterization (which just means turning it into a stream of pixels), and finds a way to put it on-screen (using blending, overlaying, etc.).

Example OpenGL program.

Here's a simple program found in the textbook on page 6:

#include <whateverYouNeed.h>

main() {

OpenAWindowPlease();

glClearColor(0.0, 0.0, 0.0, 0.0);

glClear(GL_COLOR_BUFFER_BIT);

glColor3f(1.0, 1.0, 1.0);

glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);

glBegin(GL_POLYGON);

glVertex2f(-0.5, -0.5);

glVertex2f(-0.5, 0.5);

glVertex2f(0.5, 0.5);

glVertex2f(0.5, -0.5);

glEnd();

glFlush();

KeepTheWindowOnTheScreenForAWhile();

}

This program creates a white square on a black background. Obviously, the header file and the first and last lines of the program are pseudocode. I won't get into OpenGL syntax until week 2, but this is a quick introduction to a simple program. First, we set the clear color to black (using RGBA here, or Red-Green-Blue-Alpha. All colors can be formed from red, green, and blue. Alpha lets you specify translucency, which won't be covered until we go over blending.) Then, we clear the color buffer. (There are other buffers as well.) We set the drawing color to white (1, 1, 1 in RGB) and set up the display, and begin drawing a polygon. We dictate the four corners, end the drawing, and flush the internal buffers to screen. (Sometimes on a network, the drawing doesn't get flushed over the network immediately - glFlush() ensures this.) Voila!

Don't fret if this looks confusing - the whole course will be devoted to learning OpenGL, and you're not expected to learn it on day one.

Other features in OpenGL include evaluators, which lets you directly draw polynomal equations in 3D space, display lists, which are like mini-OpenGL programs, and animation, which supports double-buffering (which lets you draw off-screen and "flip" the drawing and viewing buffers. This avoids the evil "flickering" effect if you draw to screen, clear screen, draw to screen, etc.)

Where do we go from here?

Each week in this course we'll uncover new OpenGL commands. We won't cover all 120+ commands, but we'll cover a good chunk of them to let you learn the language. We'll traverse through the OpenGL pipeline at first, going from 2D to 3D quickly. You should be up and running writing 3D applications by week 3 or 4. After that, we'll cover realistic 3D graphics (lighting, shading) and later advanced features like evaluators will be covered. By the end of the course, you should have a heavy arsenal of high-performance graphics techniques to use in your programs.

See you all on week 2!

Jdd