Normal maps are used to give the illusion of polygon surface detail on a mesh. They can be very useful at adding detail, or look cheap and nasty.
They are usually generated from a very high polygon version of the mesh. The light source(s) of the normal map can be altered to give the sense of real polygons being effected, giving per pixel shading.
The light angle/position is determined from the RGB (and alpha?) components of an additional texture map/vertex normal/vertex light, with,
RED being the X axis,
GREEN being the Y axis,
BLUE being the Z axis.
If you can imagine a cube. r = 128, g = 128 and b = 128. This would put the light in the very centre of the cube.
r = 255, g = 128, b = 128, would put the light at the left centre of the mesh. etc etc
so 0 - 128 - 255
would be LEFT - CENTRE - RIGHT and anywhere inbetween these numbers, being inbetween those positions.
In blitz, it is very hard to get normal maps to respond to light sources effectively. The most effective way, has been to use a specially coloured cubemap, which applies the correct vector colour depending on the normals of the mesh, and works with animated meshes.
Problem is, to rotate the light source, you must rotate the cubemap, which is a fairly slow procedure, involving rendering 6 viewports (maybe less if optimised)
They are usually generated from a very high polygon version of the mesh. The light source(s) of the normal map can be altered to give the sense of real polygons being effected, giving per pixel shading.
The light angle/position is determined from the RGB (and alpha?) components of an additional texture map/vertex normal/vertex light, with,
RED being the X axis,
GREEN being the Y axis,
BLUE being the Z axis.
If you can imagine a cube. r = 128, g = 128 and b = 128. This would put the light in the very centre of the cube.
r = 255, g = 128, b = 128, would put the light at the left centre of the mesh. etc etc
so 0 - 128 - 255
would be LEFT - CENTRE - RIGHT and anywhere inbetween these numbers, being inbetween those positions.
In blitz, it is very hard to get normal maps to respond to light sources effectively. The most effective way, has been to use a specially coloured cubemap, which applies the correct vector colour depending on the normals of the mesh, and works with animated meshes.
Problem is, to rotate the light source, you must rotate the cubemap, which is a fairly slow procedure, involving rendering 6 viewports (maybe less if optimised)