Hello everybody, Can I trouble you with some questions about performance? My situation is basically this. I have a list of 54 drawables that I'm generating in-code. Not all of them are necessarily displayed on the screen at any given time, and in some cases, a certain drawables might be drawn more than once (accomplished by adding a second MatrixTransform parent above the associated Geode).
In any case, I went for a naive implementation at first. Each drawable was an osg::Geometry object attached to an osg::Geode (which again, may have one or more osg::MatrixTransforms as parents). Each osg::Geometry had its own Vec3Array as a vertex array. The performance wasn't bad. It was around 700fps in wireframe mode on my machine. But I figured I could do better. So, I groups all of the verts for these 54 drawables into a single Vec3Array that all of the osg::Geometry objects shared. The primitive set (an osg::DrawArrays) would specify which subset of the vertex array to draw. I figured this would help because it would eliminate a lot of useless VBO bindings (or whatever else is going on under the hood). However, this actually cut the frame rate by about a third. This confused me, but in a way it made sense. My new "master vertex array" has well over a million verts! So maybe the memory requirements of this outweighs the savings I get from reducing VBO bindings? So anyway, I figured it might be a good idea to try to index this geometry, to cut down on the number of verts in the vertex array. Doing this, I was actually able to cut down the number of verts to just over two thousand. That's a savings of 99.84%! Of course, now I've got 54 separate primitive sets (I had to use osg::DrawElements, because it doesn't look like osg::DrawArrays supposed indexed geometry). But since these primitive sets are essentially vectors of USHORTs (rather than vectors of Vec3's), I'm still saving a significant amount of memory (about 725,00 bytes for the Vec3's and USHORTS versus about 16 million bytes for the huge Vec3Array). Yet, the frame rate remains at about 220fps, which is significantly lower than the naive method involving 54 separate Vec3Arrays totaling 1.4 million verts! I still have a ways to go. I'm thinking about seeing if I can use a triangle strip instead of GL_TRIANGLES, to save even more on memory used for verts. However, the logic for building the meshes with triangle strips will be much tougher, and will likely require smart use of degenerate triangles. I'm happy to do the work, but before I do, I just want to make sure that there isn't something that I'm missing. I tried setting the data variance of the osg::Geometry objects to Static, hoping that perhaps if I signal to OSG that I have no intention of changing those objects, it could put it in a more-efficient memory pool (perhaps). However, that didn't seem to affect the frame rate. Any advice at all would be greatly appreciated. Cheers, Frank ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31598#31598 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
