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?


2 Answers 2


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.

  • \$\begingroup\$ Deferred shadows can be implemented whether you use forward or deferred rendering. So this answer didn't really make any sense in my opinion. \$\endgroup\$
    – Olhovsky
    Commented Jun 4, 2011 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.

  • \$\begingroup\$ What even is an "uber-shader"? \$\endgroup\$
    – DeadMG
    Commented Feb 21, 2011 at 17:52
  • \$\begingroup\$ @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. \$\endgroup\$
    – ltjax
    Commented Feb 21, 2011 at 17:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .