Simple Double-sided Diffuse Rimlight Shader

Shader "FX/DoubleSidediffuseRimlight"
{
    // These are the fields that will appear for this Material in the Inspector - see Unity doc at http://docs.unity3d.com/Documentation/Components/SL-Properties.html
    // The first part is the property's variable, eg. "_MainTex" - Naming your main texture "_MainTex" signals to Unity that this Shader should be included in Lightmap calculations
    // Using the standard Unity property names also lets Unity apply a fallback Shader if the user's hardware can't handle this one
    // The second part in brackets is the name of the property in the Inspector, eg. "Main Texture" - This can be anything you like.
    // The third part in brackets is the variable type, eg. "2D" declares it to be a texture file -
    // The fourth part is the property's default value, eg. "white {}" - Textures are generally given default values of white, gray or black
    Properties
    {
        _MainTex ("Main Texture", 2D) = "white" {} // This is the material's Texture property and we want it to be included in Lightmap calculations (especially LightProbes)
        _RimColor ("Rim Color", Color) = (0.26, 0.19, 0.16, 0.0) // This is the material's RimLight Color
        _RimPower ("Rim Power", float) = 3.0 // This is the material's RimLight strength.  0 will be maximum rimlighting... Rim power is generally exposed as a Range property type
    }

    // The SubShader is where the Shader calculations actually happen
    // IMPORTANT : Normally, surface shaders cannot include two passes, but we're going to use a sneaky trick to use two passes into this one
    SubShader
    {

        // This allows Unity to intelligently substitute this Shader when needed
        Tags { "RenderType"="Opaque" }
        LOD 200

        // This lets Unity know it doesn't need to worry about the back of our object right now, because we can't see it
        Cull Back

        // The syntax that was use after "pragma" tells Unity what kind of shader this is and how it should be applied, eg.
        // This shader is a surface Shader of type Lambert, and we want Unity to approximate view direction to speed up calculations
        CGPROGRAM
        #pragma surface surf Lambert approxview

        //These match the shader properties
        uniform sampler2D _MainTex;
        uniform fixed4 _Color, _RimColor;
        uniform fixed _RimPower;

        // This contains the inputs to the surface function
        // Valid fields are listed at: http://docs.unity3d.com/Documentation/Components/SL-SurfaceShaders.html
        struct Input
        {
            float2 uv_MainTex;
            float3 viewDir; // Since this is a RimLight Shader, we need to account for the Camera View Direction.  This value accesses Unity's internal calculations
            float3 worldNormal; // Since this is a Mobile Shader, we want to try to avoid complex calculations.  This value uses the Unity's world normals instead of the object normals
        };

        // This is where we prepare the surcace for lighting by propagating a SurfaceOutput structure
        void surf (Input IN, inout SurfaceOutput o)
        {
            fixed4 c = tex2D (_MainTex, IN.uv_MainTex); // Samples the texture
            o.Albedo = c.rgb; // Modulate by main colour
            o.Alpha = 1.0; // No alpha in this shader

            fixed rim = 1.0 - saturate(dot(normalize(IN.viewDir), IN.worldNormal)); // We calculate the dot product of the vertex and our view direction, and use it to calculate our rim light

            o.Emission = _RimColor.rgb * pow (rim, _RimPower); // We apply our rim light and place it in the Material's emmission value
        }
        ENDCG

        // This lets Unity know that we'll need the back of theobject now, but it can ignore the front... it we wanted, we could also say "off" and have it paint everything
        Cull Front


        // IMPORTANT : This is where this shader starts getting sneaky and weird
        // The "vertex" syntax at the end of the "pragma" line tells the shader we want to do some vertex calculations before we paint the texture, and that we'll put them in a function called "vert"
        CGPROGRAM
        #pragma surface surf Lambert approxview vertex:vert

        uniform sampler2D _MainTex;
        uniform fixed4 _Color, _RimColor;
        uniform fixed _RimPower;

        struct Input
        {
            float2 uv_MainTex;
            float3 viewDir;
            float3 worldNormal;
        };

        // This is our vertex function, I'm going to break it down so you know what's happening
        // "inout" tells Unity we want to hijack a value.  We're going to take it in, do something to it, and push it back out
        // "appdata_full" is the output of Unity's standard vertex calculations, if this wasn't a Surface Shader, we would have to do those ourselves
        // "out" tells Unity that we'll also be producing another value (this is actually pretty normal c syntax)
        // "Input" is the value structure we defined just above
        // We're calling it "o"
        void vert (inout appdata_full v, out Input o)
        {
            // Since Unity wouldn't normally worry about our Input structure before the surf function below, we ask Unity to prepare it for us now so we can access the vertex info
            UNITY_INITIALIZE_OUTPUT(Input, o);

            // Here, we simply switch the normals of the entire object, this will let Unity paint a texture on the back side of the planes (which are now front sides)
            v.normal = -v.normal;
        }

        void surf (Input IN, inout SurfaceOutput o)
        {
            fixed4 c = tex2D (_MainTex, IN.uv_MainTex);
            o.Albedo = c.rgb;
            o.Alpha = 1.0;
            fixed rim = 1.0 - saturate(dot(normalize(IN.viewDir), IN.worldNormal));
            o.Emission = _RimColor.rgb * pow (rim, _RimPower);
        }
        ENDCG
    }
    FallBack "Mobile/Diffuse"
}