ObjectSpace NormalMaps - What is the Neutral Color ? And Normalization ?

Bug

From what I think considering that it represents a vector that is packed into RGB values, it should be (0.5,0.5,0.5) Grey Color, becuse when brought into the -1/1 range it becomes (0,0,0). :thumbup:

Additional Question:
How do I normalize an ObjectSpaceNormal map in Photoshop or in 3dsMAX ?

Because when I unpack the normals : 2*texel-1 and then normalize it per pixel normalization changes the shown result, but it should be already noralized or not ?? :icon_question:

I ask this because I would like to avoid useless calculations in the pixel shader.

Thanks.

MarcClintDion

In the fragment shader the normal map is un-range compressed using the formula

normalMap = normalize((normalMap - 0.5) * 2.0);

You can leave out the * 2.0 since this component is meant to bring the vectors into -1.0 to 1.0 range. The normalization does this already so it should be redundant.

Bug

MarcClintDion wrote: »

In the fragment shader the normal map is un-range compressed using the formula

normalMap = normalize((normalMap - 0.5) * 2.0);

You can leave out the * 2.0 since this component is meant to bring the vectors into -1.0 to 1.0 range. The normalization does this already so it should be redundant.

Maybe you didn't understand the point, the objective is not to write (2*a)-1 as (a-0.5) * 2 which is exactly the same but cost more on the gpu.

Indeed simplyfying the matter:

a = tex2D()

The monomial (a - 1/2) * 2 = 2a - 1 is equivalent.

x)(2*a) - 1.0 costs 5 cycles on SGX540
y)(a - 0.5)* 2.0 costs 6 cycles on SGX540
z) a - 0.5 costs 5 cycles on SGX540
When normalizing:
1) n(x) costs 8 cycles
2) n(y) costs 10 cycles
3) n(z) costs 9 cycles

Even much worse on SGX535 (iPad/iPhone4).

So apart from being more expensive on mobile writing the monomial in the (a-0.5) form instead than (2*a) - 1.0, the objective was misunderstood.

The objective was to know if normalization in the pixel shader can be avoided to lower the shader cost.