Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, I have more information. The GraphicsContext is only referenced by the camera when the camera is destroyed. The camera detaches itself from the graphics context in its destructor, then the camera's ref_ptr to the graphics context is destroyed, triggering the destruction of the graphics context. The graphics context calls its own close in its destructor, but by then the camera has already detached itself, so it's not helpful. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76497#76497 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, > Are the Camera's being removed from the Window before it gets closed? I have > just checked the GraphicsContext::close() method and it calls all the > Camera::releaseGLObjects(), which in turn will call the > Renderer::releaseGLObjects(), which will now call the > ObjectCache::releaseGLObjects(). After calling all the releaseGLObjects() > the GraphicsContext::close() then calls the > osg::deleteAllGLObjects(_state->getContextID()) of the context isn't shared. There aren't any cameras in the GraphicsContext's list when its closeImplementation is called. The camera is removed from that list by its destructor, and its destructor is called when the ref_ptr is set to zero in the osg::View destructor. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76496#76496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi Chris, I've reviewed the CompositeViewer::addView()/removeView() and then both look fine, for the general case I don't see anything obvious that needs adding. Calling releaseGLObjecs() isn't something I would add to removeView() as you can have multiple views sharing the same window and sharing the same scene graph so if you did call releaseGLObjects() you only have to recreate them. If the View has a GraphicsWindow/GraphicsContext of it's own when the window gets closed it should be able to do the clean up then. Would there be any value in making CompositeViewer::addView/removeView() virtual? So you can subclass from CompositeViewer and override them? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi Chris, On Thu, 25 Jul 2019 at 17:33, Chris Djali wrote: > Annoyingly, while that branch fixes the issue in my examples, it isn't > fixing it in my actual application. I guess that's an improvement :-) This change is in the OpenSceneGraph-3.6 branch and the 3.6.4-rc9 so will part of the release. > The cache gets cleared when the application exits (potentially after all > OpenGL contexts have been closed), but not when views are added to and > removed from the composite viewer, so I'm still getting the same Warning: > detected OpenGL error 'invalid value' at after RenderBin::draw(..) message. > I'm not seeing Renderer::releaseGLObjects get called ever, but I can't tell > whether it would be called if there was a view active when the application > was closed, as I'm also battling a Qt bug that causes a crash in that > situation. > Are the Camera's being removed from the Window before it gets closed? I have just checked the GraphicsContext::close() method and it calls all the Camera::releaseGLObjects(), which in turn will call the Renderer::releaseGLObjects(), which will now call the ObjectCache::releaseGLObjects(). After calling all the releaseGLObjects() the GraphicsContext::close() then calls the osg::deleteAllGLObjects(_state->getContextID()) of the context isn't shared. There might be something weird that needs fixing at my end. I can see with > tracepoints that a pair of Renderers gets constructed when the application > constructs a View and StatsHandler and they get destroyed when the last > ref_ptr to the view is destroyed, so the Renderers aren't sticking around > forever. > I don't have your application or test app with similar behavior so can't add much more. With the Qt error, it could be that the OSG integration or the OSG itself isn't doing something perfectly for this usage case so the problem pops in Qt, it could also be just a Qt bug... Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Removing objects with shared GL state from scene graph
Hi, Annoyingly, while that branch fixes the issue in my examples, it isn't fixing it in my actual application. The cache gets cleared when the application exits (potentially after all OpenGL contexts have been closed), but not when views are added to and removed from the composite viewer, so I'm still getting the same Warning: detected OpenGL error 'invalid value' at after RenderBin::draw(..) message. I'm not seeing Renderer::releaseGLObjects get called ever, but I can't tell whether it would be called if there was a view active when the application was closed, as I'm also battling a Qt bug that causes a crash in that situation. There might be something weird that needs fixing at my end. I can see with tracepoints that a pair of Renderers gets constructed when the application constructs a View and StatsHandler and they get destroyed when the last ref_ptr to the view is destroyed, so the Renderers aren't sticking around forever. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76493#76493 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-3.6.4-rc9 tagged
Hi All, Last one!! I have tagged the 3.6.4 release candidate 9. https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.4-rc9 Just a few changes, listed below. Key one is that I've tweaked how the osgTest/DefaultFont is managed, moving the instance into the osgDB::ObjectCache so it can be centrally managed, and I also wired up osgViewer/Renderer.cpp so that it calls the Registry::releaseGLObjects() and hence ObjectCache::releaseGLObjects(). These changes are done to tighten up the release of GL objects that might otherwise slip through the gaps. Please test the above tag or the OpenSceneGraph-3.6 branch and let us know of success or failure on this thread so we know how we are doing. My plan is tag the final 3.6.4 release tomorrow. Cheers, Robert. +Thu, 25 Jul 2019 14:58:17 +0100 +Author : Robert Osfield +Changed the #extension enable + +Thu, 25 Jul 2019 14:10:01 +0100 +Author : Robert Osfield +Change the DefaultFont so that it's managemed via the ObjectCache to enabl it to be release and cleared in a central manner. Added call to Registry::releaseGLObjects() to osgViewer/Renderer.cpp to enable automatic clean up of objects in the ObjectCache and hence DefaultFont. + +Thu, 25 Jul 2019 12:48:21 +0100 +Author : Robert Osfield +Added readObject() implementations + +Thu, 25 Jul 2019 10:39:34 +0100 +Author : Robert Osfield +Added ReaderWriterOBJ::readObject(..) implementations to address issue with using osgconv + +Mon, 22 Jul 2019 19:22:16 +0100 +Author : Robert Osfield +Updates for 3.6.4-rc8 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I'm writing a Siggraph BOF presentation, what do you want to know?
Hi Mike, On Wed, 24 Jul 2019 at 23:44, Michael Weiblen wrote: > Is VSG in-scope for the OSG BoF? :-) That's my focus of interest! > Well I'm writing what I've been busy with over this year so it's two OSG stable maintenance releases and the rest is VSG :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
