Best Practice For Shader Complexity + IOS

Question

Quick question for all you shader wizzards out there, target platform is IOS.

Let's say I want 3 different things for a shader:

 1. Unlit + Lightmap Support * Color.
 2. Unlit + Lightmap Support.
 3. Unlit * Color (no lightmap support).

Now I can write the shader with a bunch of #ifdef regions, branching to all 3 different outcomes depending on settings I choose from script. It keeps all the code in 1 place and makes it easier for organization.

Or I could write 3 different versions of the same shader. I'm not a big fan because I don't like code duplication, and it also makes it harder to organize everything and keep track of all the changes.

The question is, how much of an impact does a shader with too many branches have on the performance in an IOS game? If anyone has some "PRO" pointers for me I would really appreciate it, as always :)

Thanks for your time guys, Stephane

Answer 1

Best Answer

Answer by ScroodgeM · Aug 13, 2012 at 08:40 PM

shaders are compiling in editor and goes to build version in compiled mode. i don't know a way to recompile it an runtime. so, in anyway your task should output 3 different shaders. and that's why is not so important how it will be built.

'#ifdef' is pre-compile operator, so i'm not sure you can do something with it at runtime.

point to another way - using, for example, shader 1 instead of shader 1+2 can be more efficient caused by unity batching.

tell if i understood you wrong.

Add comment · Show 12 · Share

ronronmx · Aug 14, 2012 at 01:19 AM 0

Share

Thanks for your help Scroodge. I don't particularly want to do anything at run-time, I just want to be able to use the same shader for multiple materials, for example, have a "lit" material that sets the shader to the "#ifdef IsLit" branch, another material, "litAndLightmap" that would set the shader to the "#ifdef IsLitAndLightmap" branch etc...

Since the compiled shader code would be bigger for the shader with all the #ifdef branches then it would be for the same shader without the #ifdef branches, I was wondering if that would impact performance.

You were saying that it would output 3 different shaders anyways, how come? Are you suggesting that for every #ifdef found in the shader, it outputs a different shader when compiled?

Thanks for the help!

ScroodgeM · Aug 14, 2012 at 04:05 AM 0

Share

all #ifdef are checked on precompile and then this is one compiled shader on output.

but, you can make a CGINCLUDE file with almost all your source to include it in all 3 shaders with #ifdef blocks, and make a 3 different shaders that includes this file. shaders will contains only params declaration and reference to this include with dclaring #def veriables. so you can get 3 shaders from one source code file

for unity this will be 3 different shaders like it was wrote in 3 different files.

ronronmx · Aug 14, 2012 at 06:05 PM 0

Share

Ah got it, thanks for clearing that up for me, I didn't know you needed to put the source code in a cginc file in order to use custom #ifdef's, and I was also unaware that each #ifdef compiles into a shader each on output...this explains a lot!

Thanks for all your help Scroodge$$anonymous$$!

ScroodgeM · Aug 14, 2012 at 08:26 PM 0

Share

you needn't put the source code to cginc to use #ifdef, but this lets you store your source in one place. using ext cginc file lets you write shaders like this (pseudocode)

Shader "blah blah blah"
{
    Properties...
    SubShader
    {
        #define BLAH1
        #define BLAH3
        #include ...
    }
}

ScroodgeM · Aug 15, 2012 at 09:13 PM 1

Share

not sure about it. may be it's a check for user's customization. for example, in case where user forgot one or declared unneeded including. need to check context to be sure in it. with custom .cginc file it's enough just declare it and be sure that it's already declared in all code below 8)

Show more comments

Best Practice For Shader Complexity + IOS

1 Reply

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions