UV based on world position in surface shader normals problem

Unity Engine
1

Hi, I did simple shader which should ignore UVS and map topdown texture based on vertex position. All works except one thing normals. It seems that they are rotated by object rotation somewhere out of my code. Because normal before put into o.Normal looks without seems if put for debug into albedo and also o.Normals seems without seems… I also tried to make rotation clockwise the object rotation, result is better but not absolutely OK, and also scale started affecting it. So I am putting there code without that feature. If you have an idea how to make any trick to say do not rotate normals. I would be very glad :). (note it is not triplanar it is only for topdown surfaces and it is meant to have no seems between objects with different rotation)

Shader "Custom/TopDown Global Map" {
    Properties
    {
        _Color("Color", Color) = (1,1,1,1)
        [NoScaleOffset]_MainTex("Albedo", 2D) = "white" {}
         [NoScaleOffset]_MetallicGlossMap("MetallicMap", 2D) = "white" {}
        _Glossiness("Smoothness", float) = 0.5
        _Metallic("Metallic", float) = 0.0
         [NoScaleOffset]_BumpMap("Normal Map", 2D) = "bump" {}
         _BumpScale("Scale NormalMap", Float) = 1.0
         [NoScaleOffset]_OcclusionMap("Occlusion", 2D) = "white" {}
         _OcclusionStrength("Occlusion Strength",float) = 1.0
         _Repeatance("Repeatance",float) = 1.0
    }

    SubShader {
        Tags { "RenderType"="Opaque" "DisableBatching" = "true"}
        LOD 200
       
        CGPROGRAM
        // Physically based Standard lighting model, and enable shadows on all light types
        #pragma surface surf Standard vertex:vert
        // Use shader model 3.0 target, to get nicer looking lighting
        #pragma target 3.0

        sampler2D _MainTex,_MetallicGlossMap,_BumpMap,_OcclusionMap;//,_EmissionMap;
         struct vertexInput {
            float4 vertex : POSITION;
            float3 normal : NORMAL;
            float4 tangent : TANGENT;

         };

        struct Input {
            float3 worldPos;
            float4 vert;   
        };

        half _Glossiness,_Metallic,_OcclusionStrength,_BumpScale,_Repeatance;
        fixed4 _Color;

void vert (inout vertexInput v, out Input o) {
          o.worldPos= mul(unity_ObjectToWorld,v.vertex).xyz;
          o.vert = v.vertex;

      }

        void surf (Input IN, inout SurfaceOutputStandard o) {

            float2 uv = IN.worldPos.xz*_Repeatance;
             
            fixed4 c = tex2D (_MainTex, uv) * _Color;
            o.Albedo = c.rgb;

            fixed4 m =tex2D(_MetallicGlossMap, uv);
            o.Occlusion=tex2D(_OcclusionMap, uv)*_OcclusionStrength;
            half3 nrm =UnpackScaleNormal(tex2D(_BumpMap, uv),_BumpScale);

o.Normal=nrm;

            o.Metallic =m.a*_Metallic;
            o.Smoothness = _Glossiness*m.rgb;

        }
        ENDCG
    }
    FallBack "Diffuse"
}


There is how shader looks, you can see lighting comes from different dirrections as these 3 cubes have 3 different rotations.

There is unpacked Normal map as albedo - no visible problem

o.Normal as albedo - again no problems… so the problem has to be somewhere in any default shader pass…

Thank you for your advices in forward :slight_smile:

2

There is few lines, which helps reduce seems, without last line, there are just 2 shadow directions by 180. and that last row is magic line, have no clue, just reduced seam to minimum, but the stones does not look same…

half3 transformator= mul(half4(1,0,1,0),unity_ObjectToWorld);
            half rotor = abs(transformator.b-transformator.r);
            nrm=lerp(half3(nrm.r*transformator.b,nrm.g*transformator.r,nrm.b),half3(nrm.g*(transformator.r)*0.5,nrm.r*(transformator.b)*0.5,nrm.b),rotor);
3

Surface shaders assume the o.Normal you set in the surf function is a tangent space normal. That is to say a normal map with the same orientation as the mesh’s stored UVs. To use programmaticly defined UVs with surface shaders you have to either convert the normals back into tangent space, or edit the generated shader by hand to remove the tangent to world transform. The second option is the best for performance, but kind of sucks if you are working in the shader still.

Here’s a post in which I outline the first option, along with a full triplanar shader, and a warning to never use it.

All told it probably adds some 60 operations and uses 3 extra interpolators to work around commenting out one line.

4

Thanks, I knew that caused that problem, just wonder if there is no any kind of pragma or any part to override, which says use world space… Yesterday I played with random magic numbers and got result which is absolutely almost seamless (just if you watch it from few cm, what is impossible to camera clip :slight_smile: )… just when you have 2 overlapping faces it little blinking as they are absolutely not same… but that is what I am trying to avoid :slight_smile:

    half4 bmp =tex2D(_BumpMap, uv);
            half3 transformator= mul(half4(1,0,1,0),unity_ObjectToWorld);
            half rotor = abs(transformator.b-transformator.r);
            _BumpScale=lerp(_BumpScale,_BumpScale*0.56,rotor);
            half3 nrm =UnpackScaleNormal(bmp,_BumpScale);
            nrm=lerp(half3(nrm.r*transformator.b,nrm.g*transformator.r,nrm.b),half3(nrm.g*(transformator.r)*5,nrm.r*(-transformator.b)*5,nrm.b),rotor);
            o.Normal=nrm;

Other solution could be writting it in fragment shader, but I would not go into there, as I have to make it look same as surface shader and there is no surface shader in fragment source code, so I could just change that uv’s and delete that MVP which rotates normals…

5

No, there isn’t a “skip tangent to world normal transformation” option for surface shaders, hence the horrible code in my example.

However surface shaders are just vertex fragment shaders, or more specifically they’re vertex fragment shader generators. There’s nothing a surface shader can do that a vertex fragment shader can’t, it’s just more manual coding.

Just select your surface shader and click on “show generated code” and you now have the (somewhat ugly) vertex fragment shader the game actually uses. As long as you’re not looking to change the #pragma surface parameters, some of which can significantly change the generated shader’s code, working on that shader directly isn’t too bad, especially if you do a bit of visual clean up.

6

Thanks, I know that surface is nothing other, than fragment, but building only little changed standard material in fragment, I do not know all tricks about metalic, smothness etc in fragment, to behave exactly as in standard. I tried to find something, but could not. So without any frame, which i can change, i would not try to go there and do some mess in surface :smile: I use fragment shaders, but there I really need to look same as standard :frowning: Anyway optimization of these few rows will hardly improve fps :slight_smile: