Hi all: I have been reading a lot about shader permutation problem and I'm getting a little bit frustated because I really don't know which solution is better: - uber-shaders: I can't use it because I don't like it because the performance hit of dynamic branching and I must target low graphic cards. - Generate custom shaders on the fly: I have tried this solution but I really don't feel good with it. I have read the article of Shawn Hargreaves and did a little implementation of something similiar but I think is not the way to go ( I like to have more control of my code ) - Use ID3DXEffectCompiler enabling constants at compile time: I like it, but it doesn't seems the way to go neither for me. The main problem with it ( it happens with 'generatin custom shaders on the fly' ) is that I can't ( as far as I know ) save all shaders at disk in one effect and read it with one 'create' call ( I'm targetting to consoles so it matters to cut down loading time ). - Precompile all the possible permutations of the shader, even if I don't use a lot of them: I think this is the best, but I prefer to ask you. I like it because I can generate it totally offline without having to parse all the game data ( even parsing it, maybe the game needs some special combination that is not contemplated on game data ). Besides I can have only one ID3DXEffect ( per shader type ) with N techniques. The only thing the material has to compute is the technique name ( and even that can be computed offline and saved as an index when possible ). Even more, I feel like this solution is the most cross platform, because I can generate all the combinations for XBox360 and PC ( HLSL ), and PS3 ( it seems like I'll have to deal with it soon... ). What do you think? I appreciate every opinion from you. Thanks a lot in advance and excuse me for my english =) Carlos

Thank you, I've solved my problem =)

Carlos

Iv recently had the same kind of questions, and based on research ive done and getting professional opinions on it, an ubershader is the way to go (if your targeting recent hardware). It may seem like it would be pretty slow, but if used correctly, the compiler can actually turn your "dynamic branches" into static branches which are basically for free.

Furthermore, if the branching happens uniformly across the object and dynamic branching needs to be used, it will be fast because all of the pixels/verticies being processed will all be taking the same path, which is what the GPU is really good at.

Quote:Original post by Christer Ericson
Obviously, creating such a system is more work than just having separate .fx files for every shader than a single ubershader.fx file from which others are created, but (1) the above build system gives you pipeline performance benefits for all asset types, and (2) in your "simpler" system you have the problems of remembering to change every relevant shader file when you want to change e.g. lighting, plus you too would rebuild (nearly) all shaders if you touched something as general as lighting falloff, except you wouldn't have the benefit of the smarter build system to help you out in that case.

You include all common elements/functions from shared seperate files, so, changing the lighting falloff only necessitates recompiling the shaders that use that particular lighting model. Easy to parse fx files for the #includes. This results in the optimal compilation time, as you are: compiling only exactly what you need to (any other way of setting up your shaders would require the same or worse), and you can easily parallelize compiling multiple fx files.