Hi David, > The octree doesn't seem to have given me much of a performance boost in the > culling department. I am guessing this is because the leaves of the tree > contain so many geometry objects?
The octree will only help significantly when the cull traversal is a performance bottleneck and you want to cull as much as the subgraph as quickly as possible and the scene is distributed right across the 3d volume. More usual 3d worlds sit on terrain which limits the height range that things are distributed so the useful of octree is far less, and quad tree is the prefered structure of the scene graph. > I've had a read of the forum and google and have come to the conclusion I > should do something like the following to improve performance: > > 1. Group up my geometry objects to perform "batch rendering" - i.e. render > more than a single face of a single block in one go. I'd go much further than just this, batch rendering for me is pulling together as much vertex and primitive data into a single osg::Geometry as is efficient. The "as is efficient" part vary from app to app. Generally principles to follow is the all the data you are grouping together sit in the local spatial area so the bounding volume remains quick tight for the amount of vertex data in it - think about maximizing vertex density in the bounding volumes. Also consider that the OpenGL driver and graphics hardware will like batches of geometry of a thousands of vertices to tens or even hundreds of thousands, small batches such as 100 or less not efficient at all as the call overheads are very high, and very large batches such as a million vertices or more can lead to OpenGL driver and graphics hardware struggling to managing moving and storing the data around concurrently. Using bigger batches is win from several perspectives - less scene graph nodes to traverse in cull and draw dispatch, less OpenGL commands, better utilization of the graphics hardware. Put too much data together into single really large batches then you can have an impact of culling geometry, as well as potentially stall the graphics pipeline. The sweet spot size will depend upon your apps needs and the type of hardware, but you'll probably be surprised at how big the batches will be for max efficiency. > How can I do this? Do I need to create a single geometry object containing > vertex arrays etc of a whole chunk of block faces? Yep. You even better can still loads of cubes in one osg::Geometry too all with the same local area to keep the density up. If you are putting a thousand to then thousand vertices in a single osg::Geometry then you will probably be doing things pretty efficiently. > 2. Re-use a single geometry object for block faces. Apparently there is code > in osgParticle::PrecipitationEffect which does this - although I haven't > checked it out yet. You could do this, but now the geometry instancing is available in hardware you might be best to just use it instead... > 3. "Instanced rendering" I'm not sure quite what this is about, but is what > osg::Impostor does? I just had a look at osgimpostor.exe for the first time > while writing this, and it seems pretty close to what I want to achieve. Imposters are no longer something I would recommend except for some very specific applications, and even those would be best served by a custom imposter implementation. Geometry instancing is something you should look at though. Also if you don't have to use cubes then perhaps point sprites would be a useful. > I'll be digging into osgimpostor now anyway. :D A decade ago it might have been useful, but not with modern graphics cards. Have a look at osgdrawinstanced and osgpointsprite. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
