ibrary) is a standard specification defining a
applications that produce 2D
and 3D computer graphics
interface consists of over 250 different function calls which can
be used to draw complex three-dimensional scenes from simple
. OpenGL was developed
by Silicon Graphics Inc.
1992 and is widely used in CAD
, virtual reality
, scientific visualization,
information visualization, and flight
. It is also used in video
, where it competes with Direct3D
on Microsoft Windows
(see Direct3D vs.
). OpenGL is managed by the non-profit technology
consortium, the Khronos Group
OpenGL serves two main purposes:
- To hide the complexities of interfacing with different 3D
accelerators, by presenting the programmer with a single, uniform
- 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
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. OpenGL 2.0
offers several stages that 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
) 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:
Simplified version of the Graphics
Pipeline Process; excludes a number of features like blending, VBOs
and logic ops
A brief description of the process in the graphics pipeline could
- Evaluation, if necessary, of the polynomial functions which
define certain inputs, like NURBS surfaces, approximating
curves and the surface geometry.
- Vertex operations, transforming and lighting them depending on
their material. Also clipping non visible parts of the scene in
order to produce the viewing volume.
- Rasterisation or conversion of the
previous information into pixels. The polygons are represented by
the appropriate colour by means of interpolation algorithms.
- Per-fragment operations, like updating values depending on
incoming and previously stored depth values, or colour
combinations, among others.
- Lastly, fragments are inserted into the Frame buffer.
Many modern 3D accelerators provide functionality far above this
baseline, but these new features are generally enhancements of this
basic pipeline rather than radical revisions of it.
This example will draw a green square on the screen. OpenGL has
several ways to accomplish this task, but this is the easiest to
understand. However, the reader should be aware that most of the
APIs used in the code below have been deprecated in and after the
OpenGL 3.0 specification.
glClear( GL_COLOR_BUFFER_BIT );
- This statement clears the color buffer, so that the screen will
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 */
- These statements initialize the projection matrix, setting a 3d
frustum matrix that represents the viewable
area. This matrix transforms objects from camera-relative space to
OpenGL's projection space.
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 */
- These statements initialize the modelview matrix. This matrix
defines a transform from model-relative coordinates to camera
space. The combination of the modelview matrix and the projection
matrix transforms objects from model-relative space to projection
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 */
- These commands draw a green square in the XY plane.
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 – OpenGL Programming Guide, 6th edition. ISBN
- : A readable tutorial and reference book – this is a 'must
have' book for OpenGL programmers. The first edition is available
online here and here.
- The Blue Book – OpenGL Reference manual, 4th edition. ISBN
- : 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. It is available
- The Green Book – OpenGL Programming for the X Window System.
- : 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 – OpenGL Shading Language, 2nd edition. ISBN
- : A readable tutorial and reference book for GLSL.
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
glCombinerParameterfvNV() and their constant
It may happen that more than one vendor agrees to implement the
same extended functionality. In that case, the abbreviation
is used. It may further happen that the Architecture
Review Board "blesses" the extension. It then becomes known as a
, and the abbreviation ARB
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
exist to simplify the
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
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
. Still other libraries like GLAux (OpenGL
Auxiliary Library) are deprecated and have been superseded by
functionality commonly available in more popular libraries, but
code using them still exists, 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
In addition to the aforementioned simple libraries, other higher
level object oriented scene graph retained
libraries exist such as PLIB
and OpenGL Performer
. These are
available as cross platform free/open source or proprietary
written on top of OpenGL and systems libraries to enable the
creation of real-time
simulation applications. Other solutions support parallel OpenGL
programs for Virtual Reality
scalability or graphics clusters usage, either transparently like
or through a
programming interface like Equalizer
is a free/open source implementation
of OpenGL. It supports pure software rendering as well as providing
hardware acceleration for several 3D graphics cards under Linux
. As of June 22, 2007 it implements the 2.1
standard, and provides some of its own extensions for some
In order to emphasize its multi-language and multi-platform
characteristics, various bindings
have been developed for OpenGL in many
languages. Some languages and their bindings are:
- Ada: AdaOpenGL 1.12
supports GL, GLU, GLUT, GLX and WGL and (for OpenGL3) OpenGL3Ada
- BlitzMax: OOP language with no runtime.
Supports Win32/64, Linux, Mac OS X (PowerPC/Intel). Built in OpenGL
- The Open
Toolkit librarycontains OpenGL, OpenAL and OpenCL bindings for
.Net/Mono. Supports Win32/64, Linux and Mac OS X.
- The framework Tao
for Microsoft .NET includes OpenGL
between other multimedia libraries
- D: See bindings
and Project Derelict
- Delphi: Dot
- Eiffel: EiffelOpenGL
- Fortran: f90gl supports
OpenGL 1.2, GLU 1.2 and GLUT 3.7
- FreeBASIC: Native OpenGL support.
Built-in OpenGL context creation.
- Haskell: HOpenGL supports
GL, GLU and GLUT. Included with the latest version of the Glasgow Haskell Compiler.
- Lisp: See the
cl-opengl project at common-lisp.net
- Lua: Doris, LuaGL
- Mercury Prolog
- Ocaml: GLCaml and
- Pike: It has a
OpenGL native interface. Moreover, it supports GLU and GLUT
- PHP: See
- PureBasic: Native OpenGL support.
- Python: PyOpenGL
supports GL, GLU and GLUT
- Ruby: ruby-opengl
- supports GL, GLU and GLUT
- Smalltalk as seen in Croquet Project running on Squeak
- thinBasic - native interface for
OpenGL 2.1, GLU library + language specific higher level
- Visual Basic: ActiveX Control
- Visual Prolog commercial
For more information on OpenGL Language bindings, see opengl.org's Wiki
Higher level functionality
OpenGL was designed to be graphic output-only: it provides only
The core API has no concept of windowing systems
, audio, printing to the
screen, keyboard/mouse or other input
. While this seems restrictive at first, it allows the
code that does the rendering to be completely independent of the
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
and the GLFW
provide functionality for basic windowing using OpenGL, in a
Some open source cross-platform toolkits, such as GTK+
, include widgets to embed OpenGL
In the 1980s, developing software that could function with a wide
range of graphics hardware was a real challenge. Software
developers wrote custom interfaces and drivers for each piece of
hardware. This was expensive and resulted in much duplication of
By the early 1990s, Silicon
(SGI) was a leader in 3D graphics for workstations.
Their IRIS GL
API was considered the state
of the art and became the de facto industry standard, overshadowing
the open standards-based PHIGS
. This was
because IRIS GL was considered easier to use, and because it
supported immediate mode
By contrast, PHIGS
was considered difficult to
use and outdated in terms of functionality.
SGI's competitors (including Sun
) were also able to bring to market 3D
hardware, supported by extensions made to the PHIGS
standard. This in turn caused SGI market share
to weaken as more 3D graphics hardware suppliers entered the
market. In an effort to influence the market, SGI decided to turn
the IrisGL API into an open standard.
SGI considered that the IrisGL API itself wasn't suitable for
opening due to licensing and patent issues. Also, the IrisGL had
API functions that were not relevant to 3D graphics. For example,
it included a windowing, keyboard and mouse API, in part because it
was developed before the X Window
and Sun's NeWS
In addition, SGI had a large number of software customers; by
changing to the OpenGL API they planned to keep their customers
locked onto SGI (and IBM) hardware for a few years while market
support for OpenGL matured. Meanwhile, SGI would continue to try to
maintain their customers tied to SGI hardware by developing the
advanced and proprietary Iris Inventor
and Iris Performer
As a result, SGI released the OpenGL
The OpenGL standardised access to hardware, and pushed the
development responsibility of hardware interface programs,
sometimes called device drivers
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,
. 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
In 1994 SGI played with the idea of releasing something called
" which included elements such as
a scene-graph API (presumably based around their Performer
specification was circulated among a few interested parties – but
never turned into a product.
in 1995, which would become the main
competitor of OpenGL. On 17 December 1997, Microsoft and SGI
initiated the Fahrenheit
project, which was a joint effort with the goal of unifying the
OpenGL and Direct3D interfaces (and adding a scene-graph API too).
In 1998 Hewlett-Packard joined the project. 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, strategic reasons at Microsoft, and general lack of industry
support, it was abandoned in 1999.
OpenGL 2.0 was conceived by 3Dlabs
concerns that OpenGL was stagnating and lacked a strong direction.
3Dlabs proposed a number of major additions to the standard. Most
of these were, at the time, rejected by the ARB or otherwise never
came to fruition in the form that 3Dlabs proposed. However, their
proposal for a C
shading language was eventually completed, resulting in the current
formulation of GLSL
anguage, also sl
ang). Like the
assembly-like shading languages that it was replacing, it allowed
the programmer to replace the fixed-function vertex and fragment
pipe with shaders
, though this time written
in a C-like high-level language.
The design of 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 includes support for GLSL.
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 (GLSL)
- 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
- : This functionality corresponds to the
- sRGB texture formats.
- : This functionality corresponds to the
Revision 3.0 of the OpenGL API was released on August 11, 2008 and
is backward compatible with all prior OpenGL versions, though a
deprecation mechanism has been introduced to simplify the API in
- OpenGL Shading Language revision 1.30 (GLSL)
- Vertex Array Objects
- More flexible Framebuffer Objects
- 32-bit (single precision)
floating-point textures and render buffers
- 16-bit (half precision)
floating-point vertex and pixel data
- Ability to render vertex transformations into a buffer
- Texture arrays
- 32-bit (single precision) floating point depth buffer
Full use of OpenGL 3.0 requires the same level of hardware as is
required for DirectX 10 support. Unlike DirectX 10, OpenGL 3.0 does
not require Windows Vista and can be used on any OS for which the
appropriate drivers are provided.
Longs Peak and OpenGL 3.0 controversy
the release of OpenGL 3.0 the new revision was known as the
At the time of its original announcement
Longs Peak was presented as the first major API revision in
OpenGL's lifetime. It consisted of an overhaul to the way that
OpenGL works, calling for fundamental changes to the API.
The draft introduced a change to object management. The GL 2.1
object model was built upon the state-based design of OpenGL. That
is, in order to modify an object or to use it, one needs to bind
the object to the state system, then make modifications to the
state or perform function calls that use the bound object.
Because of OpenGL's use of a state system, objects must be mutable.
That is, the basic structure of an object can change at any time,
even if the rendering pipeline is asynchronously using that object.
A texture object can be redefined from 2D to 3D. This requires any
OpenGL implementations to add a degree of complexity to internal
Under the Longs Peak API object creation would become atomic, using
templates to define the properties of an object which would be
created with a single function call. The object could then be used
immediately across multiple threads. Objects would also be
immutable; however, they could have their contents changed and
updated. For example, a texture could change its image, but its
size and format could not be changed.
To support backwards compatibility the old state based API would
still be available, but no new functionality would be exposed via
the old API in later versions of OpenGL. This would have allowed
legacy code bases, such as the majority of CAD
products, to continue to run while
other software could be written against or ported to the new
Longs Peak was initially due to be finalized in September 2007
under the name OpenGL 3.0, but the Khronos group announced October
30 that it had run into several issues that it wished to address
before releasing the specification. As a result the spec was
delayed, and the Khronos group went into a media blackout
until the release of the final
OpenGL 3.0 spec.
The final specification proved far less revolutionary than the
Longs Peak proposal. Instead of removing all immediate mode and
fixed functionality (non-shader mode), the spec included them as
deprecated features. The proposed object model was not included,
and no plans have been announced to include it in any future
revisions. As a result the API remained largely the same with a few
existing extensions being promoted to core functionality.
Among some developer groups this decision caused something of an
uproar , with many developers professing that they would switch to
in protest. Most complaints revolved
around the lack of communication by Khronos to the development
community and multiple features being discarded that were viewed
favorably by many. Other frustrations included the requirement of
DirectX 10 level hardware in order to use OpenGL 3.0 and the
absence of geometry shaders and instanced rendering as core
Other sources reported that the community reaction wasn't quite as
severe as originally presented , with many vendors showing support
for the update.
Revision 3.1 was released on March 24 2009 and introduces a range
of features to make the API more convenient to use, in addition to
performance oriented features:
- OpenGL Shading Language revision 1.40 (GLSL)
- Texture Buffer Objects - a new texture type that holds a
one-dimensional array of texels
- Uniform Buffer Objects for fast data share/update
- Signed normalized textures (±1.0 range)
- A minimum of 16 texture units accessible by the vertex
- Primitive restart
- Instancing - drawing of objects multiple times through the
re-use of vertex data
- CopyBuffer API for fast data copy; used in conjunction with
With the release of the OpenGL 3.1 specification, a compatibility
extension that enables developers to access the OpenGL 1.X/2.X
functionality removed in OpenGL 3.1 was also released. Notably,
legacy functionality for wide line support is retained.
Removed legacy functionality includes:
- All fixed-function options
- Direct mode
- Color index mode, i.e. pixel
formats with color palettes
Revision 3.2 was released on August 3, 2009.It includes the
- OpenGL Shading Language revision 1.50 (GLSL)
- Geometry Shader support
- BGRA vertex component ordering
- Shader Fragment coordinate convention control
- Seamless cube map filtering
- Fragment depth clamping
- Multisampled textures and texture samples for specific sample
- Sync and Fence objects
Image:JOGL Refrection Demo Screenshot.png|Refraction using
programmable vertex shadersImage:Perl OpenGL fob2.jpg|Animated
textures using framebuffer objects and vertex/fragment program
artwork using display lists
OpenGL support libraries
- GLUT – The OpenGL utility
- SDL – The Simple
- GLU – Some additional
functions for OpenGL programs.
- GLee - The OpenGL
Easy Extension library.
- GLEW – The
OpenGL Extension Wrangler Library.
- GLUI - a GUI toolkit made with GLUT
- GLFW - a portable framework for
OpenGL application development.
- GLM - C++ mathematics toolkit
for OpenGL based on the GLSL specification.
- SFML - Simple
and Fast Multimedia Library.
- Glux -
The OpenGL Utility & Auxiliary Library.
Other 3D graphics APIs
Other 2D graphics APIs
- Cairo - a cross platform
graphical vectorial draw and text toolkit.
- GTK+ - a cross platform graphical widget
- Java2d - a cross platform API for drawing
- Qt - a cross platform graphical
- wxWidgets - a cross platform graphical
All can incorporate OpenGL 3D objects. Cairo, Java2D and Qt can use
OpenGL as backend.
- Richard S. Wright, Benjamin Lipchak, Nicholas Haemel:
OpenGL SuperBible: Comprehensive Tutorial and Reference, 4th
Edition, Addison-Wesley, June 18 2007, ISBN 0-321-49882-8
- Dave Shreiner, Mason Woo, Jackie Neider, Tom Davis: OpenGL
Programming Guide: The Official Guide to Learning OpenGL, Version
2.1, 6th Edition, Addison-Wesley, July 30 2007, ISBN
- Fosner, Ron: OpenGL Programming for Windows 95 and Windows
NT, Addison Wesley, ISBN 0-201-40709-4
- Kilgard, Mark: OpenGL for the X
Window System, Addison-Wesley, ISBN 0-201-48359-9
- Lengyel, Eric: The OpenGL
Extensions Guide, Charles River Media, ISBN 1-58450-294-0
- OpenGL Architecture
Review Board, et al.: OpenGL Reference Manual: The Official
Reference Document to OpenGL, Version 1.4, Addison-Wesley,
- OpenGL Architecture
Review Board, et al.: OpenGL Programming Guide: The
Official Guide to Learning OpenGL, Version 2, Fifth Edition,
Addison-Wesley, ISBN 0-321-33573-2
- Rost, Randi J.: OpenGL
Shading Language, Addison-Wesley, ISBN 0-321-19789-5