X Window Programming/OpenGL

Introduction

OpenGL (Open Graphics Library) is a standard specification defining a cross-language cross-platform API for writing applications that produce 3D computer graphics (and 2D computer graphics as well). The interface consists of over 250 different function calls which can be used to draw complex three-dimensional scenes from simple primitives. OpenGL was developed by Silicon Graphics and is popular in the video games industry, where it competes with Direct3D on Microsoft Windows platforms. OpenGL is widely used in computer-aided design, virtual reality, scientific visualization, information visualization, flight simulation, and video game development.

Specification

At its most basic level, OpenGL is a specification, meaning it is simply a document that describes a set of functions and the precise behaviors that they must perform. From this specification, hardware vendors create implementations — libraries of functions created to match the functions stated in the OpenGL specification, making use of hardware acceleration where possible. Hardware vendors have to meet specific tests to be able to qualify their implementation as an OpenGL implementation.

Efficient vendor-supplied implementations of OpenGL (making use of graphics acceleration hardware to a greater or lesser extent) exist for Mac OS, Microsoft Windows, Linux, many Unix platforms, Wii and PlayStation 3. Various software implementations exist, bringing OpenGL to a variety of platforms that do not have vendor support. Notably, the open source library Mesa is a fully software-based graphics API which is code-compatible with OpenGL. However to avoid licensing costs associated with formally calling itself an OpenGL implementation, it claims merely to be a "very similar" API.

The OpenGL specification is currently overseen by the OpenGL Architecture Review Board (ARB), which was formed in 1992. The ARB consists of a set of companies with a vested interest in creating a consistent and widely available API. Voting members of the ARB as of April 2006 include 3D hardware manufacturers Silicon Graphics, 3Dlabs, ATI Technologies, NVIDIA and Intel, and computer manufacturers IBM, Apple Computer, Dell, and Sun Microsystems. Microsoft, one of the founding members, left in March 2003. Aside from these corporations, each year many other companies are invited to be part of the OpenGL ARB for one-year terms. With so many companies involved with such a diverse set of interests, OpenGL has become very much a general-purpose API with a wide range of capabilities.

According to current plans, control of OpenGL will pass to the Khronos Group by the end of 2006. This is being done in order to improve the marketing of OpenGL, and to remove barriers between the development of OpenGL and OpenGL ES.

Kurt Akeley and Mark Segal authored the original OpenGL specification. Chris Frazier edited version 1.1. Jon Leech edited versions 1.2 through the present version 2.0.

Design

OpenGL serves two main purposes:

• To hide the complexities of interfacing with different 3D accelerators, by presenting the programmer with a single, uniform API.
• To hide the differing capabilities of hardware platforms, by requiring that all implementations support the full OpenGL feature set (using software emulation if necessary).

OpenGL's basic operation is to accept primitives such as points, lines and polygons, and convert them into pixels. This is done by a graphics pipeline known as the OpenGL state machine. Most OpenGL commands either issue primitives to the graphics pipeline, or configure how the pipeline processes these primitives. Prior to the introduction of OpenGL 2.0, each stage of the pipeline performed a fixed function and was configurable only within tight limits but in OpenGL 2.0 several stages are fully programmable using GLSL.

OpenGL is a low-level, procedural API, requiring the programmer to dictate the exact steps required to render a scene. This contrasts with descriptive (aka scene graph or retained mode) APIs, where a programmer only needs to describe a scene and can let the library manage the details of rendering it. OpenGL's low-level design requires programmers to have a good knowledge of the graphics pipeline, but also gives a certain amount of freedom to implement novel rendering algorithms.

OpenGL has historically been influential on the development of 3D accelerators, promoting a base level of functionality that is now common in consumer-level hardware:

• Rasterised points, lines and polygons as basic primitives
• A transform and lighting pipeline
• Z-buffering
• Texture mapping
• Alpha blending

Many modern 3D accelerators provide functionality far above this baseline, but these new features are generally enhancements of this basic pipeline rather than radical reinventions of it.

