• Hello Guest!

    We have recently updated our Site Policies regarding the use of Non Commercial content within Paid Content posts. Please read the new policy here.

    An offical announcement about this new policy can be read on our Discord.

    ~The VaMHub Moderation Team
  • Hello Guest!

    We posted an announcment regarding upcoming changes to Paid Content submissions.

    Please see this thread for more information.

Normal Maps in VAM 101

Guides Normal Maps in VAM 101

kemenate

Active member
Featured Contributor
Messages
84
Reactions
1,181
Points
33
Twitter
kemenate_VAM
Patreon
kemenate
kemenate submitted a new resource:

Normal Maps in VAM 101 - I just spent 1h scratching my head so you don't have to.

A short guide to help you troubleshoot your Normal Maps. It assumes that you already know what a normal map is and that you have yours in the correct space (tangent vs world space and so on). Feel free to comment when you have correction, additions, questions.

There are a few ways to encode normal maps. I exported mine from Blender and made some in Photoshop. They looked okay, but at a closer examination there was something not quite right with both versions. So here is how exactly a normal...

Read more about this resource...
 
Great!
For those who use Gimp select the checkbox "Flip Y" in the normal Map window in order to invert the green channel.
Gimp.png
 
To be honest, I'm skeptical about the value of normal maps considering their substantial file size and the increased memory usage, which could potentially make the game more likely to crash.

While they do offer a slight visual enhancement, they come at the cost of significant storage space and potential delays in loading times. Therefore, it's essential to think twice before incorporating them. (Btw, I'm particularly eager to see a plugin that could automate the removal of normal maps from saved presets and .vars files, or prevent them from loading in a scene. Since manually removing them from every look can be quite time-consuming.)

This is an aspect that I believe should be integrated into the guide, providing guidance on when to use normal maps effectively and when it's best to avoid them.

For example, in situations where you're capturing photos and aiming for the best visual quality, normal maps may be a sensible choice. They can indeed elevate the visual appeal of your shots. However, it's crucial to remember that, in a gaming context, the increased memory usage they bring along might still pose a risk of game crashes, making their use a trade-off between visual quality and system stability.
 
@brasileirinho
It looks like the guide creator is no longer active on the Hub.

Memory is most likely only a problem on older low VRAM graphic cards. Normal maps do not consume more VRAM than any other texture. Not using normal maps would be worse for performance, because we would need to process MUCH higher polygon 3D models to compensate for the detail loss.
But yeah, in general textures are eating storage space and memory like crazy.

I think there are two common misconceptions:
  • The wrong assumption that normal maps always have a larger file size than other textures. Maybe this comes from Substance. The default normal export settings are 16 bit. Overkill in my opinion. Only needed if you're a professional VFX artist or similar. Set it to 8 bit. I have not verified this, but the higher 16 bit precision is probably wasted anyway. VAMs texture-loader may only process the texture as 8 bit. PNG-normal maps tend to compress very bad. They are intended to store details. Diffuse texture usually have some flat colored areas that compress better. So on a drive they appear smaller, which brings me to the next point ...
  • The wrong assumption the file size on the disk equals the file size in memory. All textures are converted by VAM into the DXT1 or DXT5 format and cached to be ready faster next time. This conversion makes VAM take longer when a texture loads for the first time. The actual amount of memory a texture will consume loaded in VRAM can be checked in VAMs Cache\Textures.
    • The .vamcache is raw DXT1 or DXT5 data. This file size is the amount of VRAM it will consume. Wikipedia S3 Texture Compression
    • The .vamcachemeta are json- / text-files with size and texture format info.
    • Even in RAM the pixel data is always uncompressed to access it.
Optimization to lower a normal map file size:
  • The Alpha channel for transparency is useless and should be removed.
  • Set unused parts of the normal map to black. By unused I mean the texture parts that are not used by the UV. Should compress better.
  • Run the PNG-file through an optimizer tool like for example PNGcrush. There are a ton of other similar PNG tools. I use this one with .bat-file where I just drop files on to 'brute force' compress them to the smallest possible size: pngcrush -brute -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text -rem time %1 "%~n1_crushed.png"
 
Last edited:
@brasileirinho
It looks like the guide creator is no longer active on the Hub.

Memory is most likely only a problem on older low VRAM graphic cards. Normal maps do not consume more VRAM than any other texture. Not using normal maps would be worse for performance, because we would need to process MUCH higher polygon 3D models to compensate for the detail loss.
But yeah, in general textures are eating storage space and memory like crazy.

I think there are two common misconceptions:
  • The wrong assumption that normal maps always have a larger file size than other textures. Maybe this comes from Substance. The default normal export settings are 16 bit. Overkill in my opinion. Only needed if you're a professional VFX artist or similar. Set it to 8 bit. I have not verified this, but the higher 16 bit precision is probably wasted anyway. VAMs texture-loader may only process the texture as 8 bit. PNG-normal maps tend to compress very bad. They are intended to store details. Diffuse texture usually have some flat colored areas that compress better. So on a drive they appear smaller, which brings me to the next point ...
  • The wrong assumption the file size on the disk equals the file size in memory. All textures are converted by VAM into the DXT1 or DXT5 format and cached to be ready faster next time. This conversion makes VAM take longer when a texture loads for the first time. The actual amount of memory a texture will consume loaded in VRAM can be checked in VAMs Cache\Textures.
    • The .vamcache is raw DXT1 or DXT5 data. This file size is the amount of VRAM it will consume. Wikipedia S3 Texture Compression
    • The .vamcachemeta are json- / text-files with size and texture format info.
    • Even in RAM the pixel data is always uncompressed to access it.
Optimization to lower a normal map file size:
  • The Alpha channel for transparency is useless and should be removed.
  • Set unused parts of the normal map to black. By unused I mean the texture parts that are not used by the UV. Should compress better.
  • Run the PNG-file through an optimizer tool like for example PNGcrush. There are a ton of other similar PNG tools. I use this one with .bat-file where I just drop files on to 'brute force' compress them to the smallest possible size: pngcrush -brute -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text -rem time %1 "%~n1_crushed.png"
Cool insights!

I appreciate your attention to detail in addressing common misconceptions
 
Back
Top Bottom