# OpenGL Scaling Normals

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

## Recommended Posts

I was thinking about this common scenario: You scale your geometry with a scaling matrix, but then your normals get scaled as well. This results in incorrect lighting. To combat this, we could use D3DRENDERSTATE_NORMALIZENORMALS (idk what the OpenGL equivalent is), but this is computationally expensive. Why doesn't Direct3D/OpenGL let us provide two world transformation matrices, one for vertices and one (unscaled) for normals? I think it would be faster to normalize a matrix once, then apply it to all normals, than to apply a scaling matrix to all normals and then re-normalizing them.

##### Share on other sites
Thats a darn good question

##### Share on other sites
Another reason to leave behind the fixed-function pipeline and move on to shaders =D
In a shader-based system you can use as many matrices in as many ways as you like.

Some other fixed function graphics APIs (e.g. on game consoles) do allow you to specify 2 versions of the same matrix - the full matrix for transforming positions, and a scale/translation free matrix for transforming normals.

##### Share on other sites
Quote:
 I think it would be faster to normalize a matrix once, then apply it to all normals, than to apply a scaling matrix to all normals and then re-normalizing them.

Matrix = Scale * Matrix * InverseScale

No need, just pre and post mult the scaling + inverse scaling matrix (might be the other way around depending on the matrix order of your maths lib). points and normals get scaled, however the normals get left unit length.

Things can get a bit more tricky if you are using scaling within a bone hierarchy. In those cases you normally correct with the inverse parent scale, unless the transform is at the end of a chain.

1. 1
2. 2
3. 3
Rutin
15
4. 4
khawk
13
5. 5
frob
12

• 9
• 9
• 11
• 11
• 23
• ### Forum Statistics

• Total Topics
633665
• Total Posts
3013241
×