View Full Version : Do I need to re-compute vertex/surface normals?
I'm sucessfully using glDrawElements in a Display List to draw vertices, normals and textures.
Question 1) If I go through the vertex array and apply a scaling factor (i.e. 1.333) to each vertex, do I need to go back and re-compute the vertex normals?
Question 2) Should I even be scaling this way at all? Is glScale before calling the above Display List as/more efficient?
Thanks for any insights!
05-29-2003, 10:12 AM
Changing the location of your vertices isn't going to change the length of your normals, which should all be a length of 1. Multiplying them by the same number would be a uniform scale, so no, you wouldn't have to re-compute the normals.
Vertices are multiplied by the matrices anyway, so using glScale would probably be a bit more efficent than going through and multiplying all your vertices. With glScale, you just do a single additional matrix multiplication for everything.
However, normals are multiplied by the inverse of the modelview matrix, so if you've applied a scale to them, they will no longer be a length of 1.
That's where glEnable(GL_NORMALIZE) comes in. It will set them back to a length of 1 for you. This will affect performance somewhat. Will it affect it more than multiplying all your vertices by your scale factor yourself? It's hard to say. You should do some benchmarking to see which is faster if you're that concerned about performance. My guess is that either way will provide acceptable performance, though.
Edit: Re-read your post and noticed you said something about display lists. If you are doing the scale and re-building the display list frequently, then I'd say that using glScale and glEnable(GL_NORMALIZE) would probably be more efficient. Compiling the display lists can take a bit of time.
[This message has been edited by Deiussum (edited 05-29-2003).]
Thank you very much for your well considered post!
I can see a marked performance boost in my apps near future.
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.