   HLSL: will if-statements with uniform bools always get optimized away?
  I am wondering whether it is ok to use uniform arguments to a HLSL function and expect them to get compiled away.For example if I have 2 techniques for lighting, one with, the other without shadows://Pseudocode...technique lighting{    SetPixelShader(doLighting()); }technique lightingWithShadow{    SetPixelShader(doLightingWithShadow());}It would be nice to replace it whith something like this://Pseudocode...float4 doLighting(uniform bool shadow, Input input){    float3 light = blah();    if (shadow) return float4(light * doShadow(), 1.f);    else   return float4(light, 1.f);}technique lighting{    SetPixelShader(doLighting(false)); }technique lightingWithShadow{    SetPixelShader(doLighting(true));}I know the above code will work, but somehow I am afraid, that it is less efficient, although my test doesn't suggest such a thing. Does somebody know what happens to uniforms?   
  It's called Static Branching.They should be optimized.Look hereAnd also hereCheerioDark Sylinc   ;  The DX9 effect system will auto-generate versions of your shaders when you branch on a uniform variable whose value is set in a technique or pass declaration.  I'm not sure about DX10 effects though...although I don't see why they wouldn't keep that functionality.This also has nothing to do with static branching, btw.  We're talking about the shader assembly being generated in such a way (by the Effects framework) that there's no flow control instructions used at all.  With static branching you still have flow control instructions...they're just special instructions that only work on boolean constant registers.  When the shader gets set and you run it, the driver JIT's the shader assembly and removes the flow control instructions (at least I think that's how it works).   ;Quote:Original post by MJPThe DX9 effect system will auto-generate versions of your shaders when you branch on a uniform variable whose value is set in a technique or pass declaration.  I'm not sure about DX10 effects though...although I don't see why they wouldn't keep that functionality.That's exactly what I'm after. I use DX10 though, so hopefully its still there.;  Your best bet is to use FXC and look a the disassembly produced. This will answer your questions and assure you that the compiler optimizes stuff like this.  The effects system gives you some assistance, but underneath it uses the normal shader system and normal compiler to get the job done.  A little code tweaking might be necessary here in order to view the results you are looking for.  Namely an entry point that calls your method the same way effects is calling your method will demonstrate exactly what effects has to do anyway.   ;  Hm, I was hoping that it was common practice to do stuff like that. :)Is there a better way of achieving something like that? I remember having trouble to use macros in such a way.   ;Quote:Original post by B_oldIs there a better way of achieving something like that? I remember having trouble to use macros in such a way.I was going to suggest macros :PThough it can get unreadable if the shader is complex.This is why each shader is unique.Personally I keep the common code (when possible) in another file and include it (I actually use Cg).But most of the time I need the same code with minor changes (like your example) I usually have a "master" file where I then modify from it and make the custom shaders.I keep the files well organized in different folders. When I need to change something, I use tools like Notepad++ (Replace in all opened tabs..) and Tortoise Diff to change all the files in matter of seconds.Also the C++ material system handles a lot for me.On CPU code I tend to write the code once and use it multiple times with different parameters. But shaders are small tiny programs where efficiency is top priority.Besides having a bug in a shader isn't really a big deal most of the times, because often they're so small and thus easy to spot or fix.CheersDark Sylinc   ;  I would love to use macros. But is it possible to define the macro inside the technique/pass and have it correctly evaluated inside the function that gets compiled? That's what didn't work for me IIRC (I can't check right now).float4 shader(){    #ifdef BLAH   float4 result = blah();    #else   float4 result = foo();    #endif    return result;}technique10 blah{#define BLAH    SetShader(shader);}technique10 alternative{SetShader(shader);}Should something like the above work?   ;  i think marco´s only  work on compilation time of the shader, not 100% sure though, 99%...   ;  That makes sense. But isn't the shader compiled separately for every technique? At least the way you set Shaders in a DX10 technique10 suggests that.   