This page documents the graphics software development platforms and APIs (Applications Programming Interfaces) supported in the course. These are selected based partly on the CCIS undergraduate curriculum and partly on current use in research and commercial contexts.
To complete the homework assignments, you will have to select a platform. You are free to use different platforms for each assignment. In fact, you will likely switch platforms at some point, since the homeworks during the first half of the course will mainly be 2D, and the homeworks in the second half of the course will mainly be 3D.
We encourage you to pick one of the supported platforms listed on this page, but you are free to write your code in any way you like, as long as you meet the requirements for handing in the assignment (and all the course policies, including academic honesty and the use of third-party code). Note that one such requirement will be that you give specific instructions on how to compile and execute your code using only tools available within the CCIS computing environment.
For the purposes of this course, “the CCIS computing environment” is equal to the configuration of the lab machines in 102 WVH (without administrative privileges).
If you really want to write code for a different operating system, or even for a hand-held device, this can be possible in at least two ways. First, you could write portable code that builds and runs correctly on your preferred target as well as on one of the CCIS machines. Or, if an emulator is freely available (e.g. for a hand-held device) and runs on a CCIS machine, then it would suffice to ensure that your program runs correctly within it.
We will try to help you with your code if you use one of the supported platforms. If you use something else, we can only give our best effort to answer questions.
While it is usually possible to use a 3D API even for a 2D application, you will likely find that to be a significantly harder way to do things. One reason is that it is often more complicated to initialize a drawing context in a 3D environment (e.g. in some APIs you may be obligated to do additional thread management). Another reason is that 3D APIs often do not include extended 2D features, such as polygon and path datastructures.
This is a relatively full-featured API for 2D graphics. It is a standard component of the Java Platform, Standard Edition (Java SE). It is supported on GNU/Linux, Windows, and OS X. Sun’s Java2D implementation will use hardware acceleration in many cases, and will default to software rendering otherwise.
This is the standard GUI toolbox included with PLT Scheme. It includes an API for drawing 2D graphics to the screen and other destinations (such as a PostScript file). It is supported on GNU/Linux, Windows, and OS X.
Some homeworks in the second half of the course may call for using a graphics API specifically designed for interactive 3D. This means that the API supports modeling, rendering, and interaction with 3D scenes, and is fast enough on typical computers to render smooth-looking animations (typically this requires at least 10 frames per second, if not more). This is the kind of graphics programming required for most mainstream 3D games and other 3D desktop and workstation applications, including CAD and artistic 3D modeling programs.
[Note that this is not the only kind of 3D graphics programming. There are also cases where speed is not as important, and more time can be taken to render each frame. Or, expensive hardware may be available. One area where this kind of off-line graphics programming is common is in producing high-quality animations for film and television. We will not focus on off-line programming, but many of the algorithms we will cover also apply in that case.]
Returning to interactive 3D, there are currently several major APIs available, including OpenGL and DirectX. These are both native C language APIs, but bindings exist for other languages. Below is a listing of the supported 3D platforms for the course, which are bindings from different languages to OpenGL. We select OpenGL in part because it is more portable (DirectX only runs on Microsoft platforms), and in part because its use in research and industry spans a broader cross-section of application domains. You can read more about the trade-offs here and here.
One important thing to know is that, on most modern desktop and laptop computers, APIs like OpenGL and DirectX are interfaces to specialized graphics acceleration hardware called the Graphics Processing Unit (GPU). Not all computers have a GPU, but it is a standard feature now on all but the least expensive new computers. Some App phones, including the iPhone, also have GPU hardware, though usually not as powerful as in regular computers. Typically, a library implementing OpenGL is provided as a driver by the vendor (e.g. nVidia or ATI) of your graphics hardware (unless you are coding in C, you will still need to install a binding library that makes OpenGL calls available in your programming environment).
If you do not have a GPU, OpenGL will generally still work, with a software renderer (such as Mesa) that uses the CPU (the regular processor in any computer) only. This is generally slower, but modern CPUs are quite fast, and performance can be acceptable. From your standpoint, code can be written exactly the same, whether or not a GPU or software rendering is used under the hood.
[It appears that software rendering may not always be an option with DirectX, which is another reason we focus on OpenGL.]
It is very likely that your computer is already correctly configured with an appropriate OpenGL library. However, if you have problems, you may want to check if you have the most up-to-date library installed for your hardware.
This is a binding of OpenGL 3D for Java. At the time of this writing, it is not a standard component of the Java Platform, and must be downloaded and installed separately. It is supported on GNU/Linux, Windows, and OS X.
PLT SGL is to PLT Scheme as JOGL is to Java. That is, SGL is a set of Scheme-language bindings to OpenGL. (Actually, only a subset of OpenGL 1.5 is provided.) This library is included with PLT Scheme and is supported on GNU/Linux, Windows, and OS X.
OpenGL is now a large API. We can only officially support a subset: the fixed function drawing pipeline available in OpenGL up to version 3.0.
The following references document OpenGL. They are written in terms of OpenGL’s native C-language interface. Bindings like JOGL and PLT SGL adapt the API to the needs of the corresponding language (Java or PLT Scheme), but the underlying functionality of each API call is the same.
There are many libraries available that add layers of functionality on top of OpenGL or DirectX. In Java these include