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 <robert.osfi...@gmail.com>wrote:
> Hi Brad,
>
> On Thu, Mar 25, 2010 at 8:17 PM, Brad Colbert <bcolb...@rscusa.com> 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
