Hi Mark, On Jan 8, 2008 8:57 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Thanks for the example. I'll see if I can recreate the problem.
I've now recreated the problem, and established the particular failure mechanism. The OpenGL object clean up mechanism built into osg::GraphicsContext and osgViewer relies upon the viewer knowing about the complete scene graph, or for that complete scene graph to be deleted prior to closing the graphics context, in either of these instances the OSG is able to clean OK. In your example you a prevent this mechanism for working by the two steps of retaining a ref_ptr<> to the texture and removing this texture form the scene. Placing the texture creation and assignment into the scope of the viewer so it gets destroyed when the viewer is destroyed would work, or for you not to remove it from the scene graph before the viewer gets destroyed. You are in effect preventing destruction, and hiding this texture from the viewer and thereby prevent automatic clean up. You can prevent the issues in this instance by doing what the viewer/graphics context would do automatically if it still knew about the texture objects and that's to call: texture->releaseGLObjects(); Adding this after the viewer.run() and before the end of the local scope solves the problem. A 100% full proof and automatic system would require all objects with OpenGL objects to be registered with the graphics context on creation/destruction so that it keeps track of everything that comes and goes. This is not a trivial change to the internals of the OSG, and well beyond the scope of a straight bug fix. For now please just manually call releaseGLObjects() for the objects you are removing form the scene graph but retaining for your own purposes. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
