[osg-users] Adding custom updater to the Viewer

[Robert Osfield]

HI Sam,

On 28 August 2015 at 19:04, sam <brkopac at gmail.com> wrote:

> In my application class I'm currently inheriting the osg::Viewer and doing
> my own run function. It is basically a copy paste of the osg::Viewer
> function just so I can add my own custom "update" code for networking,
> entities, etc... Is there a way in osg I can do that without having to do
> this override?
>

The Viewer::run() method is just a convenience function that essential just
wraps up:

  viewer.realize();

  while(!viewer.done())
  {
     viewer.advance();
     viewer.eventTraversal();
     viewer.updateTraversal();
     viewer.renderingTraversals();
  }

In you own application you could just use this code and then insert the
updates in this main loop without the need for sub-classing.

However, if you did want to use subclassing, then Viewer::updateTraversal()
is a virtual method so you can override just this method rather than
Viewer::run(), you could then just add your updates to it i.e:

  MyViewer::updateTraversal()
  {
     // my update code here
     Viewer::updateTraversal(); // let the standard update traversal do
it's stuff
     // any more update code here if you want it..
  }

Another approach you can take is to subclass from osg::Operation to create
a operation that you can do on the viewer to get called during the update
ie.

   viewer.addUpdateOperation(new MyOperartion());

Or... use scene graph update callbacks.

You can mix and match these approaches too if you so wish.  There are lots
of different ways each with their own sweet spot for the type of operation
that you want to do, what is best all depends upon your application needs -
the OSG is used in many different types of applications so can't dictate a
single approach to updating, instead leaves the door open for you to
customize to own needs.

Robert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150831/127bd701/attachment-0003.htm>