Jump to content
  • Advertisement
Sign in to follow this  

Cube Map Normalization

This topic is 4854 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just got started with cube map normalization and have a question about it. According the the cube map normalization, I believe, each face of the cube is at 1 unit from the cube's center. The position at which a given vector V intersects a texel on the face of the cube map is found and the vector connecting the center of the cube and the intersected texel gives the normalized vector of V. I guess so far I am correct. If not please correct me. Supposing I am correct, consider the following picture. The image below is a cross section of the cube map along the XY plane. Sorry about the messy representation. ---------------- |||||||||||||||| ---> B |||||||||||||||| |||||||.|||||||| ---> A |||||||O|||||||| |||||||||||||||| ---------------- In the above image consider 2 texels A and B at which 2 given vectors intersect the right face. A lies on the horizontal co-ordinate axis from O. Since each face is 1 unit from the origin, I can see that the length of vector OA will be 1 and so OA is a normalized vector. But, in the case of B, the length of OB is not 1 unit but > 1 unit. So OB cannot be a normalized vector. What did I miss in my understanding of the Cube Map Normalization ? Or is the cube map normalization just a fast way to get *almost* (approximated) normalized vectors ? Somebody please explain this. I would also greatly appreciated if someone can point me to some good articles on cube map normalization. I tried googling, but could not get much from it. Any help is greatly appreciated

Share this post

Link to post
Share on other sites
shouldn´t the cube map used for cube map normalization consist of colors representing the xyz-components of a vector in that direction?
Every color in that cube map represents a vector with the length of 1. The R component of the color maps to the x-component of the vector, G to y and B to z.
If you want to normalize a vector (200,0,0) you would do a cubemap lookup giving you a RGB color of (1.f, 0.f, 0.f) which you then use as xyz-coordinates of the vector.

Never done this thing before, but I think I remember seeing a cubemap image filled with some RGB gradient for that purpose when reading about it, so that would be my guess. No guarantee for correctness, though I think that should work.

Your approach would only work using a sphere around O with radius of 1. Calculating the intersection of a vector with that sphere shouldn´t be faster than the standard normalization of the vector, so I don´t think that it is used at all.

just looked around a bit and it seems I´m right, but for one thing:
in order to allow negative directions the color components represent scaled and biased values for the xyz-coordinates:
A normalized vector can have values in [-1, +1] whereas a color is restricted to [0, +1]. So the coordinates of the normalized vector in a specific direction are stored in the following way in the cubemap:
R = 0.5 * (x + 1);
G = 0.5 * (y + 1);
B = 0.5 * (z + 1);

To get the right coordinates back from the cubemap, you do a cubemap lookup using your unnormalized vector and do the following:
x = 2 * R - 1;
y = 2 * G - 1;
z = 2 * B - 1;
where x,y,z are the coordinates of the normalized vector.

[Edited by - matches81 on July 1, 2005 8:01:02 PM]

Share this post

Link to post
Share on other sites
so, you are saying that each texel in the cube map will contain in its RGB components, the normalized vector for any vector with the direction from the center of the cube to that texel and this value can be read in the shader by sampling the cube map texture and the given vector. Now I get the whole picture.

Thanks for the clarification matches81.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!