OpenGL

OpenGL (Open Graphics Library) is a specificatioSpecification

At its most basic level, OpenGL is a specification, meaning it is simply a document that describes a set of functions and the precise behaviours that they must perform. From this specification, hardware vendors create implementations &mdash; 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 (leveraging graphics acceleration hardware to a greater or lesser extent) exist for Windows, Linux, many Unix platforms, the PlayStation 3, and Mac OS X. 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 SGI, 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: 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.
 * Rasterised points, lines and polygons as basic primitives
 * A transform and lighting pipeline
 * Z-buffering
 * Texture mapping
 * Alpha blending

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;                  /* Initialise 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;                  /* Initialise 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
Part of the popularity of OpenGL is 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 0321335732
 * A readable tutorial and reference book - this is a 'must have' book for OpenGL programmers.
 * The Blue Book - The OpenGL Reference manual. ISBN 032117383X
 * Essentially a hard-copy printout of the 'man' pages for OpenGL.
 * Includes a poster-sized fold-out diagram showing the structure of an idealised OpenGL implementation.
 * The Green Book - Programming OpenGL for the X Window System. ISBN 0201483599
 * 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 0201407094
 * A book about interfacing OpenGL to Microsoft Windows.

Then, for OpenGL 2.0 and beyond:


 * The Orange Book - The OpenGL Shading Language. ISBN 0321334892
 * 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  and their constant. 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, 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.

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, 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 is an Open Sourced implementation of OpenGL. It supports pure software rendering as well as providing hadware 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 enforce 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 lists various bindings for Java, Fortran 90, Perl, Pike, Python, Ada, and Visual Basic. Bindings are also available for C++ and C#, see.

Higher level functionality
OpenGL was designed to be output-only: it provides only rendering functions. The core API has no concept of windowing systems, audio, printing, 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. Mac OS 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 analyse 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.

Silicon Graphics Incorporated specializes in the creation of specialized graphics hardware and software. Being the world leader in 3D graphics at the time, SGI naturally saw this hardware interface problem as a barrier to market growth. It therefore sought to standardise and abstract access to hardware. SGI already had a proprietary graphics API called IrisGL which had grown over the life of the company and was starting to show its age.

SGI solved two problems in one by radically cleaning up IrisGL and opening up the standard to other companies. The result is known as OpenGL. OpenGL standardised 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 harkened 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 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).