A Middle-Out Approach to Teaching Computer Graphics with uisGL


Scott Grissom
Computer Science Department
University of Illinois at Springfield
Springfield, IL 62794
grissom@uis.edu

1.0 Introduction

Computer graphics students are expected to understand and write software that performs all three steps of the graphics pipeline: model building, transformations, and rendering (Foley et al. 1994). However, it can take all semester to develop rendering software from scratch in an introductory course. Only at the end of the semester will students have the satisfaction of seeing the fruits of their labor. A better solution is to have students create pictures from the first day while they investigate how the pictures are created during the rest of the semester.

One strategy is to provide software to students (Schweitzer and Northrop, 1991). Unfortunately, this approach does not require students to implement their own code. A better strategy is to provide software at the beginning of the semester and require students to develop their own software as well. This approach was taken by Clevenger et al. (1991) but their work was not adopted by many educators because it was developed in Ada. A similar approach using C was taken at The Ohio State University (Carlson, 1990). A limitation of the Ohio State software is that it does not take advantage of object-oriented programming. This is why some students find the data structure to be overwhelming to learn (Carlson, 1990).

2.0 Out With The Old

I previously taught a traditional graphics course at the University of Illinois at Springfield. Students used Turbo Pascal on PCs to generate the images. They completed four projects during the semester. The first project was a 2D exercise using fractals and other recursively defined curves. The second project was a paint program that emphasized the user interface. The third project displayed wireframe objects with hidden surface removal. Students were responsible for implementing the data structure and all of the low level operations such as clipping and matrix manipulation. The final project built on the previous one by adding view manipulation and lighting models (flat and Gouraud).

3.0 In With The New

Our department recently purchased our first Sun fileserver. The new hardware prompted me to change the programming language from Pascal to C++ in the graphics course. I was also interested in giving students exposure to a real world API but still require them to implement their own code. I selected a free version of OpenGL called Mesa for the renderer, GLUT for the window API, and developed my own C++ library of graphics data structures, called uisGL. These APIs are described in more detail in section 4.0. Since there was only one Sun machine, students used PCs with X server software to access the Sun over the network.

Most textbooks present a bottom up approach to teaching graphics. Students first learn to draw 2D lines and perform window clipping. It is only towards the end of the semester that students get exposure to 3D images with lighting effects. In contrast, a top down approach would allow students to render 3D images from the first day using commercial software and then learn how to implement their own algorithms during the semester. For example, a popular ray tracer such as Povray could be used at the start of the semester to create dazzling images. Students would then write their own renderer by the end of the semester. As appealing as this approach may sound, I am concerned that students would lose the motivation to write their own software after using advanced features of a commercial product early in the semester.

I prefer to teach with a middle out approach. Students use an API to draw 3D wireframe images early in the semester but implement their own rendering algorithms later in the semester. Manipulating 3D wireframe objects is interesting enough to keep the students' attention early in the semester and still provide motivation to create more impressive images later in the semester.

Using the APIs means less coding for the students so I combined both projects related to 3D rendering from the previous semester. Students used pop up menus provided in GLUT to create an interactive program to dynamically change between wireframe, flat shading, and Gouraud shading. Students were freed from implementing the low level details and could concentrate on the important concepts. However, they still had to calculate surface normals and manipulate objects with matrix transformations. This was a nice balance between reusing code and designing from scratch.

4.0 Resources

UisGL is a portable library of C++ classes that provides support to perform the first two steps in the graphics pipeline: data structures and data transformations (Grissom, 1996). Rendering is performed by an API or students can write their own rendering routines. This allows students to create impressive images early in the semester using existing software and slowly replace each component with their own software as the semester progresses. This 'plug and play' approach not only provides motivation early in the semester but it allows for deep understanding of the algorithms by the end of the semester.

