opengl

You are currently browsing articles tagged opengl.

NVIDIA released a new version of their beta ForceWare 180 drivers. There are 2 very interesting things about it worth mentioning.

First, it supports most of the OpenGL 3 ARB extensions, bringing some useful functionality such as vertex array objects (which first appeared on Mac OS X many years ago) and looser restrictions on framebuffer attachments with respect to their resolution.

However, the most exciting new feature is support for EXT_direct_state_access. That extension addresses a long-standing problem of the OpenGL API, namely state selectors. Indeed, there are quite a large number of functions in OpenGL whose behavior is affected by a number of state variables. For instance, the LoadMatrix* commands depend on the current matrix mode state. As the name suggest, EXT_direct_state_access adds a large number of new functions to OpenGL that explicitly take as an argument the object or piece of state to be modified, bypassing state selectors. This allows, for example, to load a texture matrix without changing the matrix mode first, or to change a texture parameter without binding that texture first.

As the EXT prefix suggests, this extensions is probably not likely to be adopted in the core specification in the next revision of OpenGL 3, but there’s a good chance it might be promoted to ARB, and integrated into core OpenGL by the 3.2 timeframe. This is pure speculation on my part, but this extension is something that a lot of people in the industry desire, so there should be momentum behind it.

GLee is my favorite OpenGL extension “manager” due to its simplicity (2 files to add to your project) and ease of use (just use one of the GLEE extension variables in an if statement, and function pointers are automatically bound).

Check it out.

NVIDIA has posted some OpenGL-related presentations from their recent NVISION 08 conference. I found the one on the GeForce 8 features and Cg particularly good with respect to introducing some modern OpenGL functionality and giving a sense of direction for the API.

http://developer.nvidia.com/object/nvision08-opengl2.html

Also check out the NVSG presentation with has some OpenGL related content.

http://developer.nvidia.com/object/nvision08-NVSG.html

AMD has released ATI Catalyst™ 8.9, which includes a number of OpenGL 3 extensions:

  • ARB_half_float_pixel
  • ARB_draw_instanced
  • ARB_instanced_arrays
  • ARB_map_buffer_range
  • EXT_texture_compression_3dc
  • EXT_texture_compression_rgtc
  • EXT_texture_compression_latc
  • EXT_texture_shared_exponent
  • EXT_depth_buffer_float
  • EXT_gpu_shader4

The addition of the geometry instancing extensions and of gpu_shader4 (GLSL 1.20) is particularly significant, as they expose functionality that has been available since DirectX™ 9, and of course DirectX™ 10 features as well.

I just stumbled on this Google Code project which is categorizing and documenting OpenGL extensions. It should prove to be a very useful reference, check it out.

http://code.google.com/p/glextensions/

Check it out, it’s a good read.

http://www.farrarfocus.com/atom/

There has been a lot of noise on various news sites and forums concerning OpenGL 3 and how the GL Working Group has killed OpenGL. I consider most of that noise just that, noise. The dissatisfaction of API fanboys that has little to do with the reality of hardware and software vendors.

With that being said, here’s a a list of reasons why OpenGL is not dead:

  • Apple
  • Linux
  • Samsung
  • Autodesk
  • Google
  • Blizzard
  • id
  • NVIDIA
  • AMD
  • Intel
  • Matrox
  • Sony

You get the idea. Microsoft Windows is not the only operating system that needs a 3D graphics API. Are companies like Apple and those that have financial and strategic interests in Linux, or mobile handset manufacturers, really going to say “Oh snap, the fanboys have declared OpenGL dead, so huh… we’re not going to offer 3D hardware acceleration on our platform anymore. Sorry.”?

As for the reason I included Blizzard, id, NVIDIA, AMD and Intel in that list, it should be obvious: they contributed and are contributing massively to the development of OpenGL. Why in the world any company would spend significant man-hours (and hence dollars) on something it plans on killing? Projects do get killed, sure, but I doubt anyone has ever started a project with the intention of killing it from the start.

So to all the of API fanboys out there: beware the CAD monster. As for me, I will be discussing the new specifications over the course of the upcoming days, and am looking forward to OpenGL 3 drivers from the various hardware and software vendors in the industry.

Addendum: please see the comments for a clarification of what I mean by API fanboy. There are some very smart people who have criticized constructively the new specification, but those people have not made emotionally-charged and irrational comments such as “OpenGL is dead”. I am sorry if I offended anyone by not being clear enough the first time.

Along with the OpenGL 3 and GLSL 1.3 specifications, the OpenGL Working Group has also released a number of ARB extensions which bring any OpenGL 3 core functionality to OpenGL 2.1 if possible. Although the OpenGL 3 specification’s ARB extension annex doesn’t list them, they are available on the OpenGL Extension Registry. Below are direct links to the extension specifications. Most of them are the ARB form of NVIDIA’s Shader Model 4 EXT extensions.

If you have read my previous entry, you’ve seen the links to the change-annotated versions of the OpenGL 3 and GLSL 1.3 specifications. If you are an OpenGL veteran, those versions will provide for a better read, highlighting the new content, thus allowing you to focus on the important stuff.

Barthold Lichtenbelt of the OpenGL Working Group wrote an extremely valuable post in the OpenGL forums into the final form of OpenGL 3 and the radical change from the Longs Peak plan. It certainly is worth reading.

« Older entries