#### Archived

This topic is now archived and is closed to further replies.

# Transforms, normals, and lighting

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

## Recommended Posts

I have an object under the scale transformation <1,2,1>. The shape and location of the object is correct, but lighting is not. Specifically, the diffuse shading of the object appears to move when the camera rotates. When the scale is changed to <1,1,1> this does not occur. I am doing the following in my code: - Transform ray by inverse matrix of the transformation - Test intersection - Transform intersection point by transformation (return to world coordinates) - Transform surface normal by inverse matrix - Light as normal The lighting model works fine, and the shape of the object is correct. The matrix math is fine. As near as I can tell, the problem is with the surface normal, but I can''t figure out what the problem IS. Any insight would be greatly appreciated!

##### Share on other sites
If you are using OpenGL, scalling messes up with the normals, so you should glEnable(GL_NORMALIZE);

Height Map Editor

##### Share on other sites
If you''re using DX8, you can use D3DXComputeNormals

Kamikaze

##### Share on other sites
Unfortunately I''m using a custom rendering engine at the moment, so I can''t make use of DirectX or OpenGL. Transforming normals is a piece of cake with either one :-)

I''m now transforming the normal by the inverse transposed matrix as suggested in the thread linked to in the anonymous post above [thanks btw]. This seems to have some effect on the lighting but its still off. I did find a bug in the point->world transform code I was using, so now I''ll see if a similar problem is present in the normal->world transforms.

Thanks again for the input.

##### Share on other sites
>I''m now transforming the normal by the inverse transposed matrix as suggested in the thread...

But didn''t you transform the normal using the inverse matrix before? In that case I think you should try the transposed but non inverse matrix instead.

##### Share on other sites
quote:
Original post by Anonymous Poster
>I''m now transforming the normal by the inverse transposed matrix as suggested in the thread...

But didn''t you transform the normal using the inverse matrix before? In that case I think you should try the transposed but non inverse matrix instead.

Tried the transposed pure matrix; still the same incorrectness. I don''t know if the bug is actually in the transform code; I''m beginning to suspect that it is a sign issue somewhere else in the code, because it behaves like the normal is pointing the wrong way. Agh!

Anyone?

##### Share on other sites
Someone mentioned the transpose and the inverse matrix... I assume they mean that the inverse of a rotation matrix is the transpose (correct). But that''s not the inverse of a scale matrix, the inverse is another scale matrix scale factors 1/x, 1/y, 1/z.

"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

##### Share on other sites
>I assume they mean that the inverse of a rotation matrix is the transpose (correct).

No, that was not what was meant. The inverse of any (invertable) transformation matrix can be found using standard methods. The question was how to apply a transformation matrix to a normal vector.

##### Share on other sites
OK Apoch, don''t sue me for this...

The code looks like this:

  v.x = v.x * trans.inverse.m[0][0] + v.y * trans.inverse.m[0][1] + v.z * trans.inverse.m[0][2];	v.y = v.x * trans.inverse.m[1][0] + v.y * trans.inverse.m[1][1] + v.z * trans.inverse.m[1][2];	v.z = v.x * trans.inverse.m[2][0] + v.y * trans.inverse.m[2][1] + v.z * trans.inverse.m[2][2];

"v" is a 3d vector and trans.inverse is the inverse of the 4x4 scaling matrix.

##### Share on other sites
No suing necessary... just don''t post the complete source

Just in case my dozens of checks against dozens of independent sources all came up with invalid math, does anyone see a flaw in that code?

##### Share on other sites
If this is the actual code it is quite obviously wrong. You change the value of v.x (and v.y) before you are finished using it. Use a temporary variable.

##### Share on other sites
Hmm, good point

That wasn''t the problem but there was a bug related to not transforming some things to object coordinates far earlier in the pipeline. Now its all resolved.

Thanks everyone for the input.