UisGL provides several primitives used in graphics algorithms: vertices, vectors, and matrices and a complex data structure for 3D objects. The data structure is used in most graphics textbooks and represents objects as a collection of faces composed of a counterclockwise series of vertices. Additional attributes include the object's color, transformation matrix, and whether it should be smooth shaded or not. Source code is available at the uisGL Web Page (www.uis.edu/~grissom/UISGL). Student manuals explain how to use the software. Instructor materials include instructions for obtaining the software, installing it, and recommendations for integrating the material into a curriculum.

GLUT (Kilgard, 1994) is a window independent API for OpenGL that performs common window operations and provides an event handler. Information about OpenGL and GLUT are available at the OpenGL WWW Center (www.sgi.com/Technology/openGL). This site has many references to commercial implementations of OpenGL, journal articles, and other useful information.

Mesa is a graphics library similar to OpenGL that has the same command syntax. However, the author of Mesa makes no claim that it is a compatible replacement. The software is freely available under the terms of the GNU Library General Public License. Source code and documentation is available at the Mesa Web Site (www.ssec.wisc.edu/~brianp/Mesa.html).

5.0 Observations

We experienced problems during the semester related to our computing environment, software documentation, and software performance. One problem was that students had four different X servers available: one for Windows NT, one for LINUX, one for Macintosh, and OpenWindows for Solaris. These servers were not consistent with how they handled certain events. For example, when GLUT menus came up a display event was issued on some servers to clear the menu and on others it was not. This difference caused subtle problems for the students until we identified the cause.

The biggest problem we had this semester was the slow performance of Mesa on our Sun fileserver. Although still images were displayed in a reasonable amount of time across the network, interactive applications and animations were out of the question. Next time I teach the course I will use an OpenGL implementation that takes advantage of the Sun architecture. This should improve performance and allow students to create simple animations.

Even though students were given sample code to build upon, they needed additional documentation for OpenGL. I did not require them to buy the OpenGL Programming Guide (Neider et al., 1993). Documentation was available on the WWW but I am not convinced that students took advantage of this resource. Instead, we used a draft version of Angel's (1997) new graphics textbook that uses GLUT and OpenGL but it was not sufficient to answer all the questions students had while developing OpenGL code. I found OpenGL to be quite complex and will provide more handouts and sample code next time to help students get started.

In summary, I am pleased with my first experience using the middle out approach to teach graphics. My students appreciated using a real world API such as OpenGL instead of Turbo Pascal. They also gained experience with event driven programming due to the GLUT API. Another benefit is the exposure to client-server issues and performance over the network. This was new to many of the students. I look forward to making a few changes to this course before teaching it again next year.

6.0 Acknowledgments

This work is supported by the Learning Technologies in Higher Education Program at the University of Illinois. I also appreciate the patience and effort of my students who provided valuable feedback during the development of uisGL.

7.0 References

E. Angel, Interactive Computer Graphics with OpenGL, Addison-Wesley, 1997.

W.E. Carlson, "An Environment for a Graduate Curriculum in Computer Graphics," ACM SIGCSE Bulletin, 22(2), June 1990, pp. 15-20.

J. Clevenger, R. Chaddock, R. Bendig, "TUGS - A Tool for Teaching Computer Graphics," Computer Graphics, 25 (3), July 1991, pp.158-164.

J. D. Foley, A. van Dam, S. K. Feiner, J. F. Hughes and R. L. Phillips, Introduction to Computer Graphics, Addison-Wesley: New York, 1994.

S. B. Grissom, "uisGL: A C++ Library to Support Graphics Education," Computer Graphics, 30 (3), August 1996.

M.J. Kilgard, The OpenGL Utility Toolkit (GLUT) Programming Interface, Silicon Graphics, Inc., 1995.

J. Neider, T. Davis and M. Woo, OpenGL Programming Guide, Addison-Wesley: New York, 1993.

N. Schaller, "Graphics Education for Computer Science - Panel Report," Computer Graphics, 27 (1), Jan. 1993, pp. 6-10.

D. Schweitzer and L. Northrop, "Getting to the 'Graphics' in a Graphics Exercise," Computer Graphics, 25 (3), July 1991, 151-175.