It’s harder than “just use shaders”!
I’m always puzzled why people think that some interesting effect is “shaders”. The most recent example I saw is this message on Dir3d mailing list - it’s about NVIDIA’s skin rendering demo (*).
The most interesting effects are in fact not achieved by the use of shaders - rather it’s the complex interplay of render-to-textures, postprocessing them, using them somewhere else, postprocessing that, using them somewhere else again, combine the intermediate results in various interesting ways, and finally get something that represents the colors on the screen.
So the effect is much more than the shaders; it’s more like “an orchestration of different stuff”. It’s the shaders, textures, models (often with custom data that is required for the effect to work), specially precomputed textures (more custom data for the effect), multiple render textures to store intermediate results, and finally some sort of “script” that controls the whole process.
Shaders are (relatively) small, isolated thingies that operate on small, isolated pieces of data. So they are only a small part of the whole picture, and in fact often they are the easiest part. Both to the effect author, and even for the “engine” to support.
Adding “shader support” to the engine/toolset is a piece of cake. The hard parts are:
- How shaders integrate with the lighting? Once you start doing shaders, you lose all lighting that used to be computed for you.
- How shaders integrate with various data the mesh may have or it might not? For example, to support per-vertex colors you either have to write a single (sub-optimal) shader that always assumes vertex colors are present, or write multiple shaders: when vertex colors are present, and when they are not.
- How shaders integrate with … lots of other things that were taken for granted in fixed function world. Scaled meshes. Various fog types. Texture transforms. The list goes on.
- How do you expose the rest of the “stuff” that makes interesting effects possible? Shaders alone are nothing. You need render-to-texture with various interesting formats. You need to store custom data in the meshes. You need to store custom data in the textures, in various interesting formats. You need custom cameras to render intermediate results into render textures. You need a way to replace object shaders with some other shaders so that these objects can render these intermediate results. The list goes on.
- Hardware support. Once you enter shader world, you get a totally new set of inconsistencies between operating systems, graphics APIs, hardware vendors, graphics card models and driver versions. And a new bag of driver bugs of course.
So shaders do present three big challenges.
1) Shader explosion. How do you do lighting? Do you say “there shall only ever be a single directional light” (that is what most tech-demos do)? Do you try to support the general case and write some dozen shader combinations? How do you handle all other cases that were “just handled” by fixed function pipeline? Vertex formats, fog, texture transforms, etc. Congratulations, multiply your shader count by 10 or so. Or don’t multiply the shader count, but use static/dynamic branching if you have hardware support for it.
2) Platform differences. How you write shaders in the general case, when some things don’t work on AMD cards, some other things don’t work on NVIDIA cards, yet some other things don’t work in OpenGL, some other things don’t work in Direct3D, and something entirely else does not work on Mac OS X (with different things not working on PPC vs Intel, yay)? Congratulations again, multiply your already large shader count by 10 or so.
3) Shaders are just a small part of the equation. You need the whole infrastructure around them to actually enable those interesting effects.
To return to the original message about the skin rendering demo: no, “just shaders” won’t enable that. You need render textures in several formats (color & depth) at least. And some dozen shaders to do the effect for a single light type, for a single mesh configuration, and for a single hardware platform. Multiply the shader count by, hmm…, hundred or so to cover the general case.
Real life is harder than a tech demo. Real life is more than just the shaders.
(*) I’m taking the message out of the context on purpose. Nothing is wrong with noisecrime’s message, I just want to point out that just exposing shaders does not get you very far.

AFAIK, serious guys write a sort of shader “combiner”, which generates all combinations of available shaders (e.g. specular + diffuse + nm out of separate ones) and compiles them as a prebuild step.
Yes, that is one of the possible solutions (and we use that at work). But it’s not ideal either: it takes time to compile the shaders, the shaders take up space, it increases the load time to load all of them etc.
yeah the “shader explosion” is a pain. i think it’s really just a temporary thing though and applies to the “early” shader hardware (sm1-2). in the future i think we’ll all just use lots of conditionals in the shader and let the drivers figure out the most used / expensive permutations and bake those out to optimized versions. it’s a waste for every developer to do this manually.
- Hey, I’ve just seen [a piece of software], it’s wonderfull! How do I create something like THAT?
- It’s simple. Just use C++.
;)
blackpawn: yeah, and some future APIs (D3D 11) seem to be planning to combat this as well. A good thing definitely.
zeux: :)
Serious guys write distributed shader compilers and store the results. Anyways this is hell :)
Why do people think that shaders can do anything? Because they simply don’t know how stuff works (and there’s also the silly marketing thing).
Probably 97% (random figure) of all consumers measure the power of their video card by megabytes of video memory :-)
Wow, very disappointing, way to take my post completely out of context there!
My orignal post was refering to the fact that that sw3d is woefully limited technology wise (limited to circa 1999 tech) and that a whole bunch of effects are either pointless (results way to slow) or simply not possible.
I don’t remember the exact nature of the skin demo now, but i’m pretty sure without shaders the task would be pretty horrible and vastly slower in performance via any alternative. Sure it may well use renderbuffers and other tools, but hey guess what we don’t even have that capability either (well its possible with various hacks but lets not go there).
That was the whole point of my post, not that shaders do everything
Whilst its possible to achieve a number of effects without shaders, e.g the old dot3 bumpmapping, even these are not possilbe purely using the graphics card since the functions are not supported by sw3d even though there are in the various 3D API’s. Although not supported something like bumpmapping is still possilbe, I posted a demo to that list sometime after, but its all done in a convoluted method using bitmap image manipulation and simply uploading them as textures. Having shaders would make it almost effortless.
Your rant just doesn’t make sense. Granted many effects rely on a complete toolset, but shaders form the basis and without them you’d have a hard time achieving effects with the standard api extensions.
So before you go and use a post as a basis of a rant and knocking the knowlecdge, perhaps do a little research into what they are talking about in the first place.
Now if only Unity had a windows IDE, then I could drop sw3d work work with some modern technology ;)
noisecrime, I was under impression that the blogosphere operates in such way - take something out of context and rant about it! :) In other words, sorry for taking it out of the context. Edited the post to clarify.
My only point is that shaders are nothing more than an interface to access the hardware… not more revolutionary than dot3 bumpmapping or multitexture, just in this case the hardware got more complex. And just exposing shaders only gets you so far, because some of the really hard problems (integration with lighting, shader combination explosion, …) are still not solved by the hardware, and must be solved by whatever is built around it (usually “the engine”).