This raises the question, when running in the different threading modes, ThreadPerContext, etc., is it safe to modify the graph in the update traversals or could there be a rendering thread working on the graph? I would assume the update phase is safe from conflict, but it's not clear.
John On Fri, Mar 26, 2010 at 4:53 AM, Robert Osfield <[email protected]>wrote: > Hi Brad, > > On Thu, Mar 25, 2010 at 8:17 PM, Brad Colbert <[email protected]> wrote: > > Where is the best place to update application level things before the > > frame is drawn? (ie. network reads/writes, model updates, text > > setting... ) > > The answer will depend upon your viewer/application and the scene > graph you are trying to modify. The OSG has a update traversal that > calls update callbacks on node, drawables, statesets and > stateattributes so you could attach an update callback for this. > > There is also support for in osgViewer::Viewer/CompositeViewer for > attaching a custom osg::Operation that called on every fame. You > simply subclass form osg::Operation and implement the virtual void > operator () method, then attach this via > viewer.addUpdateOperation(pointerToMyOperation); > > Finally you have control over the frame loop in you application so > outside of calling viewer.frame() you can do you updates. If you are > presently using viewer.run() for the frame loop you can break it down > in to it's constituent parts (have a look at the source code): > > viewer.run() > > is equivialant to : > > viewer.realize(); > while(!viewer.done()) > { > viewer.frame(); > } > > Which can be further broken down in to: > > viewer.realize(); > while(!viewer.done()) > { > viewer.advance(); > viewer.eventTraversal(); > viewer.updateTraversal(); > viewer.renderingTraversals(); > } > > You can place you own update could into these frame loops where you > find appropriate. > > Another possible route is to subclass from > osgViewer::Viewer/CompositeViewer and override the updateTraversal() > method then frame() or run() will call the you own code. > > Finally, in you are doing IO operations then you are typically best to > put these in an separate thread than one that runs the frame loop as > IO operations can be prone to high latencies that can cause frame > breaks. > > Robert. > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
