Using OpenGL to Create 2D and 3D Graphics
by Joan Slottow
This list shows the sections dividing this article. If you click on one of
them, your view will zoom down to the section you have chosen. Alternatively,
you can skip these linked sections and scroll through the article in the
The purpose of this article is to introduce you to OpenGL which is quickly
becoming the next Graphics Standard API (Application Programming
Interface).OpenGL consists of a set of functions that you can call from your
own program to create 2D and 3D graphics on the workstation.
In addition to introducing you to OpenGL, it is hoped that this article will
put OpenGL into context, so that you can get a better idea of whether or not
you want to use it on the SP/cluster. Alternative ways of visualizing data are
discussed, as well as competing products.
Brief Overview of OpenGL
OpenGL is a software interface that allows the programmer to create 2D and 3D
graphics images. OpenGL is both a standard API and the implementation of that
API. In other words, OpenGL is a set of functions which have the same syntax
and which act the same on every platform, even though the actual subroutines
which implement the standard have been written by different vendors. You can
call the functions that comprise OpenGL from a program you write and expect to
see the same results no matter where your program is running.
Graphics programming concepts underlie the functionality of OpenGL. These
concepts are easy for the average application programmer to understand and
use. OpenGL is independent of the hardware, operating, and windowing systems
in use. The fact that it is windowing-system independent makes it portable. It
also makes programming easier with OpenGL than with an API that is integrated
with a windowing system, since learning how to program a windowing system is
often quite complicated.
However, since graphics are normally displayed in a window, and since you have
to have some way of obtaining input from the user, your OpenGL program must
interface with the windowing system of the platform where the graphics are to
be displayed. Therefore, a number of windowing toolkits have been developed
for use with OpenGL. Some are simpler than others to use.
OpenGL functions in a client/server environment. That is, the application
program producing the graphics may run on a machine other than the one on
which the graphics are displayed. The server part of OpenGL, which runs on the
workstation where the graphics are displayed, can access whatever physical
graphics device or frame buffer is available on that machine. This makes
OpenGL a software interface to the actual hardware.
The IBM implementation of OpenGL is available for your use on the SP/cluster.
Who uses OpenGL?
OpenGL can be used by anyone who writes an application which requires that
graphics be displayed. Many commercially available software packages use
OpenGL. For example, IBM Data Explorer (dx), a popular scientific
visualization software package running on the SP/cluster, can render graphics
in both hardware and software modes. For software rendering it uses X Window
graphics. For hardware rendering it uses either GL, OpenGL's predecessor, or
OpenGL. Graphics rendered in hardware are usually faster and of better quality
than software-rendered graphics.
You can call the OpenGL functions directly from a program you are writing if
you want to draw pictures directly from one of your own programs. This article
should help you decide whether or not this is something you want to do.
The Nature of Graphics Programs and the SP/Cluster Environment
The SP/cluster nodes are divided into two categories: interactive and batch.
You can run programs on the interactive nodes that require human interaction.
However, all long-running and compute-intensive jobs must be submitted to
LoadLeveler to be run on the batch nodes. Any program run on an interactive
node that uses more than 30 cpu minutes in a 24-hour period is automatically
killed. People who have long-running programs often use the interactive nodes
to test them before submitting them to LoadLeveler.
The OpenGL specification, and IBM's implementation of OpenGL in particular,
require that any program which uses OpenGL be run interactively. This is
because OpenGL uses the graphic adapter which is part of your display to
render the graphics. This makes it impossible to run an OpenGL application in
batch under LoadLeveler because when you run a job under LoadLeveler there is
The way we have visualized data produced by long-running jobs in the past (and
still do), is to write the data out to disk files and to visualize it
afterwards with a program such as IBM Data Explorer, GnuPlot, PV-Wave, or AVS.
When writing out the data for a large number of time steps in order to produce
a movie, the amount of data produced can be very large. There are ways to save
disk space and eliminate an extra step by producing the graphics images
directly on disk from your program. This would only work, of course, in a case
where the data is produced for the visualization only and is not needed for
any other purpose.
One possible way to do this is to use OpenGL. This would require that you do
all the graphics programming yourself and incorporate it into your simulation
or other program. You could include calls to the OpenGL API and one of the
windowing toolkits when you test the program interactively. This would allow
you to see and debug the graphics. Then, when you are ready to run in batch,
you can switch over to Mesa, an OpenGL API look-alike which includes
off-screen rendering, which basically renders the image to memory. Off- screen
rendering is accomplished with three function calls. They are documented on
the SP/cluster in the header file:
/local/include/mesa/GL/osmesa.h. A sample program can be found in /local/apps/mesa. This program renders an
image off-screen and then writes it out in a .pnm file. From there you can
convert it to any other image type you like using tools already on the system.
The newest version of Data Explorer, dx 3.1 provides another means to create
image files directly from a long-running program. With it, you can execute a
Data Explorer network under control of your program. The images need not be
displayed and can be saved directly to the disk. A major difference in using
dx versus OpenGL is that with dx you don't have to do any of the graphics
programming yourself. You can test the graphics interactively by building a dx
network with the normal dx GUI user interface and, when ready, run that
network directly from your application program. We are planning to obtain dx
3.1 for the SP/cluster.
OpenGL would also be very good to use in interactive applications in which the
user has to interact with the graphics. An example would be an application in
which the user interacts with a graphic to sample or subset the data and to
compute new data based upon a selection.
Before you rush out to write your own graphic application however, you should
look into the software that is already installed and see if any of it is
useful to you. The following software packages on the SP/cluster can create
visualizations or graphs from data:
The following packages consist of subroutines that can be called to produce
visualizations or graphs directly from your program:
The following packages are discipline-specific and do graphics in addition to
doing something else:
- Data Explorer
SAS, for example, allows you to interact graphically with data, find and
eliminate outliers and select alternate statistical analyses.
Detailed Description of OpenGL
OpenGL functions (which are called commands) are designed to provide 2D and 3D
graphics with the emphasis on 3D. The program is fully functional, including
everything that users usually want out of 3D graphics. This includes:
OpenGL's rendering commands, however are "primitive". You can tell
the program to draw points, lines, and polygons, and you have to build more
complex entities upon these. There are no special-purpose functions that you
can call to create graphs, contour plots, maps, or any of the other elements
we are used to getting from "old standby programs" like the
Calcomp/Versatec subroutine library, DISSPLA, and DI/3000. With OpenGL, you
have to build these things up yourself. Again, with the programs just
mentioned you could not do "real" 3D graphics, nor could you get
shading, lighting, texture mapping and all the other features that OpenGL
- 3D modeling
- Gouraud shading
- texture mapping
- non-uniform rational B-spline (NURBS) curves and surfaces
- atmospheric fog
- alpha blending
- motion blur
Open Inventor, a separate product, is available if a higher- level of
functionality is desired. Open Inventor is an object-oriented toolkit written
in C++ on top of OpenGL. It provides pre-built objects, a built-in event model
for user interaction, and other components that can be used by higher- level
applications that do interactive 3D graphics.
Immediate and Display List Execution
With OpenGL any commands that you execute are executed immediately. That is,
when you tell the program to draw something, it does it right away. You also
have the option of putting commands into display lists. A display list is a
not-editable list of OpenGL commands stored for later execution. You can
execute the same display list more than once. For example, you can use display
lists to redraw the graphics whenever the user resizes the window. You can use
a display list to draw the same shape more than once if it repeats as an
element of the picture.
Display lists reside with the OpenGL server. If the client and server machines
are different, as they are when you use the SP/cluster as the client, this
minimizes network traffic. Also, the display lists can be optimized on the
server side for the specific hardware.
OpenGL Components on the RS/6000
OpenGL is divided into several libraries:
- Base library
- This library includes all the basic 3D rendering functions, including depth
(Z) buffering, matrix and attribute stacks, and display list creation and
manipulation facilities. It also includes anti-aliasing, user-defined clipping
planes, and fog and atmospheric effects.
- OpenGL Utility Library
- This library includes functions for creating orthographic and perspective
projections, converting between world and window coordinates, transforming
coordinates, texture mapping, error reporting, rendering canonical shapes such
as spheres and cylinders and tessellating concave and multicontour polygons.
- OpenGL X Windows Extension
- This library is the marriage of OpenGL and X. You need it to perform
windowing functions if your server machine is running X Windows. Its design
integrates OpenGL into X in a way that is consistent with the way X works.
OpenGL works with sophisticated frame buffer types: double and single
buffering, depth buffers, stereo windows, stencil, and accumulation buffers,
none of which are defined in X Windows. The GLX library extends X so that it
can allow OpenGL and X to write into the same window if that is what is
- OpenGL Motif Widget Library
- This library is new with AIX 4.1. It includes just a few functions that you
can use to create a Motif widget that can be used as a canvas for OpenGL to
OpenGL Functions Independently of Hardware and Windowing System
OpenGL is hardware-independent. Many different vendors have written
implementations that run on different hardware. These implementations are all
written to the same OpenGL standard and are required to pass strict
conformance tests. Vendors with licenses include SGI, AT&T, DEC, Evans
& Sutherland, Hitachi, IBM, Intel, Intergraph, Kendall Square Research,
Kubota Pacific, Microsoft, NEC, and RasterOps. The RS/6000 version comes with
X and Motif extensions. However X is not required to run OpenGL since OpenGL
also runs with other windowing systems.
The Architecture Review Board
The OpenGL standard is set by the OpenGL Architecture Review Board. The board
controls changes to the API and licensing and conformance testing. Members of
the board, which each have one vote, are as follows: DEC, Evans &
Sutherland, IBM, Intel, Intergraph, Microsoft, and SGI.
The information here on the supported platforms may not be entirely up to date
and should be taken as a minimal subset of the supported platforms. Supported
- OpenGL is supported by the DEC Open3D layered product for OSF/1 AXP and
OpenVMS AXP workstations. It is not offered on VAXstations or DECstations.
- IBM RS/6000
- OpenGL is supplied for RS/6000 IBM. It is implemented for almost every
graphics adapter available for RS/6000.
- IBM has partnered with Portable Graphics and provides their implementation
of Open Inventor for IBM RS/6000 platforms. OAC, however, does not have Open
Inventor available on the SP/cluster.
- Template Graphics Software also has a version of Open Inventor for RS/6000.
- IBM PC
- OpenGL is part of the base operating system for OS/2 2.1 and OS/2 Warp.
- OpenGL is offered as a standard feature of Microsoft Windows NT Workstation
version 3.5 and later.
- Portable Graphics, Inc., also has versions available for Windows NT, OS/2
and Windows 95.
- Silicon Graphics
- OpenGL and Open Inventor are supported by SGI for various SGI platforms
under IRIX 5.2 and 5.3 including: Indy, Indigo, Indigo2, Crimson, Onyx.
- Hewlett Packard
- Evans & Sutherland is the supplier of OpenGL for Hewlett Packard
- Template Graphics Software is providing OpenGL for Power Macintosh.
- Portable Graphics, Inc., a subsidiary of Evans & Sutherland Computer
has a version for Sun which is optimized for SPARC/Solaris.
- Template Graphics Software, Inc. (TGS) is providing OpenGL for Sun SPARC
Solaris 2.x acceleration hardware.
OpenGL is documented in the two-volume printed set from Addison-Wesley, which
is available at the ASUCLA Student Store:
"OpenGL Reference Manual ISBN 0-201-63276-4"
"OpenGL Programming Guide ISBN 0-2-1-63274-8"
Mesa is a 3-D graphics library based on OpenGL. It was written by Brian Paul of
the University of Wisconsin at Madison. He makes no claim that it is in any
way a compatible replacement for OpenGL, however, it is extremely similar. One
major difference between Mesa and OpenGL is that Mesa uses regular X Windows
graphics on Unix machines and is therefore not a software interface to any
specific hardware graphics devices. Mesa works on most Unix platforms that
have X11, including recently added Linux, and drivers for Microsoft Windows
and for Mac OS are available. There will be additional discussion of Mesa
later in this article.
GL, Predecessor to OpenGL -- Some History
GL, OpenGL's predecessor, also called Iris GL, was developed by Silicon
Graphics in 1982. GL stands for Graphics Library. GL was selected by IBM as
the API to drive the graphics adapters (frame buffers) that were installed in
its RS/6000 series of workstations when the RS/6000 was initially developed.
GL is used by more than 1500 applications including IBM Data Explorer, AVS,
Biosym Insight II, Grass, and more.
GL subroutines make direct use of the graphics adapter hardware installed on
the workstation. As such, GL graphics is usually referred to as hardware
graphics, as opposed to X Windows graphics, which is referred to as software
graphics (or software rendering). When software rendering is performed, the
graphical image is created via the software running on the machine. The
rendered image is then displayed in a window via calls to X. With hardware
rendering, much of the work of creating the image is carried out via special
hardware, the graphics adapter.
GL includes support for getting input from input devices, creating and drawing
into windows, frame buffer configuration and control, and basic and advanced
3D rendering. GL subroutines have both C and Fortran bindings.
The use of GL also has certain disadvantages. Most notable are:
OpenGL fixes at least the first of these disadvantages. OpenGL works across the
network. Major changes made with the implementation of OpenGL include:
- It does not work across the network. The user of the graphics must be
sitting at the local display device attached to the machine. For this reason,
many software developers implemented hardware rendering for the local user and
software rendering for the remote user. A program with GL only graphics can
only be run when you are sitting at the machine on which it is installed.
- Even though windows which contain GL graphics look like normal X Windows,
they are not. If you want to print a GL graphic by capturing the window, you
can't do it by normal means such as xwd or xgrab. You must write a GL program
to do it and that program must use the same graphics: rgb or color lookup as
the original, and the same buffering: single buffering or double buffering.
- OpenGL works across the network using the client/server model.
- The API has been cleaned up. All subroutine names now start with the
- All windowing has been removed from the OpenGL base library. You must use
either the GLX library or one of the windowing toolkits.
- The above two points imply that if you have a program that uses GL, you
must rewrite it to use OpenGL.
- New features have been added including: texture mapping, anti-aliased
polygons, and stencil and accumulation buffers.
- OpenGL is designed to be callable by C, C++, Fortran, and Ada. However, all
of the OpenGL manuals and other documentation that I have been able to find
use the C bindings and do not even document what the Fortran calls look like.
I asked IBM if their version of OpenGL includes support for Fortran and got
back what was essentially a null answer.
OpenGL on IBM RS/6000
Client/Server Has Important Implications for You
Because OpenGL operates on the client/server model, the fact that the IBM
implementation of OpenGL is available for your use on the SP/cluster is not
sufficient for you to use it there. Any program which runs on the SP/cluster
and which uses OpenGL to produce graphical output would be the client program.
The server of the client/server model, in this case, is the X Windows server
which is supporting your local display. There are a number of cases:
In all of these cases, if you do not have OpenGL support in your server, you
cannot view the OpenGL graphics. If that is so, you can recompile and relink
the program (if you have the source code) with the libraries provided with
Mesa. You will now be running with ordinary X Windows graphics, which is
provided for in all of the cases outlined above.
- Your server is running on another IBM RS/6000
- You are using another vendor's Unix workstation
- You are using an Xstation (X terminal) in the public area
- You are using an IBM PC with some X Windows support software, such as
- You are using a Macintosh with some X Windows support software, such as Mac
Let's take the cases one by one:
1. Your server is running on another IBM RS/6000
IBM has implemented OpenGL on almost every graphics adapter
available for RS/6000 machines. Because computer processors have become
faster, it is now possible to implement 3D graphics entirely in software,
without hardware. Therefore, IBM has implemented Soft3D, which is their OpenGL
server software for low-end configurations, those without overlay planes and
with only one hardware colormap.
First, you must have OpenGL installed on your server machine. Then you must
request the OpenGL extensions to X when you start up X. This can be done with
xinit -- -x GLX -x abx -x mbx
If you are using the Common Desktop Environment you can modify the
file /usr/dt/config/Xservers to add the extensions, or the file
/usr/lpp/X11/defaults/xserverrc changing EXTENSIONS="" to
EXTENSIONS=" -x GLX -x abx -x mbx". In both cases, you have to logon
2. You are using another vendor's Unix workstation
You have to install OpenGL and follow the instructions given by
your OpenGL vendor.
3. You are using an Xstation (X terminal) in the public area.
We haven't gotten that to work yet, but are still attempting to
4. You are using an IBM PC with some X Windows support software, such as X-Win.
X-Win does not support OpenGL but may do so at a future date.
5. You are using a Macintosh with some X Windows support software, such as Mac
Mac X does not support OpenGL.
Applications that use colors deal with them in one of two ways:
The use of a color lookup table takes significantly less memory but provides
for fewer colors. Most 3D applications, and OpenGL in particular, operate
using RGB colors because it is the natural color space for colors and lighting
and shading. However, under AIX, X Windows and the Motif Window Manager use
color index mode because they are working with a limited number of solid
colors. Therefore, unless you specifically start your X server in RGB mode,
which isn't recommended since many simple X clients then won't work, or have a
GXT 150 graphics adapter, color flashing will occur when you run OpenGL.
- RGB, also called TrueColor -- Every pixel has a red, green, and a blue
value associated with it.
- via a Color LookUp Table (CLUT), also called color index mode -- Every
pixel has a color index associated with it. The color index is a pointer into
the color lookup table where the real RGB values reside.
When the focus shifts to an OpenGL window, either by clicking on it or by
moving the mouse pointer to it, the way you have instructed X to change focus,
the colors of the rest of the windows will change dramatically. When a
non-OpenGL window is in focus, the colors in the OpenGL window will change.
This is what IBM calls color flashing and what I call steeling the colors.
Capturing and Printing the OpenGL Window
You can capture a graphic image created by a program using OpenGL from the
display and save it into an xwd file using either the command xwd -out
filename, or the xgrab utility which presents you with a GUI interface.
Specify that you want an X Window Dump for the output format, To file, and a
file name. Note that you cannot use the general purpose image converter from
the San Diego Supercomputing facility, imconv, to convert the xwd image to
another format, but you can use Jef Poskanzer's xwdtopnm, to convert it to a
portable anymap and from there, convert it to something else.
You can also print any OpenGL image you see on the screen. Use xgrab. Specify
PostScript for the output format, Color Output under PostScript Options
"To file", and a file name. Since we currently don't have a color
PostScript printer connected to the SP/cluster, you will have to ftp the
PostScript file elsewhere before printing it.
auxlib, the auxiliary toolkit library, used in the examples in the
Addison-Wesley books comes with the IBM version of OpenGL and is available on
the SP/cluster. The auxiliary library also comes with Mesa. This toolkit is
easy to use but also limited in functionality. For example, it only allows for
one graphics window.
In addition, we have installed GLUT, a windowing toolkit by Mark Kilgard. GLUT
Two versions of GLUT are available: one for IBM's OpenGL and the other for Mesa
- windowing functions, including multiple windows for OpenGL rendering
- a simple cascading pop-up menu facility
- bitmap and stroke fonts
- event processing
- plus other functionality not available on RS/6000
How to Compile and Link OpenGL Applications
When using IBM's OpenGL with auxlib, specify the following:
include files: <GL/aux.h>
OpenGL libraries: -lGL, -lGLU
windowing toolkit libraries: -laux
X Windows libraries: -lXm, -lXt -lX11 When using IBM's OpenGL with GLUT, specify the following:
include files: <GL/glut.h>
OpenGL libraries: -lGL, -lGLU
windowing toolkit libraries: -lglut
X Windows libraries: -lXmu, -lX11
When using IBM's OpenGL with GLX library, specify the following:
include files: <GL/gl.h>, <GL/glx.h>
OpenGL libraries: -lGL, -lGLU
X Windows libraries: -lX11 When using Mesa with auxlib, specify the following:
include files: "glaux.h"
include files: -I/local/include/mesa,
Mesa libraries -L/local/lib/mesa, -lMesaGL,
windowing toolkit libraries: -lMesaaux When using Mesa with GLUT, specify the following:
include files: <GL/glut.h>
include files: -I/local/include/mesa
Mesa libraries: -L/local/lib/mesa, -lMesaGL,
windowing toolkit libraries: -L/local/lib/mesa, -lglut
X Windows libraries: -lXmu, -lX11
When using Mesa with off-screen rendering, specify the following:
include files: <GL/osmesa.h>, <GL/gl.h>,
include files -I/local/include/mesa
Mesa libraries: -L/local/lib/mesa,
-lMesaGL -lMesaGLU 17
Joan Slottow is the OAC Consultant in charge of the OAC Visualization
Laboratory. Contact OAC Vis Lab Consulting
01 May 96; Rev. 23 Jan 97