[osg-users] Computing Normals for Drawables

Jean-Sébastien Guay jean-sebastien.guay at cm-labs.com
Fri Nov 6 11:00:31 PST 2009

Hello James,

> So would you happen to know if there is anything I can do (bar PagedLOD) to reduce the memory consumption in this application? I was hoping to target the normal generation and output one normal per triangle as opposed to one per vertex, as this would shave a few hundred megabytes from the app when under load. 

Well, I don't have anything to add. Your requirements are interesting, 
and you can certainly try generating normals per primitive to see if 
you'll get fast enough results make the savings in memory worth it. If 
you have 20 million vertices in view at all times I can't see how 
rendering on the slow path would yield a usable frame rate, but it might 
be good enough for your needs, I wouldn't know. Try it and see.

If you're not concerned with lighting quality, why do you even need 
normals? You could just disable lighting on your objects and do away 
with normals entirely...

Here's another trick you could do, if you want lighting on, but this 
would require using shaders. Remove your normal arrays, encode the 
normals as theta+phi angles (2 floats instead of 3, and can even be 
quantized into 2 half-floats which would physically take up only one 
32-bit float per vertex) in a texture or vertex attributes, and then 
calculate the vertex normal from this in the vertex shader. The 
calculation in the shader is trivial, so the question is whether 
generating the normals normally (SmoothingVisitor) and then encoding 
them when a model is loaded would be too time consuming (note you could 
do this as a pre-process before loading the model, and then save the 
objects that way and as long as the user doesn't change them, you 
wouldn't have to re-do this step each time).

Hope this helps,

Jean-Sebastien Guay    jean-sebastien.guay at cm-labs.com

More information about the osg-users mailing list