Difference between revisions of "Legacy OpenGL"

From OpenGL.org
Jump to: navigation, search
(Shouldn't I use the latest, which would be OpenGL 4.x?: Added section)
m (Fixed false statements. It's not the vertex color or the normal for "that" vertex but state used for all vertices until changed by a subsequent call.)
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
In 2008, OpenGL version 3.0 was released.
+
In 2008, version 3.0 of the OpenGL specification was released. With this revision, the [[Fixed Function Pipeline]] as well as most of the related OpenGL functions and constants were declared [[Deprecation|deprecated]]. These deprecated elements and concepts are now commonly referred to as ''legacy OpenGL''. Legacy OpenGL is still supported by certain implementations that support core OpenGL 3.1 or higher and the [http://www.opengl.org/registry/specs/ARB/compatibility.txt GL_ARB_compatibility] extension. Implementations that do not expose this extension do only offer features defined in the core OpenGL specification the implementation is based upon.
With this change, immediate mode with the [[Fixed Function Pipeline]] was no longer supported.
+
The functionality has been deprecated, and is sometimes referenced as Legacy OpenGL.
+
It is still supported, and you can probably count on it being available.
+
But there are some serious disadvantages that should be considered.
+
Learning immediate mode as a beginner has a limited value, as most real applications are based on at least OpenGL3.
+
=How do I know what is what?=
+
A typical sign of the immediate mode is the use of glBegin() and glEnd().
+
Immediate mode is based on a procedural method, where vertex data is defined by using glVertex, glColor,glNormal, etc.
+
  
A problem is that very many tutorials on internet are based on the immediate mode.
+
'''Note''': There is a distinction between the above extension and the corresponding [[Core And Compatibility in Contexts|profile]] which was introduced with OpenGL 3.2.
And these tutorials usually do not warn about the legacy status, much because they were created before the OpenGL version update.
+
Because of that, many beginners start out with it without knowing or understanding the consequences.
+
  
Good general tutorials learning the new technique are [http://www.arcsynthesis.org/gltut/ Learning Modern 3D Graphics Programming] and http://www.opengl-tutorial.org/.
+
== Implementations of compatibility contexts ==
  
=What are the advantages of OpenGL3?=
+
Both AMD and NVIDIA provide backwards-compatible implementations at least on Windows and Linux. Apple does only provide an implementation of the core profile and supports core OpenGL 3.2 on Mac OSX. Intel provides an implementation for Windows up to OpenGL 3.1 with Sandy Bridge CPUs and OpenGL 4.0 with Ivy Bridge CPUs. However, Intel's Linux open-source driver developers have recently stated that they will not provide backward-compatibility on Linux.
Much of this was available before OpenGL3, but not for immediate mode.
+
==Performance==
+
* Vertex data can transfered once to the GPU, and rendered many times. That can improve FPS when the amount of data is big.
+
==Flexibility using shaders==
+
* Sooner or later, real 3D projects come to a point where something more complicated needs to be done. At that point, the flexibility with the free data format of VBOs and the possibility to compute the results using flexible shader programs, will enable efficient design.
+
==Compatibility==
+
* OpenGL ES 2 doesn't support immediate mode. If the application is supposed to portable or compatible with mobile devices, the legacy options is not available.
+
  
=What are the basic changes?=
+
== Detecting legacy OpenGL ==
At first, it may look like a lot of effort to do something that was simple in immediate mode.
+
 
And it is more effort, but as soon as you have got it working it is easy to expand.
+
Although by no means exhaustive, the following examples are common in most legacy OpenGL applications.  
An application based on the immediate mode can require significant effort to adapt.
+
 
* You have to create the shader program yourself. Minimum is a vertex shader and one fragment shader.
+
One typical sign that code is using Legacy OpenGL is immediate mode vertex attribute specification starting with a call to {{code|glBegin}} ending with a call to {{code|glEnd}}. This concept is based on a procedural method, where vertex attributes are provided vertex by vertex and attribute by attribute. For instance
* The vertex data is defined in one or more VBO:s ([[Vertex Buffer Object]]).
+
 
* You have to create at least one VAO ([[Vertex Array Object]] to store the states of your geometry.
+
* setting the object-space position with {{code|glVertex*}}
* You can no longer use glMatrixMode or the other pre defined matrix functions. Instead, you manage the matrices yourself, and deliver them to the shader program using uniforms. There are good external libraries for this.
+
* setting the current vertex color with {{code|glColor*}}
* Your polygons can never have more than 3 vertices. That is, a triangle. Though GL_TRIANGLE_STRIP and similar are still supported.
+
* setting the current direction interpreted as the vertex normal with {{code|glNormal*}}
=Shouldn't I use the latest, which would be OpenGL 4.x?=
+
 
The usual recommendation for libraries are to always get the latest version.
+
Other regularly employed facilities are the matrix stack and matrix manipulation commands:
OpenGL 4+ has some added advanced features compared to OpenGL 3.
+
<source lang="cpp">
But if you don't know that you need them, you may as well wait.
+
glMatrixMode(GL_MODELVIEW);
There is no big conceptual change when going from OpenGL 3 to OpenGL 4, as there was when going from version 2 to 3.
+
glLoadIdentity();
One advantage of only using OpenGL 3 is that there are more old graphic cars supporting OpenGL 3 than OpenGL 4.
+
glRotatef(90.0, 0.0, 1.0, 0.0);
 +
glTranslatef(0.0, 0.0, -5.0);
 +
</source>
 +
 
 +
Fixed-Function lighting is found in most legacy applications as well. For that purpose, command such as:
 +
 
 +
* {{code|glLight*}} for setting certain parameters of a specific light source
 +
* {{code|glLightModel}} for determining the shading algorithm
 +
* {{code|glMaterial}} for setting material properties that influence said shading algorithm
 +
 
 +
are used to coarsely approximate real-world lighting with either flat shading or Gouraud shading.
 +
 
 +
== Removed functionality ==
 +
 
 +
A comprehensive list of all functionality removed from core OpenGL 3.1 and higher can be found in ''Appendix E'' of the OpenGL 3.0 specification. The following enumeration shows some important areas that are affected by removal.
 +
 
 +
* Fixed-function vertex and fragment processing. These stages of the [[Rendering Pipeline Overview|rendering pipeline]] are now the developers responsibility and can be fully programmed using shaders.
 +
* Immediate-mode vertex attribute specification, client-side vertex arrays. [[Vertex Attribute]]s must be stored in one or more [[Buffer Object]]s, or [[Vertex_Specification#Non-array_attribute_values|be specified explicitly]] using {{apifunc|glVertexAttrib|*()}}. Since OpenGL 3.2 using [[Vertex Array Object]]s is mandatory.
 +
* The {{enum|GL_QUAD}} and {{enum|GL_POLYGON}} [[Primitive|primitive]] types.
 +
* The matrix stack and related matrix manipulation functions. This includes projection, model-view and texture matrices. Corresponding built-in GLSL functions have also been removed. Managing matrices and sending data to shaders is now the developers responsibility. See [[Related_toolkits_and_APIs#Math_Libraries|this page]] for libraries designed for that purpose.
 +
* Fixed-function lighting, materials and color materials, fixed-function shadow mapping and bump mapping. Everything possible with functions corresponding to these areas can easily be emulated with shaders.
 +
* Accumulation and auxiliary buffers. If additional buffers are needed [[Framebuffer Object]]s can be used.
 +
* Versions 1.10 and 1.20 of the GLSL.
 +
 
 +
== Reasons to avoid legacy OpenGL ==
 +
 
 +
Much of the functionality that was promoted to core OpenGL 3.0 was available as extensions before the specification was released. However, most of the features already moved away from legacy concepts like immediate mode vertex attribute specification and offered advantages in one or more of the following fields.
 +
 
 +
=== Performance ===
 +
 
 +
Vertex attribute data can be transferred once to the GPU, and rendered many times. With immediate-mode concepts this was not the case. Vertex attributes would have been transferred every frame - even when using client-side vertex arrays. Immediate-mode attribute specification has two major drawbacks:
 +
 
 +
* it incurs a lot of API call, e.g. four calls for four different vertex attributes via {{code|glVertex*}}, {{code|glNormal*}}, {{code|glColor*}} and {{code|glTexCoord*}}
 +
* data has to transferred to the GPU after specification, even with completely static geometry that does not change its appearance in any way
 +
 
 +
Depending on the number of vertices the geometry to be drawn is made up of, this will lead to a vast number of commands just to specify the vertex attributes. Client-side vertex arrays eliminate the CPU overhead by providing a way to large chunks of attributes with only a few API calls. However, they do not eliminate the need to transfer data to the GPU every time {{apifunc|glDrawArrays}} or {{apifunc|glDrawElements}} are called.
 +
 
 +
[[Vertex Buffer Object]]s use fewer API calls while storing all attributes in GPU memory, eliminating both above mentioned drawbacks. [[Vertex Array Object]]s offer even more facilities to reduce the number of API calls, yielding, if all prerequisites are met, only two function calls are needed for geometry of arbitrary complexity (though vertex throughput performance is more complicated than simply the number of API function calls).
 +
 
 +
=== Flexibility using shaders ===
 +
 
 +
As already mentioned above, shading programs allow for replacement of formerly fixed-function processing stages. Indisputably, shaders offer flexibility which is unmatched by the fixed-function pipeline and there is no point in arguing against them, since programmable shading is a direct reflection of the capabilities of the underlying hardware. Among countless examples depicting the effects possible with shaders, here are just a few which are noteworthy:
 +
 
 +
;Complex Lighting Models
 +
Fixed-function OpenGL provides only two local lighting models which actually attempt to simulate real-world lighting: flat shading, which produces values for a whole primitive and Gouraud shading which produces values at vertices which are then interpolated across the primitive. With shaders, the lighting model can be arbitrary, albeit still local. For instance, implementing per-pixel Phong shading in GLSL is a very common use-case.
 +
 
 +
;Shadow Mapping
 +
Although supported by extensions as fixed functionality, shadow mapping using a render-to-texture approach and doing the mathematics involved directly in shaders is much more flexible and much less tedious. GLSL also offers dedicated functions to ease shadow-map lookups.
 +
 
 +
;Non-Photorealistic Rendering
 +
Among effects in this category are ''toon shading'' and ''cel shading.''
 +
 
 +
;Hardware Geometry Instancing
 +
Moved to core in OpenGL 3.1, dedicated draw calls and corresponding GLSL 1.40 built-ins make this technique easy to use. Using legacy OpenGL, the developer had to either use the matrix stack and render an geometry multiple times, possibly using immediate-mode functions, or use arrays of object-to-world transformation matrices and also render geometry multiple times to achieve the same effect.
 +
 
 +
;Animation
 +
There are many ways to animate geometry. It can be as simple as a translation or rotation but it can also be a fully fledged character animation system. It can also mean doing no transformation of geometry at all, e.g. when transforming only texture coordinates to achieve certain effect with textures. Legacy application would often employ the matrix stack to achieve this. All of the above can be implemented using shaders and, depending on the algorithm, without much or any intervention from the application.
 +
 
 +
All of the above can also be combined into multiple permutations of shading programs yielding even more effects.
 +
 
 +
=== Compatibility ===
 +
 
 +
OpenGL ES 2 and 3 don't support immediate mode. If the application is supposed to portable or compatible with mobile devices, the legacy options is not available. Also, although a new application which is supposed to work on more than one platform, e.g. Windows ''and'' Linux, drivers might not expose the compatibility extension and thus only support OpenGL 3.0 or higher core features. If so, the application will not work if only a legacy code path exists. Furthermore, if vendors should decide to drop the compatibility extension at some point, i.e. publish drivers only implementing the core profile, the same problem will arise. Writing applications that use only OpenGL 3.0 or higher core features have the advantage of being not only conforming to version 3.0 but also all other versions up to 4.3 and currently there are no known plans to deprecate more features. This means that applications are future proof regarding driver support on all major platforms until explicitly stated otherwise by hardware vendors.
 +
 
 +
== Using the most recent OpenGL version ==
 +
 
 +
Remember: OpenGL is not a library, it is a specification. Like TCP/IP isn't a library; TCP and IP simply define communication protocols, which libraries can implement.
 +
 
 +
You should always use the latest ''driver'' version. But ''OpenGL versions'' correspond in part to hardware facilities. The major version numbers for OpenGL generally represent tiers of hardware. For example, OpenGL 3.x is roughly equivalent to Direct3D 10-level hardware. OpenGL 4.x is roughly equivalent to Direct3D 11-level hardware.
 +
 
 +
So to use OpenGL 4.x features (hardware-based features that is. There are [[OpenGL_Extensions#Targeting_OpenGL_3.3|several features of 4.x that are available in 3.x hardware as extensions]]) means to confine your program to only running on 4.x hardware.
 +
 
 +
GL 3.x hardware is widely available these days, though 4.x hardware has been around for several years now and will only become more widely available. Which you choose is up to you and your needs.

Revision as of 04:17, 27 September 2012

In 2008, version 3.0 of the OpenGL specification was released. With this revision, the Fixed Function Pipeline as well as most of the related OpenGL functions and constants were declared deprecated. These deprecated elements and concepts are now commonly referred to as legacy OpenGL. Legacy OpenGL is still supported by certain implementations that support core OpenGL 3.1 or higher and the GL_ARB_compatibility extension. Implementations that do not expose this extension do only offer features defined in the core OpenGL specification the implementation is based upon.

Note: There is a distinction between the above extension and the corresponding profile which was introduced with OpenGL 3.2.

Implementations of compatibility contexts

Both AMD and NVIDIA provide backwards-compatible implementations at least on Windows and Linux. Apple does only provide an implementation of the core profile and supports core OpenGL 3.2 on Mac OSX. Intel provides an implementation for Windows up to OpenGL 3.1 with Sandy Bridge CPUs and OpenGL 4.0 with Ivy Bridge CPUs. However, Intel's Linux open-source driver developers have recently stated that they will not provide backward-compatibility on Linux.

Detecting legacy OpenGL

Although by no means exhaustive, the following examples are common in most legacy OpenGL applications.

One typical sign that code is using Legacy OpenGL is immediate mode vertex attribute specification starting with a call to glBegin​ ending with a call to glEnd​. This concept is based on a procedural method, where vertex attributes are provided vertex by vertex and attribute by attribute. For instance

  • setting the object-space position with glVertex*​
  • setting the current vertex color with glColor*​
  • setting the current direction interpreted as the vertex normal with glNormal*​

Other regularly employed facilities are the matrix stack and matrix manipulation commands:

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRotatef(90.0, 0.0, 1.0, 0.0);
glTranslatef(0.0, 0.0, -5.0);

Fixed-Function lighting is found in most legacy applications as well. For that purpose, command such as:

  • glLight*​ for setting certain parameters of a specific light source
  • glLightModel​ for determining the shading algorithm
  • glMaterial​ for setting material properties that influence said shading algorithm

are used to coarsely approximate real-world lighting with either flat shading or Gouraud shading.

Removed functionality

A comprehensive list of all functionality removed from core OpenGL 3.1 and higher can be found in Appendix E of the OpenGL 3.0 specification. The following enumeration shows some important areas that are affected by removal.

  • Fixed-function vertex and fragment processing. These stages of the rendering pipeline are now the developers responsibility and can be fully programmed using shaders.
  • Immediate-mode vertex attribute specification, client-side vertex arrays. Vertex Attributes must be stored in one or more Buffer Objects, or be specified explicitly using glVertexAttrib*(). Since OpenGL 3.2 using Vertex Array Objects is mandatory.
  • The GL_QUAD and GL_POLYGON primitive types.
  • The matrix stack and related matrix manipulation functions. This includes projection, model-view and texture matrices. Corresponding built-in GLSL functions have also been removed. Managing matrices and sending data to shaders is now the developers responsibility. See this page for libraries designed for that purpose.
  • Fixed-function lighting, materials and color materials, fixed-function shadow mapping and bump mapping. Everything possible with functions corresponding to these areas can easily be emulated with shaders.
  • Accumulation and auxiliary buffers. If additional buffers are needed Framebuffer Objects can be used.
  • Versions 1.10 and 1.20 of the GLSL.

Reasons to avoid legacy OpenGL

Much of the functionality that was promoted to core OpenGL 3.0 was available as extensions before the specification was released. However, most of the features already moved away from legacy concepts like immediate mode vertex attribute specification and offered advantages in one or more of the following fields.

Performance

Vertex attribute data can be transferred once to the GPU, and rendered many times. With immediate-mode concepts this was not the case. Vertex attributes would have been transferred every frame - even when using client-side vertex arrays. Immediate-mode attribute specification has two major drawbacks:

  • it incurs a lot of API call, e.g. four calls for four different vertex attributes via glVertex*​, glNormal*​, glColor*​ and glTexCoord*​
  • data has to transferred to the GPU after specification, even with completely static geometry that does not change its appearance in any way

Depending on the number of vertices the geometry to be drawn is made up of, this will lead to a vast number of commands just to specify the vertex attributes. Client-side vertex arrays eliminate the CPU overhead by providing a way to large chunks of attributes with only a few API calls. However, they do not eliminate the need to transfer data to the GPU every time glDrawArrays or glDrawElements are called.

Vertex Buffer Objects use fewer API calls while storing all attributes in GPU memory, eliminating both above mentioned drawbacks. Vertex Array Objects offer even more facilities to reduce the number of API calls, yielding, if all prerequisites are met, only two function calls are needed for geometry of arbitrary complexity (though vertex throughput performance is more complicated than simply the number of API function calls).

Flexibility using shaders

As already mentioned above, shading programs allow for replacement of formerly fixed-function processing stages. Indisputably, shaders offer flexibility which is unmatched by the fixed-function pipeline and there is no point in arguing against them, since programmable shading is a direct reflection of the capabilities of the underlying hardware. Among countless examples depicting the effects possible with shaders, here are just a few which are noteworthy:

Complex Lighting Models

Fixed-function OpenGL provides only two local lighting models which actually attempt to simulate real-world lighting: flat shading, which produces values for a whole primitive and Gouraud shading which produces values at vertices which are then interpolated across the primitive. With shaders, the lighting model can be arbitrary, albeit still local. For instance, implementing per-pixel Phong shading in GLSL is a very common use-case.

Shadow Mapping

Although supported by extensions as fixed functionality, shadow mapping using a render-to-texture approach and doing the mathematics involved directly in shaders is much more flexible and much less tedious. GLSL also offers dedicated functions to ease shadow-map lookups.

Non-Photorealistic Rendering

Among effects in this category are toon shading and cel shading.

Hardware Geometry Instancing

Moved to core in OpenGL 3.1, dedicated draw calls and corresponding GLSL 1.40 built-ins make this technique easy to use. Using legacy OpenGL, the developer had to either use the matrix stack and render an geometry multiple times, possibly using immediate-mode functions, or use arrays of object-to-world transformation matrices and also render geometry multiple times to achieve the same effect.

Animation

There are many ways to animate geometry. It can be as simple as a translation or rotation but it can also be a fully fledged character animation system. It can also mean doing no transformation of geometry at all, e.g. when transforming only texture coordinates to achieve certain effect with textures. Legacy application would often employ the matrix stack to achieve this. All of the above can be implemented using shaders and, depending on the algorithm, without much or any intervention from the application.

All of the above can also be combined into multiple permutations of shading programs yielding even more effects.

Compatibility

OpenGL ES 2 and 3 don't support immediate mode. If the application is supposed to portable or compatible with mobile devices, the legacy options is not available. Also, although a new application which is supposed to work on more than one platform, e.g. Windows and Linux, drivers might not expose the compatibility extension and thus only support OpenGL 3.0 or higher core features. If so, the application will not work if only a legacy code path exists. Furthermore, if vendors should decide to drop the compatibility extension at some point, i.e. publish drivers only implementing the core profile, the same problem will arise. Writing applications that use only OpenGL 3.0 or higher core features have the advantage of being not only conforming to version 3.0 but also all other versions up to 4.3 and currently there are no known plans to deprecate more features. This means that applications are future proof regarding driver support on all major platforms until explicitly stated otherwise by hardware vendors.

Using the most recent OpenGL version

Remember: OpenGL is not a library, it is a specification. Like TCP/IP isn't a library; TCP and IP simply define communication protocols, which libraries can implement.

You should always use the latest driver version. But OpenGL versions correspond in part to hardware facilities. The major version numbers for OpenGL generally represent tiers of hardware. For example, OpenGL 3.x is roughly equivalent to Direct3D 10-level hardware. OpenGL 4.x is roughly equivalent to Direct3D 11-level hardware.

So to use OpenGL 4.x features (hardware-based features that is. There are several features of 4.x that are available in 3.x hardware as extensions) means to confine your program to only running on 4.x hardware.

GL 3.x hardware is widely available these days, though 4.x hardware has been around for several years now and will only become more widely available. Which you choose is up to you and your needs.