normal map????

A normal map typically is just a texture indeed, where the normal's xyz coordinates are encoded in the texture's rgb components. So from a coding perspective, handling a normal map is pretty much the same as handling a typical diffuse texture, up to the point where you use it.

A normal map stored in such a texture has to be translated to the so-called tangent space, which is a seperate coordinate system per vertex. Conceptually this will will make the normal map relative to the existing vertex normal, which is necessary to properly use the normal map for all sides of the object, no matter which direction these are facing. Object space normal maps probably are defined in object space for the whole object, so they don't need the translation to tangent space, but I've never seen these used before.

You can find more information on these concepts in this excellent article on Phong illumination (pages 4-6).

Quote:

Original post by remigius A normal map typically is just a texture indeed, where the normal's xyz coordinates are encoded in the texture's rgb components. So from a coding perspective, handling a normal map is pretty much the same as handling a typical diffuse texture, up to the point where you use it.

Although this is true, there's a visible quality increment in managing normalmaps explicitly. More specifically, you cannot easily mipmap normalmaps. Altough renormalizing normal mips cuts it, rebuilding each normal mip from the height mip (which is easily mipmappable) is The Right Way.

Quote:

Original post by remigius A normal map stored in such a texture has to be translated to the so-called tangent space, which is a seperate coordinate system per vertex.

This is also true, but speaking about conversion to tangent space is somewhat like opening a can of worms.
The easiest way to build a tangent space normal map is to simply look at each heightmap pixel and consider its neightbours. The height difference will make the normal component for that coordinate. This effectively computes XY components. The Z is simply set so the normal is unit length. I believe this is easier.

Quote:

Original post by remigius Object space normal maps probably are defined in object space for the whole object, so they don't need the translation to tangent space, but I've never seen these used before.

I fear I'm misuderstanding you there.
Tangent space normalmaps are encoded in tangent space by definition. The transformation they undergo is to transform the canonical tangent space in the one used by the surface/evaluated pixel, like using Rotate or Translate to put your objects in the world.
Object space normals as far as I know (but I've never really looked in them so take this with some salt) were used for NV1x products and are not reccomanded anymore, usually because they take much more memory. Someone will likely provide additional informations here.
Anyway, if you use object normals then you have two cases:
1- You transform each light, ray and position to object space.
2- You transform the object space bump into another space (the same used by the calculations). This is what old games did as far as I remember.

The bottom line is that object normalmaps also needs to be xformed in a way or the other (unless you use 1, which also takes a bit of care) to consider the object in the new space, which is not its canonical one. Just as tangent space normalmaps.

Tangent maps however are easier to manage. They eat memory linearly with textures (instead of object complexity) and share tcCoords with base coordinates (instead of needing a unique uv mapping) at the cost of the TBN basis per-vertex. This however gives the opportunity to render all the objects you need theorically in a single batch, in contrast to require several CPU GPU syncs.

My apologies if I've been that unclear :)

By translating the normal maps into tangent space, I meant transforming them in the pixel shader while rendering. Other than that, I'd say we're on the same page.

Yes, I see we're really saying the same thing now.