OpenGL 2.0 launched!

The OpenGL ARB has formally released the OpenGL 2.0 specification. This not only included things like the improved OpenGL Shading Language API’s, but a bunch of other new features as well. The highlights are;

Programmable Shading Interface

 

 

 

 

 

 

 

 

 

 

The OpenGL Shading Language, and the related APIs to create, manage, and use programmable shaders written in the Shading Language, were promoted to core features in OpenGL 2.0. The complete list of features related to programmable shading includes:

Shader Objects: Shader objects provides mechanisms necessary to manage shader and program objects. Shader objects were promoted from the ARB shader objects extension.

Shader Programs: Vertex and fragment shader programs may be written in the high-level OpenGL Shading Language, replacing fixed-functionality vertex and fragment processing respectively. Vertex and fragment shader programs were promoted from the ARB vertex shader and ARB fragment shader extensions.

OpenGL Shading Language: The OpenGL Shading Language is a high-level, C-like language used to program the vertex and fragment pipelines. The Shading Language Specification defines the language proper, while OpenGL API features control how vertex and fragment programs interact with the fixed-function OpenGL pipeline and how applications manage those programs.
OpenGL 2.0 implementations must support at least revision 1.10 of the OpenGL Shading Language. Implementations may query the SHADING LANGUAGE VERSION string to determine the exact version of the language supported. The OpenGL Shading Language was promoted from the ARB shading language 100 extension (the shading language itself is specified in a companion document; due to the way it’s written, that document did not need to be changed as a consequence of promoting programmable shading to the OpenGL core).

Changes To Shader APIs:Small changes to the APIs for managing shader and program objects were made in the process of promoting the shader extensions to the OpenGL 2.0 core. These changes do not affect the functionality of the shader APIs, but include use of the existing uint core GL type rather than the new handleARB type introduced by the extensions, and changes in some function names, for example mapping the extension function CreateShaderObjectARB into the core function CreateShader.

Multiple Render Targets Programmable shaders may write different colors to multiple output color buffers in a single pass. Multiple render targets was promoted from the ARB draw buffers extension.
Non-Power-Of-Two Textures The restriction of textures to power-of-two dimensions has been relaxed for all texture targets, so that non-power-of-two textures may be specified without generating errors.
Point Sprites

 

Point sprites replace point texture coordinates with texture coordinates interpolated across the point. This allows drawing points as customized textures, useful for particle systems. Point sprites were promoted from the ARB point sprite extension.
Two-Sided Stencil

 

Separate stencil functionality may be defined for the front and back faces of primitives, improving performance of shadow volume and Constructive Solid Geometry rendering algorithms. Separate stencil was based on the the API of the ATI separate stencil extension, with additional state defined by the similar EXT stencil two side extension.

This brings OpenGL up to speed with DirectX 9, and since most of the folks on the ARB are video card manufacturers whom have to support DirectX as well, it’s in their interest to have as few differences as possible. Given OpenGL’s extension mechanism (which is rumored to be considered as a possible feature for DirectX 10), and the rapid development of the last few OpenGL versions, it’s obvious that the hardware folks don’t want Microsoft to dictate the way that 3D graphics are going to look in the future.

So…should you go for OpenGL or DirectX? Just listen to John Carmack from his Feb. 2003 .plan

Reasonable arguments can be made for and against the OpenGL or Direct-X style of API evolution. With vendor extensions, you get immediate access to new functionality, but then there is often a period of squabbling about exact feature support from different vendors before an industry standard settles down. With central planning, you can have “phasing problems” between hardware and software releases, and there is a real danger of bad decisions hampering the entire industry, but enforced commonality does make life easier for developers. Trying to keep boneheaded-ideas-that-will-haunt-us-for-years out of Direct-X is the primary reason I have been attending the Windows Graphics Summit for the past three years, even though I still code for OpenGL.

This entry was posted in Graphics, Graphics API, OpenGL. Bookmark the permalink.