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

[Julien Valentin]

Hi Robert

Thanks for this completness of your answer,
it could be usefull for others

I misinterpreted your review of my Readback callback, i though you suggested removing a drawcb from updatecb wasn't thread safe: it induces the idea there were a case (unknow to me) where draw and update were concurrents..:/ Thanks to lever this unrational doubt :)

Cheers


robertosfield wrote:
> Hi Julien,
> 
> On 7 February 2018 at 18:16, Julien Valentin <> 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.
> _______________________________________________
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  ------------------
> Post generated by Mail2Forum


------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=72955#72955