[osg-users] [A standardized way to mod scene graph during runtime?]

[Robert Osfield]

Hi Julien,

On 7 February 2018 at 18:16, Julien Valentin <julienvalentin51 at gmail.com> wrote:
> Perhaps my brain bugs,
> but AFAIK there's no way to mod a scenegraph at runtime because it's shared among threads.

What do you mean by this, as it's really just a vague statement that
could have so many different interpretations.

Most OSG applications modify the scene graph during the update or
event phases of the frameloop.  Some even modify it during cull and
draw, but these just need to be more careful to handle the possibility
of multi-threaded draw.


> Do you think a mutual exclusion "zone" should be defined in the main loop could be a good  way to proceed?
> We'd then could define a standard way to mod sg executed in the "zone"

The "zone" for the OSG is between the viewer.advance() and
viewer.renderingTraversals(), the viewer by design runs the main frame
loop single threaded and these traversals are all single threaded,
except when the DRAW_THREAD_PER_CONTEXT or
CULL_THREAD_PER_CAMERA_DRAW_THREAD_PER_CONTEXT are used, in which case
you need to set the DataVariance of the StateSet and Drawable that
contain dynamic data so that draw dispatch can hold back the main
thread till all the dynamic objects have been dispatched into the
OpenGL FIFO.

The OSG is design to multi-thread cull and draw traversals.

The OSG also is designed to have a DatabasePager for dynamically
loaded/computed new scene graph elements that are prepared in separate
background threads.

You can also create your own threads and have them do work in the
background, you just need to make sure you are modifying bits of the
main scene graph that is being rendered.

If you want some generic mechanism to allow you to modify any part of
the scene graph at any time you need to take a step back and wonder
what you are really asking for.  Any scene graph, not just the OSG,
has to create a world and capture that world that is static for the
instance in time you take the picture of it, this means that the cull
and draw traversals really need to work on a static representation
during their traversals, for this instance in time all the operations
done need to be done with a single time stamp, otherwise you'd get
different objects all moving at different points and ended up with an
unholly mess on screen.

This means that there is natural rhythm to what is done when, which is
why the OSG has a single FrameStamp that is updated by
viewer.advance() and all the update, event, cull and draw traversals
all share this same FrameStamp.  You might have multiple threads
reading or writing, by they need to be synchronized. The osgViewer
itself will provide much of this threading and high level
synchronization for you.

It's not a general purpose do whatever you want when ever you want
free for all, but it's a scene graph so it has to have this syncronity
to it.  There are exceptions that some applications might need but for
these they need to decide exactly what they need to do and when and
use their own multi-buffering or mutexing to manage it.  Since what
these exception are is completely open ended there is no way the OSG
can provide an API for it.

Robert.