Page 84 - Computer Graphics Handout

SUMMARY AND NOTES

In this chapter, we introduced just enough of the OpenGL API to apply the basic concepts that we learned in Chapter 1. Although
the first application we used to develop our first program was two dimensional, we took the path of looking at two-dimensional
graphics as a special case of three-dimensional graphics. We then were able to extend the example to three dimensions with minimal
work. The Sierpinski gasket provides a nontrivial beginning application. A few extensions and mathematical issues are presented in
the exercises at the end of this chapter. The texts in the Suggested Readings section provide many other examples of interesting
curves and surfaces that can be generated with simple programs.
The historical development of graphics APIs and graphical models illustrates the importance of starting in three dimensions. The
pen-plotter model from Chapter 1 was used for many years and is the basis of many important APIs, such as PostScript. Work to
define an international standard for graphics APIs began in the 1970s and culminated with the adoption of GKS by the International
Standards Organization (ISO) in 1984. However, GKS had its basis in the pen-plotter model and as a two-dimensional API was of
limited utility in the CAD community. Although the standard was extended to three dimensions with GKS-3D, the limitations imposed
by the original underlying model led to a standard that was lacking in many aspects. The PHIGS and PHIGS+ APIs, started in the CAD
community, are inherently three dimensional and are based on the synthetic-camera model.
OpenGL is derived from the IrisGL API, which is based on implementing the synthetic-camera model with a pipeline architecture.
IrisGL was developed for Silicon Graphics, Inc. (SGI) workstations, which incorporated a pipeline architecture originally implemented
with special-purpose VLSI chips. Hence, although PHIGS and GL have much in common, GL was designed specifically for high-speed
realtime rendering. OpenGL was a result of application users realizing the advantages of GL programming and wanting to carry these
advantages to other platforms. Because it removed input and windowing functions from GL and concentrated on rendering, OpenGL
emerged as a new API that was portable while retaining the features that make GL such a powerful API.
Although most application programmers who use OpenGL prefer to program in C, there is a fair amount of interest in higher-level
interfaces. Using C++ rather than C requires minimal code changes but does not provide a true object-oriented interface to OpenGL.
Among object-oriented programmers, there has been much interest in both OpenGL and higher-level APIs. Although there is no
official Java binding to OpenGL, there have been multiple efforts to come up with one. The problem is not simple, because
application users want to make use of the object orientation of Java and various Java toolkits, together with a non–object-oriented
OpenGL specification. There are a few bindings available on the Internet, and Sun Microsystems recently released their Java
bindings. Many Java programmers use the JOGL bindings.
In Chapter 8, we will introduce scene graphs, which provide amuch higher-level, object-oriented interface to graphics hardware.
Most scene graph APIs are built on top of OpenGL.
Within the game community, the dominance of Windows makes it possible for game developers to write code for a single platform.
DirectX runs only on Windows platforms and is optimized for speed on these systems. Although much DirectX code looks like OpenGL
code, the coder can use device-dependent features that are available in commodity graphics cards. Consequently, applications
written in DirectX do not have the portability and stability of OpenGL applications. Thus, we see DirectX dominating the game world,
whereas scientific and engineering applications generally are written in OpenGL. For OpenGL programmers who want to use features
specific to certain hardware, OpenGL has an extension mechanism for accessing these features but at the cost of portability.
Programming pipelines that are accessible through the OpenGL Shading Language and Cg are leading to small performance
differences between OpenGL and DirectX for high-end applications.
Our examples and programs have shown how we describe and display geometric objects in a simple manner. In terms of the
modeling–rendering paradigm that we presented in Chapter 1, we have focused on the modeling. However, our models are
completely unstructured. Representations of objects are lists of vertices and attributes. In Chapter 8, we will learn to construct
hierarchical models that can represent relationships among objects. Nevertheless, at this point, you should be able to write
interesting programs. Complete the exercises at the end of the chapter and extend a few of the two-dimensional problems to three
dimensions.

84