OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

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


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 423
Location: France

PostPosted: Wed Feb 07, 2018 6:16 pm    Post subject:
[A standardized way to mod scene graph during runtime?]
Reply with quote

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 Sad
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
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11802

PostPosted: Sat Feb 10, 2018 5:13 pm    Post subject:
[A standardized way to mod scene graph during runtime?]
Reply with quote

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
View user's profile Send private message
mp3butcher (Julien Valentin)
Appreciator


Joined: 17 Feb 2010
Posts: 423
Location: France

PostPosted: Sun Feb 11, 2018 3:34 pm    Post subject:
Re: [A standardized way to mod scene graph during runtime?]
Reply with quote

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 Smile

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
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

Similar Topics
Topic Author Forum Replies Posted
No new posts Positioning a Camera relative to anot... Takarashy General 0 Thu May 24, 2018 8:27 am View latest post
No new posts Adding primitiveset in runtime sergio2k18 General 7 Tue May 01, 2018 9:12 pm View latest post
No new posts Rendering a scene to texture JoseMan General 4 Sun Mar 18, 2018 10:12 am View latest post
No new posts How to Save and Load the current scen... blackball General 1 Mon Dec 11, 2017 5:52 pm View latest post
No new posts Unable to load texture in the same fo... EonStrife Plugins [osgPlugins] 3 Mon Nov 27, 2017 2:37 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP