Restructure, Refactor, Rewrite, Re...

Sorry, not many shiny pictures in this one.

End year two. It doesn't feel like it's been that long...

This is mostly a look back on how the past year has gone, and what I have planned for the (hopefully near) future.

So, first big thing of 2006: Dynamic Range Lighting

Wow, that was a fun resource to release. First a huge thanks to Jeff Raab (my usual partner in crime) for getting the windows version up and running. Next another huge thanks to John Kabus for working with us on the finishing touches, releasing it, and ensuring that we didn't accidentally hurt sales of any products (*cough* TLK *cough*).

In the ultimate irony, I did not own a copy of the TLK when the resource was released, and went a week without being able to access my own resource. Oops. So ya, just so you know John, I bought the TLK entirely to use the DRL resource.

Next action of 2006: Dynamic Range Lighting 2.0 Right, who saw that coming?

I also submitted an IOTD for this resource, which despite all logic actually went up. In addition, it had downloadable precompiled executables for Mac and Windows, and loads of happy documentation. It was more like a miniature free product release than a resource release. Only without as much QA, which lead to a couple of bug fixes that not everyone picked up on. All in all though, it went over pretty well.

And here I drop out of submitting resources. Sorry about that.

Not that I didn't write up some possible resources. I put together a GLSL version of the TGE water upgrade resource (which I believe is the most popular resource ever released, way to go Manoel!). Initially I wanted to break my work up into two resources. One resource would be a very simple integration of GLSL into TGE, making it easier for various objects to load GLSL shaders and generally being cleaner than previous shader integrations (read: I added a couple of dgl functions to load shaders), the other being GLSL water. Manoel believed that a GLSL integration should have lots of solid examples behind it, such as bumpmapped interiors, reflective water, and DRL.

I figured why not, and promptly moved all of the resources over to GLSL.

<insert quiet hush hush stuff I can't talk about>

Sadly the resource was never released.

However, I did work closesly with Jon Jorajuria, Alan James, and Ian Roach on adding these GLSL enhancements to their awesome games. Thanks guys for testing and abusing the code!

The Illumina demo marked the first time the GLSL work I had done was available to the general public in any form.

It sucked. My bad. I hadn't considered that people wouldn't have updated their drivers since 2004/5, nor had the code been extensively tested on cards which don't support shaders. Untested code is buggy code, and damn did it show.

I don't want to talk about that anymore.

Around the same time as the Illumina release I wrote up the OpenGL FAQ and Shader FAQ articles on TDN. Check out the OpenGL one! It got lots of love and includes tons of neat little tips on how to use spiffy OpenGL features like FBOs, VBOs, GLSL, and more!

Please ignore the shader one. It is unloved. Maybe you can give it some love.

Now about here I basically drop out of everything (as far as you know). I resurfaced once a month to post a .plan and, word to the wise, my .plans usually said nothing about how I was really spending my coding time.

Would you like to know what I've really been up to?

The last update of my GLSL code that went out to the few people I was working with was from June 28th. July 1st, I ripped out everything I had done and started over from scratch.

The GLSL code as of June 28th was modelled much like the existing Cg resources. Each object was responsible for tracking its own shader, etc. Happy fun with making sure they all loaded, that shaders were supported, and, best of all, ensuring that they were properly reloaded when our context was destroyed and a new one created. Clearly no way to handle shaders.

From this desire to keep shaders centralized I wrote a shader manager for Torque.
ShaderManager function list (well, half of it, give or take).

The shader manager uses a pure virtual class, Shader (aren't my names so imaginative) to handle all shader management, and all objects which use shaders also deal with the Shader class. Behind the scenes, there are actually four classes which implement shaders, GLSLShader, CGShader, ASMShader, and ATITShader. Each class handles a different kind of shader, and together they allow you to load crossplatform shaders on almost every programmable GPU, from the GeForce 3/Radeon 8500 up to the GeForce 7950/Radeon 1950 (sorry, no 4.0 shaders supported). In addition, as you may note, the shader manager allowed for setting global paramters, which applied to all shaders. What you can't see is that global parameters could be set from script, allowing for easy script control of shaders (yay!), and all global parameters could be saved into a .cs file which could be exec'd on launch to reload and initialize all global parameters (some of this was written entirely for the shader IDE I mentioned in my previous .plans).

But of course, shaders are only part of the equation.

Meet the Modernization Kit!

Remember that resource with spiffy GLSL stuff that I never released? Be glad I never released it. You're looking at the latest incarnation of where that has gone. I am currently going through and moving as much of the code as possible into separate files, and clearly marking all changes for easy merging.

Some things you can glean from that short little file list: Shaders, vertex buffers, a material system, DRL, and some sort of GLSL validation.

Shaders are essentially the shader manager described above, though it is currently being streamlined to work better with the material system.

Vertex buffer objects: They're vertex buffer objects. mkVBOManager.cc contains all the code which manages VBOs, allocates them as needed, and wraps using them.

DRL: DRL is being moved out of scenestate/scenegraph (WHY DID I EVER PUT IT THERE? WHY?!) and into its own class. Because DRL has virtually no reliance on anything Torque specific (getting window size is probably the most Torque specific thing it does), this class will be essentially drag and drop into any OpenGL based engine.

Materials: mkMaterial.cpp. At the moment, the material system is a very basic script interface that allows you to explicitly specify shader fallbacks. It also contains some early code for setting parameters in script on a per material basis, and loading shaders based on a user set shader quality level. It may be expanded to modify other portions of the current rendering state, but this is highly unlikely.

I'm restructuring, refactoring, and rewriting all of this old code, documenting it, expanding it, testing it.

Only one thing left to do when that's all done with.

See you all next month!