15-463 Course Software
The software setup for this course is nearly identical to
that for 15-462.
is a programming interface for interactive 3D graphics.
exist for various platforms.
To learn more OpenGL we recommend the book
OpenGL Programming Guide, 3rd Edition: The Official Guide to
Learning OpenGL, Version 1.2 by Woo et al,
1999. (earlier editions OK, too).
Another book on OpenGL, the Reference Guide,
is available in both printed and
electronic forms, but it's a rather poor substitute for the
On an SGI, run "insight &" to get the Programming Guide.
Mesa is a free
implementation of OpenGL that runs on Sun with UNIX, Linux
PCs, and other machines, with a variety of graphics boards.
For some boards and drivers, OpenGL is supported mostly in
hardware; for others it is implemented almost entirely in
software. On UNIX and Linux, OpenGL is almost always layered
on top of XWindows. The Mesa
file describes some its special features.
As suggested there, if you put the line "setenv MESA_DEBUG"
in your .login, that will cause Mesa to print out error messages
if you do something illegal in your OpenGL calls.
Mesa can emulate a 24 bit display on an 8 bit one, and that's
the way we recommend using Mesa on the 8 bit Suns.
Setting up the
colormap so this works right is a bit tricky. (If you want the
full story, see the
and do a find for "glXChooseVisual".)
we're providing for the assignments should set things up so
that you don't need to worry about this, however.
Mesa version 3.2.1 is installed as libGL.so in the class's lib
You can link it with -lGL .
See below for more linking tips.
is a nice graphical user interface library.
It doesn't rely on X Windows, as its predecessor library Xforms did.
It is portable to UNIX, Linux, and Windows.
We have a
local copy of the documentation.
FLTK comes with
an interactive interface design and layout program called fluid.
If you prefer to use some other user interface library, feel
the Simple Vector Library, written by Andrew Willmott here at CMU,
is a C++ library for vector and matrix arithmetic.
It is very useful for operations with xyz vectors, colors,
This is a little library provided for your convenience. It
supports a very simple interface to and write TIFF or PPM picture files.
Some of our programs,
such as xplay, use this library. The routines you might be
interested in are pic_read and pic_write. To use
this library, you need to put #include <pic.h> in your
source code and -lpicio on your link line. Currently, the
only documentation for the library is the header file,
and the simple program
The latter shows how to use the library to write a simple program to
read, modify, and write a TIFF picture file.
The source code for libpicio is in
Libpicio is a layer on top of Sam Leffler's excellent
libtiff library for
TIFF picture file I/O.
For previewing animation:
For viewing stills and image processing:
- The xplay program can read PPM and TIFF picture files
and display them at various speeds or single framed. Paul
Heckbert wrote it. Try, e.g. xplay *.tif . Sometimes
it uses so much memory that the X server bogs down and thrashes
or crashes. To use less memory / run faster:
This program is in the class bin directory; its source is in
- xplay ??0.tif --- display every tenth frame
(frame numbers ending in 0).
- xplay ??.tif --- display every fifth frame
- xplay -zoom .5 *.tif --- display pictures half size
- xplay -depth 8 -grid ??.tiff - will display using
8 bits per pixel (not 24), thereby saving X server memory, showing
every 5th frame.
- xplay `cat frame.list` - will display the frames
listed, one per line, in the file frame.list
(Bug: as of 2/1/00, on linux, if your tiffs are 8 bit pseudocolor,
not 24 bit (check that with tiffinfo), xplay probably won't work right.
If you create your tiffs with the pic_write or tiff_write routine,
they will be 24 bit.)
- The animate program in /usr/contributed/bin is also
good. Try it also.
- If you have Adobe Premiere or some other video
editing software, then you can convert your animation into MPEG
or other digital video format and go to town.
- mpeg_encode can be used to generate mpeg versions of your
animation; mpeg_play can then display them. This is a pretty
fast process and will allow you to preview your animation even
on machines with small memory. If the cluster machines don't
have this, you could find the source on the web.
display can display many picture file formats.
It does a good job displaying 24 bit pictures.
convert is good for file format conversion from the
xv reads most format and permits interactive cropping,
file format conversion,
and many other functions.
The user interface is a bit clumsy, but it works.
On the Andrew cluster, the installed version of xv is quite old
(1992) and will not display a 24 bit picture file using a 24 bit
window; it always converts to 8 bits per pixel.
I therefore do not recommend its use if you're concerned about
Use display or xplay some other program instead.
(Bug: As of 2/2/00, it appears that xv won't display many TIFF files
properly (it displays them as ASCII files).
Perhaps xv wasn't compiled correctly?
Computing Services says this should be fixed in a few days.)
gimp is a nice image processing system for UNIX, if you can find it
Adobe Photoshop (PC or Mac) is the best image processing software;
it can do almost anything.
fluid is the user interface design program for FLTK,
as mentioned previously.
It is in the class bin directory.
I suggest you set your path automatically by putting something like
in your .cshrc or .login to get these programs with minimum hassle.
set path=($path /afs/andrew/scs/cs/15-463/pub/bin)
The include files for Mesa, FLTK, libpicio, and libtiff are in
so if you compile with
your source code can use, for example
to include some of the more important include files.
#include <GL/gl.h> /* for OpenGL */
#include <pic.h> /* for libpicio */
#include <FL/Fl.H> /* for FLTK */
The Makefiles we provide will link the starter code correctly on
cluster Sun and Linux machines, so hopefully you won't need to
muck with the following much.
Typical link sequences, if you're using FLTK, are:
If you're linking with the pic_ and tiff_ routines,
then you'll need -lpicio -ltiff as well.
on Linux: -lfltk -lGLU -lGL -lX11 -lXext -lm
on Sun: -lfltk -lGLU -lGL -lX11 -lXext -lsocket -lm
on SGI: -lfltk -lGLU -lGL -lX11 -lm
A quick tutorial on UNIX libraries:
Subroutine libraries come in two forms, .a files and .so files.
When you make an executable, subroutines are ``linked'' to the main
If you compile with -lfoo, the compiler by default looks for the archive file
and if it doesn't find it, it looks for the shared object file libfoo.so.
These files are searched for in the list of directories given in -L options
to the C/C++ compiler, then in the directories listed in the shell variable
$LD_LIBRARY_PATH, then in the default directory /usr/lib.
See "man ld" for more details.
When an archive file (.a) is linked, the appropriate subroutines from the
object files (.o) are copied, making your executable larger, but ensuring that
it will always run (on the right architecture).
When a shared object file (.so) is linked, the subroutines are not copied
and compile/link time.
Instead, at run time, the system uses LD_LIBRARY_PATH to find the
.so file and the appropriate subroutines are dynamically
linked into your executable in memory.
This results in much smaller executable files,
but it means that if you copy your
executable to another machine without copying all of the .so's it references,
your program won't run.
The upshot of this is that LD_LIBRARY_PATH must be set correctly or something
is likely to fail.
You'll need the command
It's a good idea to put this command in your .login .
On the Suns, it's critical that you
list the class lib directory before /usr/lib and /usr/local/lib,
or you'll get Sun's version of OpenGL (from /usr/lib), rather than Mesa's.
Our experience is that Sun's OpenGL doesn't work well on Suns having
only 8 bits per pixel (the colormap is wrong).
You can, of course, check this variable with
setenv LD_LIBRARY_PATH /afs/andrew/scs/cs/15-463/pub/lib:/usr/lib:/usr/local/lib
On an SGI, you'll probably also need
for shared object files such as libfltk.so and libGL.so to be resolved
setenv LD_LIBRARYN32_PATH /usr/local/lib32
You can get a list of shared object files that a given executable needs
Working on a Non-Cluster UNIX/Linux Machine
If you want to set up so you can program the assignments directly on
a non-cluster machine, without remote login to a cluster machine,
you'll need to do some extra work, namely copy the include files and libraries.
In order to compile code, you'll need the include files.
Copy the include directory hierarchy to your machine.
(We currently have different versions for each architecture, but I think
the differences are insignificant, so copy any of them.)
Then you'll need the libraries for linking.
Figure out what architecture your remote (e.g. home) machine is.
On many systems you can do this by running "sys";
If it's an Intel processor running Linux, then copy the directory hierarchy
If it's a Sun Sparc, copy pub/arch/sun4_57/include.
To copy a hierarchy, the easy way to do it is
cp -r source-dir dest-dir
Another way to do it is:
The L option to tar tells it to follow symbolic links.
You'll probably want option this to help grab files that come
from outside the 463 hierarchy such as the header files for libpicio
(cd source-dir; tar cfL - .) | tar xvf -
If your machine is not a Sun or a Linux machine (an Alpha, say) then
the first thing to do is check the web pages for the libraries above
(Mesa, FLTK, etc) to see if a compiled library is available for your
If not, you'll need to get the source and recompile.
If it was written by someone at CMU and it's used in this course,
you should find the source code in the class src directory.
To get documentation via the "man" program, put this
in your .login or equivalent shell initialization file.
setenv MANPATH /usr/share/catman:/usr/share/man:/usr/catman:/usr/man:/usr/local/man:/afs/andrew/scs/cs/15-463/pub/man
15-463, Computer Graphics 2
Paul Heckbert, Jan. 2001