OK, so you probably know what ubershaders are? Unfortunately there is no wiki on this term, but mostly by it we mean very fat shaders containing all possible features with compile-time branching that allows them to be then specialized into any kind of small shader with a limited amount of tasks. But it can be implemented very differently, so here I’ll share my experience on this.
#ifdefs
So, you can use #ifdef, #define and #include in your shaders? Or you’re going to implement it yourself? Anyway, it’s the first idea anyone has.
Why it sucks:
- Too many #ifdefs make your code hard to read. You have to scroll the whole ubershader to see some scattered compile-time logic.
- How do you say “compile this shader with 1 spot light and that shader with 2 directional lights”? Or 2 decals instead of 6? One PCF shadow and one hard? You can’t specify it with #ifdefs elegantly, only by copy-pasting code making it even less readable.
Terrible real-life examples: 1, 2
Code generation from strings
Yet another approach I came across and have seen in some projects. Basically you use your language of choice and use branching and loops to generate new shader string.
Why it sucks:
- Mixing shader language with other languages looks like total mess
- Quotes, string additions, spaces inside strings and \n’s are EVERYWHERE flooding your vision
- Still have to scroll a lot to understand the logic
Terrible real-life examples: 1, 2
Code generation from modules
So you take your string-based code generation and try to decouple all shader code from engine code as much as possible. And you definitely don’t want to have hundreds of files with 1-2 lines each, so you start to think how to accomplish it.
So you make some small code chunks like this one, some of them are interchangeable, some contain keywords to replace before adding.
Why naive approach sucks:
- All chunks share the same scope, can lead to conflicts
- You aren’t sure what data is available for each chunk
- Takes time to understand what generated shader actually does
Code generation from modules 2.0
So you need some structure. The approach I found works best is:
struct internalData {
some data
};
void shaderChunk1(inout internalData data) {
float localVar;
read/write data
}
float4 main() {
internalData data;
shaderChunk1(data);
shaderChunk2(data);
return colorCombinerShaderChunk(data);
}
So you just declare an r/w struct for all intermediate and non local data, like diffuse/specular light accumulation, global UV offset or surface normal used for most effects.
Each shader chunk is then a processing function working with that struct and a call to it, put between other calls. Most compilers will optimize out unused struct members, so basically you should end up with some pretty fast code, and it’s easy to change the parts of your shader. Shader body also looks quite descriptive and doesn’t require you to scroll a lot.
The working example of such system is my contribution to PlayCanvas engine: 1, 2
Examples of generated code: vertex, pixel, pixel 2, pixel 3
So, I’m not saying this is the best approach. But for me, it’s the easiest one to use/debug/maintain so far.
Mr F 