Example

We first clear the color buffer, in order to start with a blank canvas:

glClear( GL_COLOR_BUFFER_BIT );

We now set the modelview matrix, which controls the position of the camera relative to the primitives we render. We move it backwards 3 units along the Z axis, which leaves it pointing towards the origin:

glMatrixMode( GL_MODELVIEW );       /* Subsequent matrix commands will affect the modelview matrix */
glLoadIdentity();                   /* Initialize the modelview to identity */
glTranslatef( 0, 0, -3 );           /* Translate the modelview 3 units along the Z axis */

The projection matrix governs the perspective effect applied to primitives, and is controlled in a similar way to the modelview matrix:

glMatrixMode( GL_PROJECTION );      /* Subsequent matrix commands will affect the projection matrix */
glLoadIdentity();                   /* Initialize the projection matrix to identity */
glFrustum( -1, 1, -1, 1, 1, 1000 ); /* Apply a perspective-projection matrix */

Finally, we issue a polygon - a green square oriented in the XY plane:

glBegin( GL_POLYGON );              /* Begin issuing a polygon */
glColor3f( 0, 1, 0 );               /* Set the current color to green */
glVertex3f( -1, -1, 0 );            /* Issue a vertex */
glVertex3f( -1, 1, 0 );             /* Issue a vertex */
glVertex3f( 1, 1, 0 );              /* Issue a vertex */
glVertex3f( 1, -1, 0 );             /* Issue a vertex */
glEnd();                            /* Finish issuing the polygon */

Documentation

OpenGL's popularity is partially due to the excellence of its official documentation. The OpenGL ARB released a series of manuals along with the specification which have been updated to track changes in the API. These are almost universally known by the colors of their covers:

• The Red Book - The OpenGL Programmer's guide. ISBN 0-321-33573-2

  A readable tutorial and reference book - this is a 'must have' book for OpenGL programmers.

• The Blue Book - The OpenGL Reference manual. ISBN 0-321-17383-X

  Essentially a hard-copy printout of the man pages for OpenGL.

  Includes a poster-sized fold-out diagram showing the structure of an idealized OpenGL implementation.

• The Green Book - Programming OpenGL for the X Window System. ISBN 0-201-48359-9

  A book about X11 interfacing and GLUT.

• The Alpha Book (which actually has a white cover) - OpenGL Programming for Windows 95 and Windows NT. ISBN 0-201-40709-4

  A book about interfacing OpenGL with Microsoft Windows.

Then, for OpenGL 2.0 and beyond:

• The Orange Book - The OpenGL Shading Language. ISBN 0-321-33489-2

  A readable tutorial and reference book for GLSL.

Extensions

The OpenGL standard allows individual vendors to provide additional functionality through extensions as new technology is created. Extensions may introduce new functions and new constants, and may relax or remove restrictions on existing OpenGL functions. Each vendor has an alphabetic abbreviation that is used in naming their new functions and constants. For example, NVIDIA's abbreviation (NV) is used in defining their proprietary function glCombinerParameterfvNV() and their constant GL_NORMAL_MAP_NV. It may happen that more than one vendor agrees to implement the same extended functionality. In that case, the abbreviation EXT is used. It may further happen that the Architecture Review Board "blesses" the extension. It then becomes known as a standard extension, and the abbreviation ARB is used. The first ARB extension was GL_ARB_multitexture, introduced in version 1.2.1. Following the official extension promotion path, multitexturing is no longer an optionally implemented ARB extension, but has been a part of the OpenGL core API since version 1.3.

Before using an extension a program must first determine its availability, and then obtain pointers to any new functions the extension defines. The mechanism for doing this is platform-specific and libraries such as GLEW and GLEE exist to simplify the process.

Specifications for nearly all extensions can be found at the official extension registry [1].

Associated utility libraries

