The OpenGL 3.0 spec has finally been released. Instead of coming with a big fancy object model like was promised, we got minor improvements over the OpenGL 2.1 spec. People were a little annoyed by this development - but there is more here than meets the eye.

For one, OpenGL 3.0 comes with a rigorous deprecation model, which lets the device driver bind to you with completely different APIs and behaviors based on how you want to talk to the driver.

OpenGL 3.0 also deprecates a LOT of stuff. Lots and lots and lots and lots of stuff. Note, it's deprecated, not removed. If you use OpenGL 3.0 in "full" mode, you still have all the 2.1 APIs that have been deprecated and they will work. If you use OpenGL 3.0 in "future operation" mode, all of the deprecated APIs won't bind. So no big deal there...

However, this is a shot across the bow for OpenGL users. It's a clear and direct warning to all out there that these APIs are dead weight and will be dropped in OpenGL 3.1. More specifically, a lot of techniques people are used to using are no longer possible with the current 2.1 APIs.

Let's take a simple program. We create a texture, setup the camera, rotate the scene, translate, bind the texture and draw a cube with the texture attached. Sounds simple enough? In 2.1, you'd use several commands specifically for this - glRotate, glTranslate, glBegin, glVertex, glColor, glTexCoordinate, glEnd, etc.. and you're done.

In OpenGL 3.0, all of the APIs I just described above are deprecated. The new way to control the video card is as follows: Upload geometries to the GPU using Vertex Buffer Objects, upload textures to the GPU using Pixel Buffer Objects, configure vertex arrays, generate vertex attribute arrays, compile and link "shader" programs (vertex and fragment), update the shader uniforms, bind the shader, draw the array.

If that sounds like a mouthful, you're not alone. The "approachability" of OpenGL is -gone-, however, as has been pointed out to me in the #opengl IRC channel, these old approaches are like the dark ages of 3d graphics. Needlessly complex, billions of glEnable/glDisable calls, twiddling this, that and another bit of state - it's all gone. Heck, the stupid lighting model is even gone.

In many respects, they're clearly defining a path toward dumping all the "old stuff".. but it means any one who is an OpenGL hobbyist needs to pick up their game and move to the present, from the past. Me included.

Many (including myself) are eagerly awating a version of the OpenGL 3.0 spec that is "forward operation" only, so that we can see which APIs we should use and which we shouldn't. Sure all the deprecated APIs are listed in the 3.0 spec now, but it's still messy, when so many concepts are talked about in great detail through the spec - many of these concepts are just dead in the water.

What does this mean for the OpenGL package in the public repository that I maintain? Well when the future operation spec comes out, it'll allow me to go through and remove all the APis that are deprecated, so that you - the aspiring OpenGL developer in Smalltalk, can get going on the right foot, not the old deprecated foot. My goal is to make sure you use the right APIs from the get go, so that when OpenGL 3.1 catches up with our computers, you're already a more savvy OpenGL developer than most out there.

It'll also mean learning a great deal more about shaders, which are GPU programs you upload to the 3d card and run as you render a scene. There are three kinds: Fragment, Vertex and Geometry. A Fragment shader really means, a program that modifies a pixel just before it is drawn to the screen, in that respect, calling it a 'shader' makes sense. A Vertex shader is a program that modifies vertexes before they are applied to the scene, in this case, it's a pure math function - lots of matrix multiplication, etc.. it's not really a 'shader' per-se.

The geometry shader is the newest, which you'll find in DirectX 10 compatible cards - it can generate vertexes at render time, letting you build your 3d objects entirely on the graphics card, further reducing the role of the CPU and the amount of 'stuff' that the video card has to hold on to in memory.

All the shader programs can be parallelized - and are. This is particularly exciting because this is a truly good way of doing multi-core computing.

These programs are interpreted and compiled dynamically by the OpenGL driver. The language is cross platform and cross card - but kind of C like. It's okay, but you really have to put your head in the right mind-set. I intend to find good ways to integrate shader programming in to the Smalltalk development environment. There's one particularly important part to shaders that we can hopefully do something special with: Shader uniforms.

Shader uniforms are essentially 'parameters' that you can apply to the shader program that's about to run. They're the arguments to a function call basically. I'd like to think that I could pretend to call a shader program from Smalltalk code and instead translating that in to setting up uniforms and then applying the shader program. Time will tell if this is a good idea or not.

For now, the OpenGL program will continue to include all the deprecated stuff.. but I guess I'd like to stress that you shouldn't invest a great deal of time writing programs with the deprecated APIs, as they will disappear.