OpenGL for Mac Users 1
Volume Number: 14
Issue Number: 12
Column Tag: Power Graphics
OpenGL for Mac Users: Part 1
by Ed Angel, University of New Mexico
How to get started programming 3D graphical applications
Graphics has always been one of the strongest points for the Macintosh. Although the
Mac has been dominant in the graphic arts community, it has not had the same impact
on the 3D CAD community or on those who write graphical applications in high-level
languages. For these users, the search for a standard Application Programmer's
Interface (API) has been going on for over 20 years. While official standards efforts
have failed to produce an API that is actually used by a large part of the community, an
API that had its origin in a particular architecture has become the choice for thousands
of graphics programmers on systems ranging from SGIs to PCs to Macs.
This article will provide an introduction to OpenGL. We shall give the overall
structure of this API and then develop a simple application program. We shall then see
the ease with which we can convert our simple program to one that incorporates the
dynamic and three-dimensional rendering features that we associate with modern
graphics. Along the way, we shall see why this particular API should be of interest to
the Mac community. A subsequent article will survey the advanced features supported
by OpenGL and how OpenGL can exploit the available hardware.
The OpenGL API
The search for a standard graphics API began over 20 years ago and has produced a
succession of interfaces from the early CORE proposal to the ISO standard GKS and its
successors (GKS-3D, PHIGS). With the possible exception of PHIGS, these APIs failed
to be used by large parts of the 3D programming community. Generally, these APIs
either lagged hardware developments or were not sufficiently general to be used on a
wide range of graphics architectures. OpenGLî began as GL, an API for using Silicon
Graphics Inc hardware. At that time, SGI produced high-end graphics workstations
that implemented much of their functionality at the chip level. Application
programmers needed an API to make use of these features and GL provided such access.
Somewhat surprisingly, programming in GL was considerably easier than in any of the
other standard 3D APIs available at the time. OpenGL was developed as a successor to
GL that could be implemented on a variety of architectures. By removing the input and
windowing features of GL, it became compatible with most other windowing systems,
including X Windows, Windows 95 and NT, and Mac OS. The popularity of OpenGL as a
way of accessing high-level hardware features has led it to be supported by many of
the add-on graphics card developers.
Figure 1 shows a typical graphics programming environment. Users write programs
in a high-level language. From this perspective, the API looks like one or more
libraries that contain the graphics functions. On the other end, however, the API
communicates with the hardware, either directly or through a hardware abstraction
layer. A good API shields the application programmers from the details of the hardware
and allows them to write applications that are independent of the machine on which
these applications will run. However, a good API is close enough to the hardware that it
leads to efficient use of these resources and allows the application programmer to
make use of hardware features.
Figure 1. Levels of a Graphics Environment.
Figure 2. Synthetic Camera.
Most modern graphics systems are based upon the synthetic camera model in Figure
2. A program must allow the user to specify the objects in the scene and the viewer
(or camera). Because both objects and viewer are in a three-dimensional world, the
API should allow their specification in a three-dimensional coordinate system. The
details of how these specifications are combined mathematically, via the projection
process, to form a two-dimensional image is the job of the graphics hardware and
software.
Figure 3. Graphics Pipeline.
Graphics architectures, whether workstations or special purpose boards, have evolved
to the pipeline configurations similar to the one in Figure 3. Graphical objects are
specified through a set of locations in space (vertices) that are passed through a first
transformation that scales, orients, and positions the objects and a second that
projects the resulting positions to their correct two-dimensional locations on the
screen. The collection of parameters necessary to accomplish these tasks - rotation
angles, scaling coefficients, camera angles - are part of the state of the graphics
system. As graphical objects flow down the pipeline, the present state determines how
they are to be rendered; whether they should be shaded, whether hidden-surface
removal should take place, and whether they should be texture mapped. Because many
of the high level functions that users now expect, such as texture mapping and
compositing, involve the use of arrays of picture elements (pixels), modern
architectures also provide a parallel pipeline for pixels and access to a variety of
buffers.
The OpenGL API is based on this architecture. We can divide the routines into a few
basic categories
• Primitive specification functions that defined the atomic objects that
OpenGL supports. These include geometric primitives, such as line segments
and polygons, and discrete primitives, such as bitmaps, and pixel arrays.
Geometric primitives are supported in two, three and four dimensions and in
most of the standard data formats. Higher level objects including Bezier
curves and surfaces, quadrics, and NURBS curves and surfaces are supported,
although are rendering through the simpler primitives.
• Attribute specification functions set colors, line types, fill patterns,
material properties and lighting specifications.
• Transformation functions control both geometric transformations
(rotation, translation, and scaling) and the viewing transformations
(orthographic and perspective).
• Control functions enable various features including hidden-surface
removal, lighting, texture mapping, blending and antialiasing.
These functions generally are contained in two libraries: GL which contains the basic
functions, and GLU, which contains useful additional functions built from functions in
the GL library. OpenGL is a rendering library whose main concern is displaying
graphical entities on the screen. It does not contain windowing and input functions.
This lack allows us to use OpenGL with a variety of systems but allows OpenGL
applications to make use of the local environment. Most implementations provide a
basic library of interface routines. For the Mac, these routines are in a library called
AGL. One alternative is a simple library called GLUT (OpenGL Utility Toolkit) that
incorporates the functionality common to the standard windowing systems and has been
implemented on most of the standard systems. GLUT allows us to put a window on the
display and get input from the mouse and keyboard through callback functions that
define how OpenGL should react to events within the windowing environment. Because
in this article we are concerned with the basics of OpenGL and portability, we shall
make use of the library.
Program Structure
A typical OpenGL application consists of a set of functions including
• main which initializes the system, describes the required display
properties, sets up any menus, and names the callback functions. The last
statement of a typical main function puts the program in an event loop and the
program's further behavior is determined through the callbacks.
• display is a callback that is invoked whenever the windowing system
determines the OpenGL window must be redisplayed. One time is when the
window is first opened. Subsequent calls to this callback are made from other
callbacks.
• myinit is a user defined function that includes atttributes and enabling of
OpenGL capabilities. A user may decide to put menu definitions here rather
than in the main function.
These three functions will appear in virtually all OpenGL programs. Most applications
will make use of at least a few other callbacks. In GLUT, these include a mouse
callback, a keyboard callback, an idle callback that is used whenever no other events
are pending, and a reshape callback that is called whenever the window is resized.
A Simple Application
Our first example draws a box on the display once. It uses the GLUT library to define a
screen window of 200 x 200 pixels.
Listing 1: box.c
/* Display a two-dimensional box in OpenGL */
#include "glut.h" /* should include gl.h and glu.h
*/
display()
{
glBegin(GL_LINE_LOOP); /* Square centered at origin */
glVertex2f(-1.0. -1.0);
glVertex2f(-1.0. 1.0);
glVertex2f(1.0. 1.0);
glVertex2f(1.0. -1.0);
glEnd();
}
void myinit()
{
glColor3f(1.0, 1.0, 1,0); /* Drawing color */
glMatrixMode(GL_PROJECTION); /* Set clipping window */
glLoadIdentity();
gluOrtho2D(-2.0, 2.0, -2.0, 2.0);
glClearColor(0.0, 0.0, 0.0, 1.0); /* set clear color */
glClear(COLOR_BUFFER_BIT); /* now clear Frame Buffer */
}
void main(int argc, char **argv)
{
glutInit(&argc, argv); /* Initialize GLUT */
glutInitDisplayMode(GLUT_RGB); /* Request 3 color screen window
*/
glutInitWindow(200, 200); /* request 200 x 200 window */
glutCreateWindow("box"); /* Window title */
glutDisplayFunc(display); /* Name display callback */
myinit(); /* User settings */
glutMainLoop(); /* Enter event loop */
}
Although there are six GLUT functions in our initialization, these will be almost
identical in most applications. In fact, there are default settings that would have been
used if we had omitted glutInitDisplayMode, glutInitWindow, glutCreateWindow and the
setting of colors. The display callback requires only the name of the function that will
be run and we can place most of our drawing functions in this function. Note the form
of the specification of the square. We state what we want to draw in glBegin, follow it
with a list of vertices, and finish with a glEnd. There are multiple forms of glVertex
that allow us to use the standard data types, such as int (i), float (f) and double (d).
We can specify vertices in 2, 3 or 4 dimensions and either specify the components or,
as we shall see in the next example, point to an array of the components. Strings such
as GL_LINE_LOOP are defined in gl.h, which is normally included by glut.h.
OpenGL supports three-color (RGB) , four-color (RGBA) and color-index mode
graphics with RGB as the default. Colors that are specified as floats or doubles range
from 0.0 to 1.0 where 0.0 means none of that component and 1.0 means fully on. For
integers and unsigned bytes, color components range over the full range of the type.
The clear color is in RGBA format and in our examples clears the screen to black and
opaque.
We specify a two-dimensional rectangle as a line loop in which the final vertex
specified is automatically connected to the first. The code in our display callback only
describes the object and not the camera. In OpenGL, there is a default camera at the
origin pointing in the negative z direction. This camera only sees the region in a 2 x 2
x 2 box centered at the origin. Objects outside this region are clipped out. Most
applications require more flexibility so we specify a camera and clipping region
through the projection matrix. In two dimensions, the function gluOrtho2D forms an
orthogonal projection matrix and sets a clipping rectangle in the two-dimensional
object plane that is mapped to the screen window specified by glutInitWindow. The
matrix becomes part of the graphics state. We set it by specifying which matrix we