Several libraries are built on top of or beside OpenGL to provide features not available in OpenGL itself. Libraries such as GLU can always be found with OpenGL implementations, and others such as GLUT and SDL have grown over time and provide rudimentary cross platform windowing and mouse functionality and if unavailable can easily be downloaded and added to a development environment. Simple graphical user interface functionality can be found in libraries like GLUI or FLTK. Still others libraries like AUX are deprecated libraries that have been superseded by functionality commonly available in more popular libraries, but code still exists out there particularly in simple tutorials. Other libraries have been created to provide OpenGL application developers a simple means of managing OpenGL extensions and versioning, examples of these libraries include GLEW "The OpenGL Extension Wrangler Library" and GLEE "The OpenGL Easy Extension library".

In addition to the aforementioned simple libraries other higher level object oriented scene graph retained mode libraries exist such as PLIB, OpenSG, OpenSceneGraph, and OpenGL Performer, these are available as cross platform Open Source or proprietary programming interfaces written on top of OpenGL and systems libraries to enable the creation of real-time visual simulation applications.

Mesa 3D ([2]) is an Open Sourced implementation of OpenGL. It supports pure software rendering as well as providing hardware acceleration for several 3D graphics cards under Linux. As of February 2 2006 it implements the 1.5 standard, and provides some of its own extensions for some platforms.

Bindings

In order to emphasize its multi-language and multi-platform characteristics, various bindings and ports have been developed for OpenGL in many languages. Most notably, the Java 3D library can rely on OpenGL for its hardware acceleration. Direct bindings are also available like the Lightweight Java Game Library which has a direct binding of OpenGL for Java and other game related components. Very recently, Sun has released beta versions of the JOGL system, which provides direct bindings to C OpenGL commands, unlike Java 3D which does not provide such low level support. The OpenGL official page [3] lists various bindings for Java, Fortran 90, Perl, Pike, Python, Ada, Delphi and Visual Basic. Bindings are also available for C++ and C#, see [4].

Higher level functionality

OpenGL was designed to be graphic output-only: it provides only rendering functions. The core API has no concept of windowing systems, audio, printing to the screen, keyboard/mouse or other input devices. While this seems restrictive at first, it allows the code that does the rendering to be completely independent of the operating system it is running on, allowing cross-platform development. However some integration with the native windowing system is required to allow clean interaction with the host system. This is performed through the following add-on APIs:

• GLX - X11 (including network transparency)
• WGL - Microsoft Windows

Additionally the GLUT and SDL libraries provide functionality for basic windowing using OpenGL, in a portable manner. MacOS X has three APIs to get OpenGL support: AGL for Carbon, NSOpenGL for Cocoa and CGL for lower-level access.

History

Today the digital generation of animated scenes in three dimensions is a regular fixture in everyday life. Scientists utilize computer graphics to analyze simulations of every possibility. Engineers and architects design virtual models using computer graphics. Movies employ computer graphics to create stunning special effects or entire animated films. And over the past few years, computer games have brought computer graphics technology to regular consumers, using graphics to bring their players into worlds that could never exist.

Bringing digital graphics technology to such widespread use was not without its challenges. Fifteen years ago, developing software that could function with a wide range of graphics hardware and all of their different interfaces was time consuming. Each team of programmers developed interfaces separately, and there was consequently much duplicated code. This was hindering the growing industry of computer graphics.

By the early 1990's SGI, a leader in 3D graphics, and its programming API, IrisGL, had become a defacto industry standard, over-shadowing the open-standards-based PHIGS. The IrisGL programming interface (API) was elegant, easy-to-use, and, importantly, supported immediate-mode rendering. By contrast, PHIGS was clunky, hard to use, and was several generations behind IrisGL in function and capability, primarily due to the dysfunctional PHIGS standardization process. None-the-less, competing vendors, including Sun Microsystems, Hewlett-Packard and IBM were able to bring to market credible 3D hardware, supported by proprietary extensions to PHIGS. By the early 90's, 3D graphics hardware technology was fairly well understood by a large number of competitors and was no longer a discriminating factor in computer systems purchases. Thus, rather than prolonging a contentious and dangerous fight between IrisGL and PHIGS, SGI sought to turn a defacto standard into a true open standard.

