RE: [osg-users] Is OSG threadsafe yet?

[Drolet, Frederic (LTI)]

Helle Robert,   As an example, we have an haptic thread running with the Newton physic engine. When the haptic hand is approaching an object, we want to highlight a bounding box (osg::Box in a geode) around the object. To do so, we initially set the node mask of the bounding box to x00 to make it invisible. When the object is “selected” as we call it, we set the color to the appropriate selection context and put the mask back to xFF.   We also have some events which can come from a network thread like “create object” and “remove object”. These events would modify the scene graph hierarchy asynchronously.   Position and orientation are easier to put into a standard format for every module that we have so every node simply request an update during the update callback and apply matrices at the right time. So, there is no problem for that. However, other properties like colors, shapes and hierarchy are more complex to standardize over a network.   I suppose that a state modification like the mask is threadsafe but the scene graph hierarchy modifications are not. Am I right?   Thanks!   Frederic   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 4:05 PM To: osg users Subject: Re: [osg-users] Is OSG threadsafe yet?   Hi Fredric, Pretty well all the examples in the distribtion are capable running multi-threaded multi-pipe out of the box, I run this way on my dual core, dual graphics card system every day. There is also the database pager which is designed from the ground up to work in a background thread.  The design is such that the updating of the main scene graph is all done single threaded, with a thread per camera running cull-draw pairs in parallel.  The database pager works on a seperate subgraph, and when ready merges it with the main scene graph during the update phase. All this is done safely with all the criticial parts syncronized to prevent threading issues. Now if you a question about general thread safety its a different story, the OSG is very much not thread safe in a totally general purpose way, and we'd be made to try and implement such a scheme as it would totally kill performance having to mutex lock practically all ops on the scene graph. So if you say what type of operations you want to do in parallel and we'll be able to tell you if that'll fit nicely or you'll need to refactor. Robert. On 9/13/06, Drolet, Frederic (LTI) <[EMAIL PROTECTED]> wrote: Hello everyone,   I just read a message in the archives from 2004 about how to protect the scene graph from external threads. In my application, all heavy computational work is done in another thread than OSG and I want to modify the scene graph asynchronously. You mentionned two solutions : locking the whole tree between frame() and sync() or having a copy of the tree and apply changes when it is appropriate. While the first approach is really bad for performance since the modifying threads will have to wait the end of each frame for every updates, the second one can also be very expensive if the scene graph is large. The compromise solution would be to keep a copy of the data into each node and only apply changes to a specific node when it is appropriate instead of the whole tree at every frame. I know there is still the problem of hierarchy changes (if the parent or children of a node are changed) but it would be easy to do so for states and attributes. I was wondering if this stuff has been done since 2004. If not, I can still do it on a higher level by keeping 2 copies of each displayed node into a group but I think it would be better if the low level code was doing that itself ! I just wanted to know if it was done before doing it myself.   In fact, all this message was only for a simple question : is OSG has been modified in any way to be threadsafe since 2004 ? Is that a feature you want to include in the future ? I understand that it is not necessary to do so if the application is controlled entirely by OSG but it could be interesting to have a threadsafe scene graph for external modules (and threads) integration.   Thanks for your time !   Best regards,   Frederic Drolet _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/