caveats: unless this changed between UE4 and UE5, you'll need a constant bias scale set to -0.5 and 2 to remap your channel values from 0:1 to -1:1 or your normal map will look wrong. if the texture has normal map compression the sampler does this automatically but if you switch to a masks sampler (which is just default without sRGB curve applied) it will cut your precision in half and only map positive values. be prepared to see a lot more blocky artifacts in your normals as well.
The precision is cut by more than half, rgb mask texture uses only 5 bits (32values) for the R channel and 6bits (64values) for the green channel. BC 7 uses 8bits (256values) for the red and green, uses no blue channel, moderns GPU can reconstruct the blue channel in a single clock but even 8bits of depth is not enough in many cases and you can often see banding artifacts on highly reflective materials. This technique is super old and it was a good technique to use when memory was a problem and when normal maps were not that important for the quality of a material since most of the lighting was prebaked in the diffuse. If someone in my team dared to do that in a production I'd fire them on the spot. The normal is, with the roughness, the most important texture when using a PBR workflow, the quality of the normal map is a top priority. If you want to save memory in a PBR workflow, halve your Albedo resolution and you won't see much difference comparing to degrading the normal map. Halving the resolution of a normal map and keep BC7 is still a better solution than this for quality (and it will use even less memory than this trick).
(you're thinking of BC5 not BC7) true about the bit-depth that was clumsy wording on my part, but eeeeeeeeehhhh not really about the normal map being objectively that much more important; That's really up to what material you're trying to replicate and how much the normal map is expected to provide on that particular model. Orienting pixel normals doesnt really have anything more to do with PBR workflow than anything else in rendering. i wouldnt outright fire someone for doing this either, that's a bit nuts. There'd be a talking-to for sure, but I'm not gonna take away someone's livelyhood for getting a wrong idea.
@@cedric7751 In this video ua-cam.com/video/uk3W8Zhahdg/v-deo.html&ab_channel=UnrealEngine Epic suggests to halve Normal maps and use a fourth for Roughness and Metalness. And I agree with them, a blurry Albedo can be seen from everywhere, while Normal and PBR values can be noticed only at specific angle and upclose.
All great points. I'm generally not a fan of compressing Normals outside of any other compression than the usual normal compression which matches the sampler expectations. Epic generally subscribes to this workflow, and it keeps things simple and predictable which counts for a lot. Memory isn't everything.
Important: if you're using this method within Material Attributes and then trying to blend them, it will result in some errors. To fix this, simple add a "Saturate" node between DeriveNormalZ and the Normal input node. Took me ages to figure out but this does solve the issue!
Hey, I don't know if you realized afterwards, but your Normalmap there is coming out completely wrong because you didn't remap the RG channels from 0/1 to -1/1 :) Moreover is worth mentioning that the reason why Normal Maps are usually compressed with only 2 channels that take up the space of four is that so they retain double the precision of the uncompressed data! Packing the channels like this is usually fine but you're probably going to notice the difference on very smooth and curvy surfaces :)
Do NOT do this. You are significantly reducing the precision of your normal maps. This will create awful blocky shading artifacts on your surfaces, it is *not* pretty, and *not* something you want to see on every material in your game. It really is better to just reduce the resolution of your texture.
I get sent videos like this often as a technical artist, because artist seek out things like this as optimizations, but in reality what you do not realize is you are losing tons of data, as well you are not allowing negative values, which are 2 of the most important things with normal maps. In this video you have halfed the quality/precision, and created an incorrect normal. I urge others to think carefully before employing a strategy like this. Can the issues be corrected? Yes. Will it look the same? No. Epic has normal map compression for a reason, just use it as designed you really are not saving what you think you are from such strategy
It makes me curious how much of an impact this makes at scale. One material / texture is practically nothing but would probably ly be much more noticeable with a few hundred materials /instances(with textures swapped) of this setup. While reducing tex memory. It increases GPU usage per frame to do that. And im curious on what those numbers would look like
I'm learning optimization that I was searching for, for months. Thank you for effort that you put in these. BTW, is there any place to check metrics for pre-optimized and optimized for each object? I mean not just for texture, but the entire object.
DeriveNormalZ is doing something very similar. It takes the red and green channels as X and Y and it calculates Z as follows 'Z=sqrt(1-(x*x+y*y));'. I wouldn't say it's more optimized, but the fact that it is already done for you is convenient. It also keeps the material graph nice and clean!
What about the performance and shader instructions? The method triples the shader count that's shown on the bottom. And as far as I know, Unreal's stats menu may show less instructions than there actually is.
Even with the added instructions it's still a cheap material by most standards and won't have a big impact on performance. If you were to view a material before and after doing this change using the shader optimization viewmode you'll notice that it only moves up slightly in complexity. The only time you would see an issue with performance using this trick would be on low end hardware such as older mobile devices, Nintendo Switch, Oculus Quest 1 etc. On those platforms you will have more strict rendering budgets and it maybe advantageous to spend those resources elsewhere. Hope that helps!
They're not look the same. The BC1 compression producing much worse results than BC5 that used on Normal map compression. So from this you will get a way worse quality normal maps with a lot of weird artefacts. Especially on noisy and smooth normal maps.
Epic should really rework the whole texture compression system, it makes no sense that a texture with just one channel is the same size as one with 3. That alone could drastically reduce the texture size without having to split textures around.
caveats: unless this changed between UE4 and UE5, you'll need a constant bias scale set to -0.5 and 2 to remap your channel values from 0:1 to -1:1 or your normal map will look wrong. if the texture has normal map compression the sampler does this automatically but if you switch to a masks sampler (which is just default without sRGB curve applied) it will cut your precision in half and only map positive values. be prepared to see a lot more blocky artifacts in your normals as well.
The precision is cut by more than half, rgb mask texture uses only 5 bits (32values) for the R channel and 6bits (64values) for the green channel.
BC 7 uses 8bits (256values) for the red and green, uses no blue channel, moderns GPU can reconstruct the blue channel in a single clock but even 8bits of depth is not enough in many cases and you can often see banding artifacts on highly reflective materials.
This technique is super old and it was a good technique to use when memory was a problem and when normal maps were not that important for the quality of a material since most of the lighting was prebaked in the diffuse.
If someone in my team dared to do that in a production I'd fire them on the spot. The normal is, with the roughness, the most important texture when using a PBR workflow, the quality of the normal map is a top priority.
If you want to save memory in a PBR workflow, halve your Albedo resolution and you won't see much difference comparing to degrading the normal map. Halving the resolution of a normal map and keep BC7 is still a better solution than this for quality (and it will use even less memory than this trick).
(you're thinking of BC5 not BC7) true about the bit-depth that was clumsy wording on my part, but eeeeeeeeehhhh not really about the normal map being objectively that much more important; That's really up to what material you're trying to replicate and how much the normal map is expected to provide on that particular model. Orienting pixel normals doesnt really have anything more to do with PBR workflow than anything else in rendering. i wouldnt outright fire someone for doing this either, that's a bit nuts. There'd be a talking-to for sure, but I'm not gonna take away someone's livelyhood for getting a wrong idea.
@@cedric7751 In this video ua-cam.com/video/uk3W8Zhahdg/v-deo.html&ab_channel=UnrealEngine Epic suggests to halve Normal maps and use a fourth for Roughness and Metalness. And I agree with them, a blurry Albedo can be seen from everywhere, while Normal and PBR values can be noticed only at specific angle and upclose.
All great points. I'm generally not a fan of compressing Normals outside of any other compression than the usual normal compression which matches the sampler expectations. Epic generally subscribes to this workflow, and it keeps things simple and predictable which counts for a lot. Memory isn't everything.
Important: if you're using this method within Material Attributes and then trying to blend them, it will result in some errors. To fix this, simple add a "Saturate" node between DeriveNormalZ and the Normal input node.
Took me ages to figure out but this does solve the issue!
I remember Tor Frick showcasing this technique back in 2010/2011 in his Modular Sci Fi Environment using a single Trimsheet. Very useful.
Hey, I don't know if you realized afterwards, but your Normalmap there is coming out completely wrong because you didn't remap the RG channels from 0/1 to -1/1 :)
Moreover is worth mentioning that the reason why Normal Maps are usually compressed with only 2 channels that take up the space of four is that so they retain double the precision of the uncompressed data! Packing the channels like this is usually fine but you're probably going to notice the difference on very smooth and curvy surfaces :)
how can I remap channels? sorry if this is a basic question.
@@re1 Subtract 0.5 and multiply by 2
@@VisualTechArt Great, thank ! Love your content btw!
Alpha channel optimization video is linked in the video description!
Wow that's a pretty big reduction, thanks for sharing this!
No problem, thanks for watching!
Do NOT do this. You are significantly reducing the precision of your normal maps. This will create awful blocky shading artifacts on your surfaces, it is *not* pretty, and *not* something you want to see on every material in your game. It really is better to just reduce the resolution of your texture.
I get sent videos like this often as a technical artist, because artist seek out things like this as optimizations, but in reality what you do not realize is you are losing tons of data, as well you are not allowing negative values, which are 2 of the most important things with normal maps.
In this video you have halfed the quality/precision, and created an incorrect normal. I urge others to think carefully before employing a strategy like this. Can the issues be corrected? Yes. Will it look the same? No. Epic has normal map compression for a reason, just use it as designed you really are not saving what you think you are from such strategy
It makes me curious how much of an impact this makes at scale. One material / texture is practically nothing but would probably ly be much more noticeable with a few hundred materials /instances(with textures swapped) of this setup.
While reducing tex memory. It increases GPU usage per frame to do that. And im curious on what those numbers would look like
I'm learning optimization that I was searching for, for months. Thank you for effort that you put in these. BTW, is there any place to check metrics for pre-optimized and optimized for each object? I mean not just for texture, but the entire object.
i thought we need to use the Pythagoras theorem for do that you do with 2 nodes, but, it's the same thing or its more optimized?
DeriveNormalZ is doing something very similar. It takes the red and green channels as X and Y and it calculates Z as follows 'Z=sqrt(1-(x*x+y*y));'. I wouldn't say it's more optimized, but the fact that it is already done for you is convenient. It also keeps the material graph nice and clean!
What about the performance and shader instructions? The method triples the shader count that's shown on the bottom. And as far as I know, Unreal's stats menu may show less instructions than there actually is.
Even with the added instructions it's still a cheap material by most standards and won't have a big impact on performance. If you were to view a material before and after doing this change using the shader optimization viewmode you'll notice that it only moves up slightly in complexity. The only time you would see an issue with performance using this trick would be on low end hardware such as older mobile devices, Nintendo Switch, Oculus Quest 1 etc. On those platforms you will have more strict rendering budgets and it maybe advantageous to spend those resources elsewhere. Hope that helps!
using the DeriveNormalZ node, it only shows the the texture in x and y coordinates only while the z is flat
Definitely going to make things lighter for lower end PC's. Thank you for sharing.
Absolutely! Glad you found it helpful.
They're not look the same. The BC1 compression producing much worse results than BC5 that used on Normal map compression. So from this you will get a way worse quality normal maps with a lot of weird artefacts. Especially on noisy and smooth normal maps.
There is no way the normal map texture size was cut in half without some sacrifice, what's the trick?
Epic should really rework the whole texture compression system, it makes no sense that a texture with just one channel is the same size as one with 3. That alone could drastically reduce the texture size without having to split textures around.
sadly