The IrisGL API itself wasn't suitable for opening (although it had been previously licensed to IBM and others), in part because it had accumulated cruft over the years. For example, it included a windowing, keyboard and mouse API, in part because it was developed before the X11 Window System versus Sun's NeWS battle had resolved. Thus, the API to be opened needed to be cleaned up. In addition, IrisGL had a large software vendor (ISV) portfolio; the change to the OpenGL API would keep ISV's locked onto SGI (and IBM) hardware for a few years while market support for OpenGL matured. Meanwhile, SGI would continue to try to maintain a vendor lock by pushing the higher-level and proprietary Iris Inventor and Iris Performer programming API's.

The result is known as OpenGL. OpenGL standardized access to hardware, and pushed the development responsibility of hardware interface programs, sometimes called device drivers, to hardware manufacturers and delegated windowing functions to the underlying operating system. With so many different kinds of graphic hardware, getting them all to speak the same language in this way had a remarkable impact by giving software developers a higher level platform for 3D-software development.

In 1992, SGI led the creation of the OpenGL architectural review board (OpenGL ARB), the group of companies that would maintain and expand the OpenGL specification for years to come. OpenGL evolved from (and is very similar in style to) SGI's earlier 3D interface, IrisGL. One of the restrictions of IrisGL was that it only provided access to features supported by the underlying hardware. If the graphics hardware did not support a feature, then the application could not use it. OpenGL overcame this problem by providing support in software for features unsupported by hardware, allowing applications to use advanced graphics on relatively low-powered systems.

In 1994 SGI played with the idea of releasing something called "OpenGL++" which included elements such as a scene-graph API (presumably based around their Performer technology). The specification was circulated among a few interested parties - but never turned into a product.

When Direct3D was released in 1995, Microsoft, SGI, and Hewlett-Packard initiated the Fahrenheit project, which was a joint effort with the goal of unifying the OpenGL and Direct3D interfaces - and again, adding a scene-graph API. It initially showed some promise of bringing order to the world of interactive 3D computer graphics APIs, but on account of financial constraints at SGI and general lack of industry support it was abandoned. The engineers involved at SGI held a beach party in celebration - complete with bonfires on which they burned piles of Fahrenheit documentation.

OpenGL 2.0

OpenGL 2.0 was conceived by 3Dlabs to address concerns that OpenGL was stagnating and lacked a strong direction. 3Dlabs proposed a number of major additions to the standard, the most significant of which was GLSL (the OpenGL Shading Language, also slang). This would enable the programmer to replace the OpenGL fixed-function vertex and fragment pipelines with shaders written in a C-like language, massively expanding the range of graphical effects possible. GLSL was notable for making relatively few concessions to the limitations of the hardware then available; this hearkened back to the earlier tradition of OpenGL setting an ambitious, forward-looking target for 3D accelerators rather than merely tracking the state of currently available hardware. The final OpenGL 2.0 specification [5] includes support for GLSL, but omits many of the other features originally proposed which were deferred to later versions of OpenGL (although many are now available as extensions).

OpenGL 2.1

OpenGL 2.1 was released on August 2, 2006 and is backward compatible with all prior OpenGL versions. OpenGL 2.1 incorporates the following functionality:

• OpenGL Shading Language revision 1.20
• Commands to specify and query non-square matrix uniforms for use with the OpenGL Shading Language
• Pixel buffer objects for efficient image transfers to and from buffer objects for commands such as glTexImage2D and glReadPixels.

  This functionality corresponds to the ARB_pixel_buffer_object extension.

• sRGB texture formats.

  This functionality corresponds to the EXT_texture_sRGB extension.

OpenGL support libraries

• GLUT - The OpenGL utility toolkit.
• GLU - Some additional functions for OpenGL programs.
• GLEW - The OpenGL Extension Wrangler Library.