[osg-users] Best ways to render "FE" models with millions of tris and quads

Robert Osfield robert.osfield at gmail.com
Thu Nov 19 01:19:08 PST 2009

Hi Andrew,

As Bryan explains, you have stubmled upon and osg::Geometry usage
combination that forces the OSG to use OpenGL slow paths where it has
to pass the data within glBegin/glVertex/glNormal/glEnd which is very
slow for large datasets.  Display lists reduce this overhead as the GL
calling overhead is just paid once during compilation.  The reason why
the OSG is forced to adopt slow paths (glBegin/glEnd) rather than fast
paths (glVertexPointer/glDrawElements) is that there is now way to
specify per primitive attributes with GL vertex arrays.

During my work on GLES I had to replace the whole glBegin/glEnd usage
as GLES doesn't have these functions, I replaced them with a
GLBeginEndAdapter class that encodes glBegin/glEnd style usage into
vertex arrays which are then dispatched to OpenGL as a fast path -
there is still the hefty cost of all the C++ calls building the data
structures though, so alas it doesn't make it any more efficient
coping with this non optimal osg::Geometry.

Since you really want to use fast paths and flat lit traingles then it
leaves us with some achieve this.  The brute force way would be to
specify a normal per vertex, but this would lead to smooth shading -
so the next step would be to use the osg::ShadeMode StateAttribute to
set the shading to flat.  To do this you'll need to be careful about
the normal ordering so the right vertices on each triangle are set
(have a read up on GL docs of glShadeModel), even then it won't be

Another possibility would be to ditch the normals completely and
compute the lighting in a whole different way - using differed
lighting.  To do differed lighting you'll need to render your scene
into a FBO to capture the colour and depth of the scene.  Then you use
a second pass that uses the resulting depth texture of the scene to
compute the normals, and from this the lighting, and then combine this
with the base colour of the scene.

Perhaps others in the community might have other ideas of how to
achieve what you are looking for.


On Wed, Nov 18, 2009 at 10:51 PM, Andrew Cunningham
<osg at a-cunningham.com> wrote:
> OK, I think I have resolved the mystery. The VBO was being stalled by a setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE);
> If I remove that, and compare FPS,  then the VBO performance is slightly better than the displaylist version
> Why do I use setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE); Because by definition, finite element geometry is a discretized geometry, so you want each element to have one normal. You don't want to smooth the surface.
>  If anyone has a way to do that without using BIND_PER_PRIMITIVE .. let me know!
> Andrew
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=19848#19848
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

More information about the osg-users mailing list