When DeriveNormalZ node is used in material to create normal map, material that use this node will not receive lighting under certain angles.
It’s easy to replicate:
Create Material.
Plug inputs to Color, Metalness and Roughness.
Then add some texture, use DeriveNormalZ on it and pluf output to normal slot.
Now place mesh in level.
The effect is best noticable if some objects are casting shadows on the object in question. Although it can be also noticed without them as in my case the object is going dark.
Now start rotating your light (either Stationary or movable).
I have tried to reproduce the issue you are having and have not been able to. Could you provide a screen shot of your material setup and also a screen shot or video of your issue?
Is the Derive NormalZ needed in this particular case? I was under the assumption that because normals were using BC5 that the shader compiler was already doing that work. I don’t know why that would effect shadows however.
The issue was here because I used my texture with TC_VectorDisplacmentmap compression setting. Why I did such thing ?
Because I packed 4 textures into 4 channel. RG were for normal map. Green for detail roughness map, and alpha for detail diffuse map. It also doesn’t work with TC_Default but that’s to be expected.
DeriveNormalZ works with TC_Normalmap compression, but there is no point in use DeriveNormalZ with Normalmap compression in the first place. At least I don’t see any I could see is viable.
I still think this is an bug. DeriveNormalZ should be able to work with textures that have all 4 channels.
We either need normalmap type compression that preserve all 4 channels with high quality or DeriveNormalZ work properly with any of the existing texture settings.
Thank you for your feedback. I have spoken to our developers and they intend to eventually cull the DeriveNormalZ expression, as it is something that can be done without the need of a function. You could create your own material function that derives a normal using the same math: z = sqrt(1 - ( x * x + y * y)) and custom inputs.
I don’t think there is any issue with derive normal Z. It works on any type, you simply have to make sure the range is -1 to 1 and there are 2 components. Doesn’t matter how you achieve it. I use derive normal Z on texture coordinates to make round normals often.
I think the most likely issue here is that default textures are unpacked 0-1 whereas normal maps are unpacked -1 to 1. A regular texture works just fine using derive normal z, you simply have to constantbiasscale it into the -1 to 1 range. So set -0.5 for the bias and 2 for the scale.
If the range is 0-1, that is like saying your normalmap can only represent positive vector values. That means that each axis is blind to an entire hemisphere.
I have used derivenormalZ on channel packed default textures before. It was to pack more texture samples onto a landscape.
Hi, can you let me know who you talked to about removing DeriveNormalZ? I think that would be a really bad idea unless they have some really good reason. The reason provided does not sound very good to me. Why would we remove it just because it can be done without a function? That makes no sense since by that standard there would be no material functions… ALL of them can be done inside materials without functions. But then our materials would go back to being a cluttered mess.
DeriveNormalZ is used extensively inside of many engine material functions and fortnite material functions. Removing it would be a very bad idea IMO.
