[osg-users] Correct way to modify scene graph [SEC=UNCLASSIFIED]

[Robert Osfield]

Hi Russel,

On 9 November 2017 at 03:49, Thamm, Russell
<Russell.Thamm at dst.defence.gov.au> wrote:
> Currently, if I want to actually modify the scene graph (adding, deleting
> nodes etc) while the render thread is running I do the following:
>
> parentNode->setNodeMask(0);
>
> modify scene graph below parent node
>
> parentNode->setNodeMask(~0);
>
> This seems to work but is there a better way?

OpenSceneGraph is quite a different beast to plib so there will be
quite a few advanced scene graphs concepts that you will likely need
to learn as you transition, this can be quite daunting but hopefully
it'll make sense once you work progresses.

The OSG osgViewer frame is broken down and managed in such a way a to
enable multi-threded, multi-graphics context/window/pipe usage, the
update, event traversals are all run from the main thread, it's these
phases of the frame that nodes of the scene graph would be modified.

The rendering traversals phase pairs cull and draw traversals for each
viewer Camera, these may be run SingleThreaded, CullDrawPerContext,
DrawThreadPerContext or CullTheadPerCameraDrawThreadPerContext
threading models (you set this with viewer.setThreadingModel().

For the SingleThreaded and CullDrawThreadPerContext the next frame is
held back till all the geometry and state data has been dispatched
into the OpenGL FIFO, so anything directly after the viewer returns
from viewer.renderingTraversals() you can begin modifying all parts
the scene graph without any worry about other per graphics context
threads running as they will all be iddlying waiting for the next
frame,

For DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext
threading models the next frame is allowed to commence as soon as all
of the DYNAMIC Geometry and StateSet in the rendering backends data is
dispatched into the OpenGL FIFO.  None of the internal nodes of the
scene graph are recorded into the rendering backend data structures so
you can actually modify these as soon as the cull traversal is
complete.  In general though one should still just wait till
renderingTraversals is complete before you start modifying - basically
keep things simple where possible, and only try to start to be
"clever" once you know that the defaults aren't going to perform well
enough.  For the vast majority of OSG users they don't need to try to
implement extra complicated code to manage scene graph updates.

For you I'd recommend just starting with updating nodes in the update
phases, and if you are updating osg::Geometry or osg::StateSet
contents then simply set the DataVariance property of these objects
you are dynamically updating to DYANMIC so the draw traversal knows to
hold back returning from renderingTraversals() till all these have
been updated.

Robert.