[osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

On 15 August 2016 at 13:21, Jannik Heller <scrawl at baseoftrash.de> wrote:
> As far as I'm aware, in-scene graph cameras are not supposed to be subject to threading issues and *should* be safely removable without stopping the viewer threading.

Your crash suggests otherwise :-)

I think you've hit upon a usage model that the RenderStage/core OSG
design wasn't envisaged in their design and implementation.
Specifically, the DrawThreadPerContext theading model is princpally
built around the idea that only the Drawable and StateSet leaves of
the scene graph make it into the rendering backend
(RenderStage/RenderBin) data structures and any modifications to these
are controlled using osg::Object::DataVariance(), it's assumed that
the scene graph nodes don't affect what's happening in the rendering
backend once it's built by the CullVisitor.  Here, Camera nodes are
actually part of the Rendering back-end thus breaking the assumption
of the design, this is fine as long a you don't go modifying the
Camera's or their contents which the draw traversal is running.  I
believe it would still work fine had you not shared the Camera's
subgraph so that it outlived the Camera that once owned it.

I've just done a review of the affected code in
src/osgViewer/Renderer.cpp and src/osgUtil/RenderStage.cpp and can't
spot a way of prevent the problem when you configure the scene graph
and doing the deletion the way you are doing it.  It wasn't written
for this particular usage in mind, it may be possible to retrofit
support for this but I have plenty of other tasks to get on with which
aren't quite so obscure and specific to a narrow usage model.

For yourself my original recommendations are still valid - either
stopThreading, remove the camera, then start threading, or just toggle
on/off Camera via NodeMask rather than adding/removing on the fly.
The later is my preference when doing this types of tasks as creation
and deletion of C++ and OpenGL objects is expensive so not something
you would generally want to do in a real-time graphics application.
If you don't have a real-tme graphics application and don't care about
frame-rate then just run SingleThreaded or ThreadPerCamera.

Robert.