Shader scripting

I don't know how many of you folks have played Quake III based games, or anything with similar capabilities. However, I recently got back into Jedi Knight II and have discovered the ability to add things called shaders to textures.

The way they work is pretty simple; you create a shader file using a fairly simple scripting language, and simply name it the same as a texture you're using in-game. When this texture is found, if it has a corresponding shader then the shader is used to determine how it is drawn.
What the shader itself does, is takes image data and using a few settings, applies it onto the existing image data.

What you can do with this for example is take say a polished metal surface with rivets in it, first taking the base image (grey-metal with rivets) and apply a texture to it using the environment distortion (which I think is possibly how shiny works at the moment?), then apply another image on top which would be the metal again, but this time using an alpha channel to make the metal itself partially transparent, and the rivets entirely opaque.
The result is a shiny piece of metal where the metal itself is shiny, but the rivets remain as normal and thus stand out more.

The shader for this (in Quake III) would look something like this:

textures/grey_metal_rivets
{
    { // Start with the base-image, ignoring its alpha channel
        map textures/grey_metal_rivets
        blendFunc GL_ONE GL_ZERO
    }
    {
        map textures/grey_metal_shine
        detail       // causes this stage to be ignored if detailed shaders are turned off
        blendFunc GL_SRC_ALPHA GL_ONE
        tcGen environment
    }
    {
        map textures/grey_metal_rivets
        detail
        blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
        rgbGen lightingDiffuse
    }
}

If you want to know more about Quake III shaders then read the Quake III shader manual (I recommend it as it clarifies it quite well, just skip the parts on surface, sky and fog parameters and editor specific settings).

The feature suggestion however is fairly simple; we would be given a new type of script which simply compiles the above type of script into OpenGL shader instructions which can then be used by the game. These shader-scripts can then simply be attached to a texture to change it's behaviour, that is the texture files themselves would have some extra data at the start telling it where to find the shader script, once the shader script has downloaded it can then start being applied.

Shaders of course can be used with multiple textures for some very impressive effects, these would need to be downloaded too, so some limits on shaders may be needed. Though to be honest, any shader with more than 3 stages is probably doing more work than it needs to anyway, a limit of 5 stages over 2 or 3 textures should suffice without squashing creativity. Some built-in variables can help, for example $shineTexture to use the default shiny texture instead of your own.

So why do we need them? Shaders allow for some really cool stuff, and put a lot more power in the hands of those people who know how to use them. The main purpose I've put it to in JK2 is in adding visually interesting effects to a player model's textures. In SL that equates to; skins!
With these would could add shiny areas to our avatars, or use alpha maps to remove parts of them. These can even be used to add complex bump/height mapping to a character for some really cool effects there (these require lighting to be done to the base-image BEFORE shaders are applied).
Best yet, all the functionality required for these is built into OpenGL already, while there are a few features that are incompatible with some cards, these can usually be dropped as they're not particularly useful ones anyway. Shaders are already being used in game for things like ripple water. They can even be used to apply texture-animations to a texture, allowing us to have avatars that appear to morph and change.

Currently we have to use multiple prims to spoof some of these effects, and they usually turn out badly, as some camera angles will show up the layered set-up. Furthermore we often needs large, alpha-mapped images to keep the desired effect looking good, while a shader can happily use low-detail layers with only a single high-detail layer (or it can use the same high-detail layer in different ways) to produce some really awesome effects.
Not to mention the current in-game bump-mapping is a bit basic, with shaders you can create an image with an alpha channel and use it as a bump-map instead of for alpha.