Normal Bump textures, also known as dotproduct3 bump maps, allow a fine degree of control over the lighting of a surface. ...
The three RGB channels of the texture are used to orient the normals. ...
Normal maps come in three basic flavors: World Space, Object Space, and Tangent Space.
Height Bump textures use luminance values instead.
If you see lighting coming from the wrong angle when you're looking at your model in the game engine, and the model is using tangent-space normal maps, the game renderer might be expecting the red or green channel (or both) to point in the opposite direction. To fix this invert the appropriate channels in an image editor, so that the black pixels become white and the white pixels become black.
Games use different shader techniques to render tangent-space normal maps, but the normal map directions are usually consistent within the game. The red channel of a tangent-space normal map points the normals predominantly leftwards or rightwards (depending on the game), the green channel points the normals predominantly upwards or downwards (depending on the game), and the blue channel points the normals outwards away from the surface (all games).
Add info here: normal length = 1.0, specular artifacts, mipping problems.
If the game shader doesn't re-normalize the normal map, you can alter the blue channel for some interesting effects. If the blue channel is inverted, the normals will be pointing to the opposite side of the surface, which can simulate backlighting. If the blue channel is darkened towards black, the surface will recieve less light. An ambient occlusion pass can be multiplied onto the blue channel to store ambient occlusion in the normal map, because it is shortening the normals in the crevices of the surface.
Mirroring normal maps can be done but requires careful processing. You must mirror your UVs before capturing the normal map from the high-res mesh.
If you change the UV layout you should re-capture the normal map, because rotating or mirroring UVs after creating the normal map will cause the existing tangents/bitangents to become invalid. This special tangent/bitangent vertex data is calculated using the UV layout at normal map-capture time, so changing the UVs afterwards isn't a good idea.
If you want to mirror the UVs, or you want to reuse parts of the normal map by overlaying multiple bits in the same UV space, then simply move all those overlapped/mirrored bits one unit over on the U axis before you capture the normal map. Only one copy of the forward-facing UVs should remain in the 0-1 UV box at baking time.
Normal map-baking tools will only capture normals within the 0-1 UV box, any UV bits outside this area are ignored. If you move all the overlaps exactly 1 UV unit away (to the side or up or down doesn't matter) then you can leave them there after the bake and they will be mapped correctly. Or you can move them back if you want. Doesn't matter to the game engine.
Tangents and Bitangents
The normal map baking process doesn't just create a map... it also creates vertex data called tangents and bitangents. This vertex data is used along with the normal map to properly transform the incoming light, so your model will be lit correctly on both sides. This special tangent/bitangent vertex data is calculated using the UV layout, so changing the UVs after baking the map isn't a good idea.
The renderer (or game engine) must be aware of these tangents when it renders your model, otherwise you'll get incorrect lighting on one side of the model (in fact you'll get seams all over the place without it).
For example, 3ds Max can only render correct lighting in its scanline renderer if you use its own Render To Texture tool to create the normal map, because the Max renderer only understands its own tangents & bitangents.
Similarly a game engine can only render correct lighting when it uses the same tangent/bitangent data that was created during the normal map process.
3ds Max can properly light mirrored normal maps in the viewport if you use special shaders, like Ben Cloward's HLSL shaders or others.
World Space, Object Space, Tangent Space
World-space normal map
- Rainbow colors.
- Object cannot rotate from original orientation that the normal map was created from nor can the vertices be deformed, otherwise shading is wrong.
- Good for static game elements (buildings, etc.).
- Fastest computation time.
Object- or Local-space normal map
- Same map as world-space, just uses slightly different game code.
- Object can rotate away from original orientation, but cannot deform.
- Good for rotating game elements (doors, vehicles, etc.).
- Next-fastest computation time.
Tangent-space normal map
- Predominantly-blue colors.
- Object can rotate and deform.
- Good for deforming meshes (characters, water, flags, etc.)
- Slowest computation time (but not by much).