Hi Brad, On 11/10/06, Bradford, Chase <[EMAIL PROTECTED]> wrote:
I've been playing around with the osgviewer loading very large scenes that uses LODs. I've noticed that after flying around the scene, forcing each LOD to load each of its children once, and then returning to my initial state, my frame rate drops to about 15% of its original. I'm pretty sure it's the textures using all of the graphics card's memory, because if I traverse the entire scene graph releasing all objects, the frame rate fixes itself.
Is this test of yours a path and speed that end users might take with the application, or is it your stress test? If you leave the camera at the start point for a while does framerate alter? There is a delay in the GL objects deletion when paging that is there to facilitate resue of texture objects, display lists. This should ordinarily improve performance.
After looking at the code for LODs and PagedLODs, I can't determine when the GL objects for inactive children are released. I'm sure there is a performance benefit to not immediately releasing them once a child is disabled, but I don't see how they are ever being released. Can someone explain how the LODs manage GPU resources that persist through frames?
LOD's don't know anything about OpenGL state, its a per cull mechansim. PagdLOD's are more complicated, although don't directly address state, their is an automatic child expriy mechansim. The DatabasePager has controls for how long no longer active children will kept around for. The osg::Texture and osg::Drawable headers also have functions for controlling how long OpenGl objects that have been queued for deletion and kept around. Any new osg::Texture's that look to create a new texture object can check this list first to see if it can reuse an existing texture objects. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
