Hi Martin, On Fri, 26 Jul 2019 at 11:41, Martin Siggel <martinsiggel+...@gmail.com> wrote:
> Hi Robert, > > I had a custom camera manipulator, which was derived from orbitmanipulator. > > I experienced the issue in my Android app. I assigned this manipulator to > the osgviewer and kept a reference outside of the viewer. My idea was to > keep the current state of orbit animation and position when going back to > the app. > > However, this prevented cleaning up all the GL objects from the current > context, even though I deleted the viewer. After removing the reference to > the manipulator, everything worked as expected. > Using an osg::observer_ptr<> might be the best solution for this type of usage. > Therefore, I suppose that there has to be some reference to the camera in > the manipulator. > There isnt' any need to have an explict link to the Camera as the higher level functionality passes in the CameraManipulator::updateCamera(osg::Camera& camera) method. This means it's possible to use the same CameraManipulator with multiple Camera i.e. have multiple View's but each share the same CameraManipualator. > I could provide an example but it will be an Android example. Is there > something you could use? > I don't have a Android setup yet so such an example won't help too much. In your case I think it's just more careful management of objects that is required rather than a bug in the core OSG that needs to be resolved. This whole issue stems from a limitation with OpenGL and how you can only do clean up from a graphics thread associated with graphics context, and once a window closes it's graphics context is no longer valid so any handles you have to the objects held in that context are now invalid. This means you have to juggle who and when gets to clean up the gl objects and the handle to them. In the Vulkan/VSG the objects are mostly associate with a device context rather than a window so it's possible to have windows come and go and still manage the lifetime of the objects in a straight forward way. Or at least I've been able to hide the lifetime issue in a far easier and more robust to different usage cases way. On the OSG side it's usage cases on the edges of the usual way that the OSG does things is when problems arise. Robert.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org