View previous topic :: View next topic |
|
Author |
Message |
mp3butcher (Julien Valentin) Appreciator

Joined: 17 Feb 2010 Posts: 511 Location: France
|
Posted: Wed Feb 07, 2018 6:16 pm Post subject: [A standardized way to mod scene graph during runtime?] |
|
|
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 |
|
Back to top |
|
 |
robertosfield OSG Project Lead
Joined: 18 Mar 2009 Posts: 12205
|
Posted: Sat Feb 10, 2018 5:13 pm Post subject: [A standardized way to mod scene graph during runtime?] |
|
|
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 |
|
Back to top |
|
 |
mp3butcher (Julien Valentin) Appreciator

Joined: 17 Feb 2010 Posts: 511 Location: France
|
Posted: Sun Feb 11, 2018 3:34 pm Post subject: Re: [A standardized way to mod scene graph during runtime?] |
|
|
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
|
|
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|
Powered by phpBB © 2001, 2005 phpBB Group
|