Building a object space normal map

    (P being the pixel location of the heightmap)         h2         |    h3 - P - h1         |         h4

BYTE heightmap[WIDTH][HEIGHT];float H1, H2, H3, H4;Vector normalmap[WIDTH][HEIGHT];for(int y=0;y<HEIGHT;y++){  for(int x=0;x<WIDTH;x++)  {    if(x<WIDTH-1)      H1 = (float)(heightmap[X+1][Y] / 255.0f);    else      H1 = (float)(heightmap[X][Y] / 255.0f);    if(x>0)      H3 = (float)(heightmap[X-1][Y] / 255.0f);    else      H3 = (float)(heightmap[X][Y] / 255.0f);    if(y<HEIGHT-1)      H2 = (float)(heightmap[X][Y+1] / 255.0f);    else      H2 = (float)(heightmap[X][Y] / 255.0f);    if(y>0)      H4 = (float)(heightmap[X][Y-1] / 255.0f);    else      H4 = (float)(heightmap[X][Y] / 255.0f);    normalmap[X][Y] = Normalize( new Vector( (H3-H1), (H4-H2), 2.0f ));  }}

Original post by MattWhite06
Oh, just to note too that [(h3 - h1), (h4 - h2), 2] works if your terrains "up" is the positive Z axis. For a up direction in the positive Y axis, use [(h3 - h1), 2, (h4 - h2)] instead.[/quote

So, I just need to store each normal as a texture converting each element to the range 0 to 255 right ?
Another question is how can i use it in my vertex and pixel shaders... In my terrain (this is for a terrain engine) I'm not sending the vertex normal to the shader. As i have one light positioned in world space I know that with a tangent space normal map i would need the TBN matrix to convert the light to tangent space to do the lightning calculations.
As this is an object space normal map my doubt is if i need to make any transformation of light vector and if yes how can i do it.

By the the way tnks a lot for all the answers

Quote:

Original post by MattWhite06 Yeah. To convert the normal (or infact ANY normalised vector) to a 0-255 RGB format, you can simply add 1.0 to each element (XYZ) then divide by two. Because a normalised vector's elements will always be between -1 and 1, this operation will rescale them to between 0 and 1. You can then typecast them to the BYTE format and store then as 3 BYTEs and thus an RGB format (a normalmap texture). To covert from RGB to a vector, the reverse operation can be performed (multiply by 2 then subtract 1.0). This normalmap can then be used in by your shaders in various ways. Either pass the normal directly to the vertex shader through the vertex declaration, or if you do create a normalmap texture, pass it to the pixel shader via texture coordinates. The way i would do it would be to find the Light - VertexPos vector per vertex in your vertex shader. You can then normalise it and encode it (as mentionend previously) into a set of the vertex's texture coords (or COLOR property if free). In a second set of the vertice's texture coords, store the vertice's pos (X and Z) divided by the terrain's actual size. This will give you 2 values between 0 and 1 which represent which texel to sample from the normalmap for the vertex. In the pixel shader, decode the toLight vector and the sampled normal from normalmap texture, using this second set of texture coords. You can then dotproduct both these vectors for your lighting etc. I'll try some sample code to explain this... Vertex Shader *** Source Snippet Removed *** Pixel Shader *** Source Snippet Removed *** There are many variations and optimizations for this, but hope it gets the jist of the idea across. And yes, because you're storing the normals in object space, you don't need to worry about a TBN matrix. Tangent/texture space normals are useful for objects which rotate, as the orientation of the faces can change. Because we don't usually rotate terrain, object space is sufficent, and faster, for storing the normals, as it skips the TBN matrix part completely. Anyways, hope this makes sense and helps.