OpenSceneGraph Forum

[mp3butcher (Julien Valentin)]

Hi,
Perhaps my brain bugs,
but AFAIK there's no way to mod a scenegraph at runtime because it's shared among threads.
What a pity
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"

Thank you!

Cheers,
Julien

[robertosfield]

Hi Julien,

On 7 February 2018 at 18:16, Julien Valentin <> wrote:

Quote:

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.

Quote:

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.


------------------
Post generated by Mail2Forum

[mp3butcher (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: Quote: 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. Quote: 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. ------------------ Post generated by Mail2Forum