Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Most shadow systems I have seen use a unified shader system for shadowing techniques, resulting in an uber shader for the projects.

What alternatives do you find work well or is the unified shader the best approach?

share|improve this question

I'm assuming your question is about shadow map-based techniques.

Generally choosing uber shaders is a higher-level decision than shadows, so shadows usually follow whatever method engine uses for rendering.

For example, you might choose using deferred rendering which requires far less permutations than traditional approach, then applying shadows will be added once to the deferred light shader and rendering shadomwap will be essentially the same path that generates G-Buffers.

Another thing I think I heard people considered is to just generate shadowmaps on SPUs without any shaders.

So decide on your method for rendering the scene and use it for shadows as well.

share|improve this answer
Deferred shadows can be implemented whether you use forward or deferred rendering. So this answer didn't really make any sense in my opinion. – Olhovsky Jun 4 '11 at 21:34

From what I see, you have three alternatives to uber-shaders:

  1. Hand-code every shader. Obviously, this is easy if you just have a few shaders and similar lighting conditions everywhere (which might actually be the case on embedded devices). However, it quickly becomes unmanageable with even a few inputs (number of lights, shadows, different materials).

  2. Deferred rendering. Effectively splits up the complexity of uber-shaders into several rendering passes. It's very nice design-wise but the memory and bandwidth requirements are high. Variations include "Light pre-pass" rendering, which does just the lighting in separate passed and gives you complete lighting information in your final compositing shader (which makes this very flexible!).

  3. A shader "build-system". It'll assemble shader-permutations from smaller modular shader-fragments. The whole idea is very similar to uber-shaders, but the more modular design can make it possible to get away with a lot less permutations (since not all options in the uber-shader are orthogonal to each other). It's a pain to build such a system, and there are quite a few pitfalls - but if you get it right, it is quite a powerful tool to have if you don't want something deferred.

In the end, it depends on the specifics of your project. The bigger the project gets, the more I would steer away from hand-coded shaders or uber-shaders and pick something more modular like light pre-pass or a shader build-system. The trend is definitely going towards deferred rendering systems though.

share|improve this answer
What even is an "uber-shader"? – DeadMG Feb 21 '11 at 17:52
@DeadMG: it's typically a single shader with lots of #ifdefs in it that is compiled in all its permutations. The engine then selects the right shader object for a given material. – ltjax Feb 21 '11 at 17:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.