nope i was wrong, the base triplanar normal seems to be inverted on some places

Megalomaniak
to difficult for me to really understand the normal blending. i simply messed around with an example on shadertoy.
strange thing is that it works correctly on specific axises and others dont.

did some tests, my normal blend code is correct i think, somehow the triplanar sampling gets messed up

DJM triplanar_pos *= vec3(1.0,-1.0, 1.0);

Whats the purpose of inverting that one scalar component?

  • DJM replied to this.

    Megalomaniak i have no idea, i allready tried setting that to 1. i started with the shader spacecloud wrote.

    actually deleting this line made the shader work
    triplanar_pos *= vec3(1.0,-1.0, 1.0);
    dont know why, but it works fine now.

    I was honestly going by gut feeling there, so if it works now, great. But there could still be a chance of some nasty surprise I suppose, since I was just giving a quick glance over the code, it's not as if I made a quick test model and brought it into godot to test the actual shader out on it.

    i was wrong, again, bah....
    ive managed to get the normal lighting working correctly but the normals are now way too saturated
    ive made a zip of my terrain and current state of the shader.
    feel free to have a look.

    also, why is it when u zip a godot project its larger than the actual files that are in the project folder?

    Because there's likely already some compression involved. I'll take a look at the scene when I have a bit more free time, hopefully some time tomorrow.

    Ok, I'm looking at it. But whats your current specific problem? Lowering blend_sharpness below 1.0?

    • DJM replied to this.

      Megalomaniak thnx for having a look, are u using alpha12?
      the normals are way to 'hard' now .
      if u lower blend_sharpness the triplanar blending gets messed up, which is not what i want

      Yes alpha 12. Lowering blend sharpness what I see looks like the detail textures mapping/"UV"s are messed. Like the texture isn't repeating correctly.

      Also off topic but interesting to note: the image is displayed wrong in my browser. Gamma is off. Hmm.

      yeah blend_sharpness variable should always be just 1 i guess,
      dont know why its exposed as a variable, this gives the same result
      power_normal = abs(NORMAL);
      i think, the fix lies in these lines of the shader>

      power_normal = pow(abs(NORMAL),vec3(blend_sharpness));
      power_normal /= dot(power_normal,vec3(1.0));

      but im just guessing.

      Ok, I removed all the detail blending and the issue remains so it's in that blend() function.

      this was the only working method i found on an example on 'shadertoy'

      n1 += vec3(0, 0, 1);
      n2 *= vec3(-1, -1, 1);
      	
      return normalize(n1*dot(n1, n2)/n1.z - n2);

      https://www.shadertoy.com/view/4t2SzR

        i also tried making a 'fake wind' shader, but its useless, as the editor becomes really, really slow.
        and the vertices dont get displaced correctly, it seems they get calculated from the pivot point of the mesh

        shader_type spatial;
        render_mode blend_mix, depth_prepass_alpha, cull_disabled, diffuse_burley, specular_schlick_ggx;
        uniform float alphatreshold;
        uniform float strenght : hint_range(0.0, 1.0, 0.05);
        uniform float speed : hint_range(0.0, 1.0, 0.1);
        
        uniform sampler2D colortex : source_color,filter_linear_mipmap,repeat_disable;
        uniform sampler2D normaltex :  hint_roughness_normal,filter_linear_mipmap,repeat_disable;
        uniform sampler2D roughnesstex : hint_roughness_gray,filter_linear_mipmap,repeat_disable;
        
        
        
        void vertex() {
        	
        	VERTEX.x += sin(TIME * speed + VERTEX.x + VERTEX.z ) * strenght * COLOR.g;
        	VERTEX.y += sin(TIME * speed + VERTEX.y + VERTEX.x ) * strenght * COLOR.g;
        	VERTEX.z += sin(TIME * speed + VERTEX.z + VERTEX.y ) * strenght * COLOR.g;
        
        }
        
        void fragment() {
        	
        	ALPHA = texture(colortex,UV).a;
        	ALPHA_SCISSOR_THRESHOLD = alphatreshold;
        	ALBEDO= texture(colortex,UV).rgb;
        	NORMAL_MAP = texture(normaltex,UV).rgb;
        	METALLIC = 0.0;
        	SPECULAR = 0.5;
        	ROUGHNESS = texture(roughnesstex,UV).r;
        	
        }

        DJM this was the only working method i found on an example on 'shadertoy'

         n1 += vec3(0, 0, 1);
         n2 *= vec3(-1, -1, 1);
         	
         return normalize(n1*dot(n1, n2)/n1.z - n2);

        It's not that, I already ruled that and now the blend() out. So it's just the triplanar mapping as far as i can tell. It's also entirely possible that the issue involves some bug in godot 4 rendering. I tried creating a standard material with triplanar mapping and converting into shader for comparison. The code seems pretty much the same as I suspected, so...

        • DJM replied to this.

          Not sure yet. I'll try and hammer out a custom shader from scratch to test further, in the meanwhile you can try setting up a test scene in godot 3 and copy and paste the shader into there, see how it does there.