Jump to content

OpenGL: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Dlae (talk | contribs)
3,215 edits
Undid revision 168973849 by 69.65.224.6 (talk)
Line 122: Line 122:
**[[Lightweight Java Game Library]] (LWJGL)
**[[Lightweight Java Game Library]] (LWJGL)
*[[Lisp (programming language)|Lisp]]: See [http://www.agentsheets.com/lisp/OpenGL.html OpenGL for Common Lisp]
*[[Lisp (programming language)|Lisp]]: See [http://www.agentsheets.com/lisp/OpenGL.html OpenGL for Common Lisp]
*[[Scheme (programming language)|Scheme]]: Chicken scheme has a binding, possibly other implementations as well
*[[Mercury (programming language)|Mercury]] Prolog mtogl
*[[Mercury (programming language)|Mercury]] Prolog mtogl
*[[Perl]]:
*[[Perl]]:

Revision as of 06:32, 4 November 2007

OpenGL
Developer(s)Silicon Graphics
Stable release
Operating systemCross-platform
TypeAPI
LicenseVarious
Websiteopengl.org

OpenGL (Open Graphics Library) is a standard specification defining a cross-language cross-platform API for writing applications that produce 2D and 3D computer graphics. 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 Inc. (SGI) in 1992[1] and is widely used in CAD, virtual reality, scientific visualization, information visualization, flight simulation. It is also used in video games, where it competes with Direct3D on Microsoft Windows platforms (see Direct3D vs. OpenGL).

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 behaviours 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, Windows, Linux, many Unix platforms, and PlayStation 3. Various software implementations exist, bringing OpenGL to a variety of platforms that do not have vendor support. Notably, the free software/open source library Mesa 3D 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 was revised by OpenGL Architecture Review Board (ARB) founded in 1992. The ARB was formed by a set of companies interested in the creation of a consistent and widely available API. Microsoft, one of the founding members, left the project in 2003.

On 21 September 2006, control of OpenGL passed to the Khronos Group.[2] This was done in order to improve the marketing of OpenGL, and to remove barriers between the development of OpenGL and OpenGL ES.[3] The subgroup of Khronos that manages OpenGL was called the OpenGL ARB Working Group,[4] for historical reasons. There is a list of members which make up the OpenGL ARB Working Group at section Members of Khronos Group. OpenGL is a general purpose API with lots of different possibilities because of the great number of companies with different interests which have made up the old ARB and the current group too.

Mark Segal and Kurt Akeley authored the original OpenGL specification. Chris Frazier edited version 1.1. Jon Leech edited versions 1.2 through the present version 2.1. Jon Leech has retired as secretary of the old ARB, and Barthold Lichtenbelt has taken his place as Khronos OpenGL ARB Steering Group Chair.

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. 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 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
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 be:[5]

  1. Evaluation, if necessary, of the polynomial functions which define certain inputs, like NURBS surfaces, approximating curves and the surface geometry.
  2. 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.
  3. Rasterisation or conversion of the previous information into pixels. The polygons are represented by the appropriate colour by means of interpolation algorithms.
  4. Per-fragment operations, like updating values depending on incoming and previously stored depth values, or colour combinations, among others.
  5. At last, 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 reinventions of it.

Example

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. 

glClear( GL_COLOR_BUFFER_BIT );
This statement clears the color buffer, so that the screen will start blank.
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 screen space.
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.

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 – OpenGL Programming Guide, 5th edition. ISBN 0-321-33573-2
    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 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 idealised OpenGL implementation. It is available here .
  • The Green Book – OpenGL Programming 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 other libraries like AUX 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 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 free/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 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 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. Some languages and their bindings are:

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 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:

Additionally the GLUT and SDL libraries provide functionality for basic windowing using OpenGL, in a portable manner.

History

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 effort.

By the early 1990s, Silicon Graphics (SGI) was a leader in 3D graphics for workstations. Their IRIS GL API[6] 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 rendering. By contrast, PHIGS was considered difficult to use and outdated in terms of functionality.

SGI's competitors (including Sun Microsystems, Hewlett-Packard and IBM) 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 System and Sun's NeWS systems were developed.

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 programming APIs.

As a result, SGI released the OpenGL standard.

The 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,[7] 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.[8]

Microsoft released Direct3D in 1995, which would become the main competitor of OpenGL. On 17 December, 1997[9], 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.[10] 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.[11]

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. 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-style shading language was eventually completed, resulting in the current formulation of GLSL (the OpenGL Shading Language, also slang). 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 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 [10] includes support for GLSL.

OpenGL 2.1

OpenGL 2.1 was released on August 2 2006 and is backward compatible with all prior OpenGL versions.[12] 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 glReadPixels.
    This functionality corresponds to the ARB_pixel_buffer_object extension.
  • sRGB texture formats.
    This functionality corresponds to the EXT_texture_sRGB extension.

OpenGL 3.0

Template:Future software

The newest revision of the OpenGL API will be OpenGL 3.0, formerly known as the codename Longs Peak. It was initially due to be finalized in September 2007, but the Khronos group announced October 30 that it had run into several issues that it wished to address before the release and is currently re-evaluating the specification.[13] As a result the spec will likely not be available until the very end of 2007 or even the beginning of 2008.

OpenGL 3.0 represents the first major API revision in OpenGL's lifetime. It consists of a refactoring of the way that OpenGL works, from the object model to shaders. To support backwards compatibility, all of the old API will still be available. However, no new functionality will be exposed via the old API in later versions of OpenGL.

OpenGL 3.0 fundamentally changes the API in virtually every way. Any fixed functionality that OpenGL 2.1 also provided a shader interface for has been removed in favor of a shader-only approach. The API has been streamlined, designed to both simplify application development and ease the burden on implementations.

The biggest change from an API perspective is the reliance on objects. 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 needed to bind the object to the state system, then make modifications to the state or perform function calls that use the bound object. This made it difficult for OpenGL implementations to know when an object was being bound for use or for modification.

Also, because the legacy of the object model was the OpenGL state system, objects had to be mutable. That is, the basic structure of an object could change at any time, even if the rendering pipeline was asynchronously using that object. A texture object could be redefined from 2D to 3D. This required that implementations be able to orphan the internal objects themselves, which added a degree of complexity to internal object management.

The new 3.0 object model does away with both of these issues. Objects, once created, are basically immutable. A 2D texture is a 2D texture object of a set resolution and format forever, though it can be destroyed or have its texture contents updated with new image data.

This requires changing a substantial portion of the OpenGL API. This change, centered around the new object model, represents a shift away from a state-based system and to an object-based system.[14]

Object creation becomes atomic; a single function call creates a fully formed object. Object sharing across rendering contexts is specified at the per-object level; this allows the implementation the ability to use thread-safe function calls for those objects.[15] Atomic object creation is achieved by creating a template object of a particular type.[16] Template objects are similar to structs in C, except they can be extended with additional fields without recompiling. Attributes are set in the template object, just as fields in a struct can be set. The template object is then passed to an appropriate object creation function for that particular template object type.

Object creation is also asynchronous.[17] The implementation is allowed to begin creation of the object in another thread. The handle to the object remains valid even if the object has not finished being created. Rendering can occur with objects that have not yet been created, since OpenGL rendering is already an asynchronous process.

For functions that are used to modify the flexible portion of immutable object, for example the contents of an image, the functions take the object as a parameter. This is as opposed to the GL 2.1 style where the object must be bound to the context if it is to be modified or queried. Objects are still bound to the context in order to be used for rendering.

Post OpenGL 3.0

Template:Future software

There are plans to add more functionality to OpenGL beyond GL 3.0.

Longs Peak Reloaded

This revision, due to be released 2-3 months after 3.0, will entail adding smaller features to 3.0 that could not be added in the timeframe for 3.0's release. They are mostly ease-of-use features that make the API more convenient to use, though a few features for performance purposes also exist.

Mt Evans

This revision, due to be released 3-5 months after 3.0, brings OpenGL 3.0 up-to-date with more modern hardware features. These include geometry shaders, integers in shaders, texture arrays, and instanced rendering.

Members of Khronos Group

In 2006, some of the OpenGL ARB Working Group were:

For a complete and updated list of the project's members see the promoters, contributors and academics member list of the Khronos Group.

Sample renderings

  • Refraction using programmable vertex shaders
    Refraction using programmable vertex shaders
  • Animated textures in Perl OpenGL using framebuffer objects and vertex/fragment program extensions
    Animated textures in Perl OpenGL using framebuffer objects and vertex/fragment program extensions

OpenGL Games

Some notable games with OpenGL renderer include:

See also

Wikibooks has a book on the topic of: Programming:OpenGL

OpenGL support libraries

  • GLUT – The OpenGL utility toolkit.
  • SDL – The Simple DirectMedia Layer.
  • GLU – Some additional functions for OpenGL programs.
  • GLEW – The OpenGL Extension Wrangler Library.
  • GLUI - a GUI toolkit made with GLUT

Other graphics APIs

References

  1. ^ "SGI - OpenGL Overview".
  2. ^ "OpenGL Pipeline Newsletter Vol.2, Transitions".
  3. ^ "Analysis: Khronos and OpenGL ARB merge".
  4. ^ "OpenGL Architecture Review Board Working Group".
  5. ^ "The OpenGL Graphics System Specification. Version 2.1" (PDF).
  6. ^ "IRIS GL, SGI's property".
  7. ^ "Creation of the OpenGL ARB".
  8. ^ "End of OpenGL++".
  9. ^ "Announcement of Fahrenheit".
  10. ^ "Members of Fahrenheit. 1998".
  11. ^ "End of Fahrenheit".
  12. ^ "OpenGL 2.1 Features".
  13. ^ "OpenGL ARB announces an update on OpenGL 3.0". October 30 2007. Retrieved 2007-10-31. {{cite web}}: Check date values in: |date= (help)
  14. ^ "OpenGL SIGGRAPH 2006 Birds of a Feather Presentation (PowerPoint documents)".
  15. ^ "OpenGL Pipeline Newsletter Vol.2, The New Object Model".
  16. ^ "The OpenGL Pipeline Newsletter - Volume 003, Using the Longs Peak Object Model".
  17. ^ "The OpenGL Pipeline Newsletter - Volume 003, Climbing OpenGL Longs Peak".

Further reading

  • Richard S. Wright Jr. and Benjamin Lipchak: OpenGL SuperBible, Third Edition, Sams Publishing, 2005, ISBN 0-672-32601-9
  • Astle, Dave and Hawkins, Kevin: Beginning OpenGL Game Programming, Course Technology PTR, ISBN 1-59200-369-9
  • 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, ISBN 0-321-17383-X
  • 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
Retrieved from "https://en.wikipedia.org/w/index.php?title=OpenGL&oldid=169108538"