Ok so this is one of those gaps in comprehension that I've continually suppressed until now, but I'd really like to have a better understanding: why isn't the normalized blue channel of the normal map always equal to 1?
If the normal map represents Cartesian coordinates x, y, z, given x^2 + y^2 = z^2, then z would equal the length of the vector, right? If a normalized vector's length is always equal to 1 then wouldn't/shouldn't/couldn't the B channel always equal 1 (if we are using normalized vectors anyway)?
Edit: Yeah for some reason I don't think I was thinking of the triangle as in 3D space...
Edit2: So yeah, I killed this topic pretty quickly; I apparently wasn't thinking clearly when I wrote it.
Anyways, without having this thread exist in vain, any merit to pursuing spherical coordinates? I could see the R channel storing phi and G storing theta with -1=-π/2, 0=0, and 1=π/2.
Bonuses: No matter what it's normalized, r will always be 1 in this sphere, you can combine maps with ease and without breaking anything, the B channel would be freed up without having to recalculate data (you could use it for something actually useful like having a height map in each bump texture), you would have angles already computed to use for all types of fun shader math.
Replies
So your theta-hat to Cartesian would look like this:
x=sin(theta+pi)
y=cos(theta+pi)sin(phi)
z=cos(theta+pi)cos(phi)
which simplifies to:
x = -sin(theta)
y = -cos(theta)sin(phi)
z = -cos(theta)cos(phi)
I used to think you could maybe store these values in the map itself from -1 to 1, but what you could do is store 2theta/pi in one channel and 2phi/pi in the other (values from -1 to 1), and when you import multiply by pi/2 (only about 1.5ish so you aren't making up too much info).
Starting with the pure, basic angle values rather than calculated values has many other benefits as well (some mentioned above).
If I mixed up my math at some point please let me know.