Next: 2 OpenGL Up: The Design of the Previous: The Design of the

1 Introduction

Computer graphics (especially 3D graphics, and interactive 3D graphics in particular) is finding its way into an increasing number of applications, from simple graphing programs for personal computers to sophisticated modeling and visualization software on workstations and supercomputers. As the interest in computer graphics has grown, so has the desire to be able to write applications that run on a variety of platforms with a range of graphical capabilites. A graphics standard eases this task by eliminating the need to write a distinct graphics driver for each platform on which the application is to run.

To be viable, a graphics standard intended for interactive 3D applications must satisfy several criteria. It must be implementable on platforms with varying graphics capabilities without compromising the graphics performance of the underlying hardware and without sacrificing control over the hardware's operation. It must provide a natural interface that allows a programmer to describe rendering operations tersely. Finally, the interface must be flexible enough to accommodate extensions so that as new graphics operations become significant or available in new graphics subsystems, these operations can be provided without disrupting the original interface.

OpenGL meets these criteria by providing a simple, direct interface to the fundamental operations of 3D graphics rendering. It supports basic graphics primitives such as points, line segments, polygons, and images, as well as basic rendering operations such as affine and projective transformations and lighting calculations. It also supports advanced rendering features such as texture mapping and antialiasing.

There are several other systems that provide an API (Application Programmer's Interface) for effecting graphical rendering. In the case of 2D graphics, the PostScript page description language[5] has become widely accepted, making it relatively easy to electronically exchange, and, to a limited degree, manipulate static documents containing both text and 2D graphics. Besides providing graphical rendering operators, PostScript is also a stack-based programming language.

The X window system[9] has become standard for UNIX workstations. A programmer uses X to obtain a window on a graphics display into which either text or 2D graphics may be drawn; X also provides a means for obtaining user input from such devices as keyboards and mice. The adoption of X by most workstation manufacturers means that a single program can produce 2D graphics or obtain user input on a variety of workstations by simply recompiling the program. This integration even works across a network: the program may run on one workstation but display on and obtain user input from another, even if the workstations on either end of the network are made by different companies.

For 3D graphics, several systems are in use. One relatively well-known system is PHIGS (Programmer's Hierarchical Interactive Graphics System). Based on GKS[6] (Graphics Kernel System), PHIGS is an ANSI (American National Standards Institute) standard. PHIGS (and its descendant, PHIGS+[11]) provides a means to manipulate and draw 3D objects by encapsulating object descriptions and attributes into a display list that is then referenced when the object is displayed or manipulated. One advantage of the display list is that a complex object need be described only once even if it is to be displayed many times. This is especially important if the object to be displayed must be transmitted across a low-bandwidth channel (such as a network). One disadvantage of a display list is that it can require considerable effort to re-specify the object if it is being continually modified as a result of user interaction. Another difficulty with PHIGS and PHIGS+ (and with GKS) is lack of support for advanced rendering features such as texture mapping.

PEX[10] extends X to include the ability to manipulate and draw 3D objects. (PEXlib[7] is an API employing the PEX protocol.) Originally based on PHIGS, PEX allows immediate mode rendering, meaning that objects can be displayed as they are described rather than having to first complete a display list. PEX currently lacks advanced rendering features (although a compatible version that provides such features is under design), and is available only to users of X. Broadly speaking, however, the methods by which graphical objects are described for rendering using PEX (or rather, PEXlib) are similar to those provided by OpenGL.

Like both OpenGL and PEXlib, Renderman[16] is an API that provides a means to render goemetric objects. Unlike these interfaces, however, Renderman provides a programming language (called a shading language) for describing how these objects are to appear when drawn. This programmability allows for generating very realistic-looking images, but it is impractical to implement on most graphics accelerators, making Renderman a poor choice for interactive 3D graphics.

Finally, there are APIs that provide access to 3D rendering as a result of methods for describing higher-level graphical objects. Chief among these are HOOPS[17] and IRIS Inventor[15]. The objects provided by these interfaces are typically more complex than the simple geometry describable with APIs like PEXlib or OpenGL; they may comprise not only geometry but also information about how they are drawn and how they react to user input. HOOPS and Inventor free the programmer from tedious descriptions of individual drawing operations, but simple access to complex objects generally means losing fine control over rendering (or at least making such control difficult). In any case, OpenGL can provide a good base on which to build such higher-level APIs.



Next: 2 OpenGL Up: The Design of the Previous: The Design of the


segal@asd.sgi.com
Fri Sep 23 17:28:42 PDT 1994