Whats blue channel for on a normal?

JO420

Hey anyone know whats the purpose of a blue channel on a normal,one of my collegues is working on a normal with no blue channel info on it for some odd reason and noone here seems to know its purpose.

KDR_11k

It's the third dimension of the normal. In theory you can compute it at load time if you assume all normals face towards the forward hemisphere but that wastes time (requires one square root operation per pixel) at load.

MoP

It usually implies visual depth. 255 blue tends to be standard, as it gets darker the shading will get darker on the normalmap, gotta be careful though because it'll go right down to black shading in-game and it'll look rubbish

KDR_11k

MoP: It's the depth of the vector, not the surface. The vector always has length 1 since the lighting algorithm expects a normalized vector. It gets darker the more the bumpmap normal deviates from the surface normal. Two parallel surfaces will have the same blue value no matter what their difference in depth is.

SHEPEIRO

this is why i dont understand the need or use for the blue channel, surely the green and red values when combined do the same thing,

im sure there is a tech reason, but its lost on me, probably why people do think it marks depth

KDR_11k

The vector has to be 3d. The third value can be computed if the other two are known and you assume it to be in one hemisphere but you cannot do that at render time because it eats too much time. You could compute it at load time but that would increase load times for your game and there's just no reason for that because the blue channel is in the TGA anyway so why not use it when it's there?

CrazyButcher

[ QUOTE ]
you cannot do that at render time because it eats too much time.

[/ QUOTE ]

actually to save memory and crunch in even bigger textures, exactly that is done today. However for the early generation cards it was better to avoid computations in pixelshaders.

because the dot product for the lighing normally needs normalized vectors, if the RGB (XYZ) Vector of the normal map is actually shorter/longer it will change the influence of light as well. So if the vector is shorter than unitsize, you will get darker values, else brighter. which can be useful to "darken/brighten" certain areas.

Whargoul

On the 360 the hardware will calc the value very fast, when using their special DXN format (two 8 bit channels). Basically the same size as a DXT1 texture, but double the bit depth, and almost free calculation of the third channel.

SHEPEIRO

i think i get it now, so the blue is almost like a pre-calculated red and green channel?

or have i said sommit stoopid again.

Whargoul

No, it's the 3rd part of the information in a normal map.

You know how in a colour map, the image is made of Red, Green and Blue information? Well, in a normal map the information is a vector, and there are three components to the vector, the X, Y and Z.

Think of the normal map as a grid full of sticks, one in the middle of each pixel. The normal map tells each stick how to lean. The Red is the left/right lean, the Green is the up/down, and the Blue is the height of the tip of the stick off the plane.

If we assume that the normal is normalized (the stick has a length of 1), then we can calculate the height from the other two. Blue = ( (Red+Red)^2 + (Green+Green)^2 ) ^ 1/2

And yes, it's worth it to not store the channel on consoles! Memory is limited, and big normal maps eat memory. It's way better to re-calculate it every time the pixel is rendered (not just at load time - that would destroy the benefits of it). Like I said, the 360's hardware will do the work for you when you sample the texture, given you back a full vector automatically.