[osg-users] Removing objects with shared GL state from scene graph
Robert Osfield
robert.osfield at gmail.com
Fri Jul 26 04:44:26 PDT 2019
Hi Martin,
On Fri, 26 Jul 2019 at 11:41, Martin Siggel <martinsiggel+osg at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20190726/1b72450e/attachment.html>
More information about the osg-users
mailing list