Shader logic combination as "Filter"

Unity Engine
,
1

Hello! I have game object (for example tree_fir). I should can apply for it

  1. alpha, some color,
  2. wind effect (on mouse over),
  3. some bounce effect (for example: on mouse click)
    and so on.

for first task, I’ve wrote shader, see below.
I understand that I can write new second shader for the second effect, and switch first on second when it need.

what should I do? if second and other effect should has also alpha filter, or color filter?

  1. Can I have both shaders at the same time on one object with some blend effect?
  2. Should I write one big shader with same switch option?

If alphaFilterEnabled
// do staff
end
If ColorFilterEnabled
// do staff
end

If WindFilterEnanbled
// do staff
end

  1. something other?

Thank you! any help.

Shader "Social Infinite/Unlit/BaseUnlit" {
Properties {
    _MainTex ("Base (RGB) Trans (A)", 2D) = "white" {}
    _TintColor("Tint Color (A - Empty)", Color) = (1,1,1,1)
    _Active("Active Tint color or not", float) = 0
    _Alpha("Alpha", float) = 1

    [Enum(UnityEngine.Rendering.BlendMode)] _MySrcMode ("SrcMode", Float) = 1
    [Enum(UnityEngine.Rendering.BlendMode)] _MyDstMode ("DstMode", Float) = 1
    [Enum(UnityEngine.Rendering.CompareFunction)] _MyZTest ("ZTest", Float) = 1
    _MyZWrite ("ZWrite", Float) = 0
}

SubShader {
    Tags {"Queue"="Transparent" "IgnoreProjector"="True" "RenderType"="Transparent"}
    LOD 100

    Cull Back
    Lighting Off
    ZWrite [_MyZWrite]
    ZTest [_MyZTest]
    Fog { Mode Off }
    Blend [_MySrcMode] [_MyDstMode]

    Pass {
        CGPROGRAM

            #pragma vertex vert
            #pragma fragment frag
            #pragma target 2.0
            //#pragma multi_compile_fog


            #include "UnityCG.cginc"

            struct appdata_t {
                float4 vertex : POSITION;
                float2 texcoord : TEXCOORD0;
                UNITY_VERTEX_INPUT_INSTANCE_ID
            };

            struct v2f {
                float4 vertex : SV_POSITION;
                float2 texcoord : TEXCOORD0;
                //UNITY_FOG_COORDS(1)
                UNITY_VERTEX_OUTPUT_STEREO
            };

            sampler2D _MainTex;
            float4 _MainTex_ST;
            float4 _TintColor;
            float _Active;
            float _Alpha;

            v2f vert (appdata_t v)
            {
                v2f o;
                UNITY_SETUP_INSTANCE_ID(v);
                UNITY_INITIALIZE_VERTEX_OUTPUT_STEREO(o);
                o.vertex = UnityObjectToClipPos(v.vertex);
                o.texcoord = TRANSFORM_TEX(v.texcoord, _MainTex);
                //UNITY_TRANSFER_FOG(o,o.vertex);
                return o;
            }

            fixed4 frag (v2f i) : SV_Target
            {
                fixed4 col = tex2D(_MainTex, i.texcoord);
                float oldalpha = col.a;
                col = (col * _TintColor) * _Active * 2 + col * (1 - _Active);
                col.a = oldalpha * _Alpha;
                //UNITY_APPLY_FOG(i.fogCoord, col);
                return col;
            }
        ENDCG
    }

    // paste in forward rendering passes from Transparent/Diffuse
    //UsePass "Transparent/Diffuse/FORWARD"
}

}
2

This is kind of what #pragma shader_feature and #pragma multi_compile are for.

However static branches (i.e.: if statements looking at values that are material properties) are also really fast to the point of being essentially free on modern GPUs.

Do you can also do stuff like:

// Property - will appear as check box.
[Toggle] _Active ("Active Tint Color", Float) = 0

// Uniform declaration - defined as a bool here even though it's a float property.
// Unity will handle this for you.
bool _Active;

// Fragment shader
fixed4 col = tex2D(_MainTex, i.texcoord);
if (_Active) col.rgb *= _TintColor.rgb * 2.0;
2 Likes
3

—However static branches (i.e.: if statements looking at values that are material properties) are also really fast to the point of being essentially free on modern GPUs.

But for mobile device?

4

Depends on the device. Sometimes yes, generally no, hence the existence of multi_compile.