[osg-users] Recommended way to render a scene from multiple independent viewpoints

Tue Apr 11 13:54:04 PDT 2017

Robert

Thanks so much for your help. That makes a lot of sense. I'll go implement
the approach where the traversal is stopped at the shared subgraph root.

Regards
Hannes

On Tue, Apr 11, 2017 at 8:08 PM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> HI Hannes,
>
> The osgViewer has a mechanism for avoid multiple traversals of shared
> scene graphs if mutlple View's share the same root node of the scene
> graph.  If shared component isn't the topmost node then the OSG has no
> straight forward way to know whether a subgraph has been traversed or
> not that frame.  One could implement a mechanism to avoid this
> visiting a node multiple times in one frame but it would be really
> costly to do, an expense that would only be a benefit for a very small
> number of users, but would slow performance for everyone else.
>
> The most efficient way to avoid this multiple traversals issue is to
> implement to have a custom callback that is tailored to the specific
> usage case that a user has.  I don't know enough about the specific
> callbacks and scene graph set up you have so I can't pinpoint the best
> route.
>
> If you have a shared subgraph that you don't want traversed multiple
> times per frame then use an UpdateCallback that has a frameNumber
> member variable that keep track of the the frameNumber (use
> NodeVisitor::getFrameStamp()'s FrameNumber) of the last traversal,
> when a traversal calls the update callback you only traverse the
> subgraph if the frameNumber is different and then set the frameNumber
> to the present frame,  if the frameNumber is the same then you just
> return immediately.  This custom UpdateCallback you'd place as high as
> you can in your scene graph to make sure the traversal stops as soon
> as possible.
>
> Another approach is to move this frameNumber tracking into your
> existing update callbacks, and simple return right away with the
> frameNumber is the same.  This requires a small tweak to the callbacks
> but is such a small change it's generally pretty easy to integrate.
>
> Finally you can simple make your callbacks resilient so that the are
> no ill effects from being called multiple times.
>
> Robert.
>
> On 11 April 2017 at 18:48, Hannes Naude <naude.jj at gmail.com> wrote:
> > Thanks Riccardo and Robert for your inputs.
> >
> > Robert, yes you are correct that the only issue I had with the
> > CompositeViewer was that the same Node's callback would get called as
> many
> > times as views that it appeared in. This means that for example if I
> have a
> > simple update that would translate a node a fixed amount, then nodes that
> > appear in mulitple views would move faster than those that appear in a
> > single view only. Also, as I add more cameras nodes end up moving faster.
> >
> > Obviously I can fix this in the update callback itself, by checking
> > something like simulationTime (and I would ultimately have to do this
> anyway
> > to make my motion happen at the same speed, irrespective of frame rate),
> but
> > I would prefer to not have the callbacks called at all when not required.
> >
> > Incidentally, I found that the (non-composite) viewer did not immediately
> > solve this. It would only go away if all my cameras shared the exact same
> > root node. Now I have some symbology that I wish to display on one
> camera,
> > but not the others, but I managed to achieve this by setting the nodemask
> > appropriately.
> >
> > I am not really doing anything fancy with the callbacks. I created a
> class
> > which extends osg::Callback and overrode the run method to update a
> > MatrixTransform node (via getMatrix and setMatrix). I then created
> another
> > class which extends MatrixTransform and in the constructor I call
> >
> > this->setUpdateCallback
> >
> > providing an instance of my callback class as the argument. Now whenever
> I
> > add an instance of my MatrixTransform class to the scenegraph, it
> implements
> > the motion I want.
> >
> > This seems to work, except for the multiple update problem.
> >
> > Hannes
> >
> >
> > On Tue, Apr 11, 2017 at 3:09 PM, Robert Osfield <
> robert.osfield at gmail.com>
> > wrote:
> >>
> >> HI Hannes,
> >>
> >> The CompositeViewer was written specifically for your usage case -
> >> i.e. multiple Views.
> >>
> >> I wouldn't recommend using slave Camera's for doing multiple views,
> >> while possible it's just a mess in terms of management.  slave
> >> Camera's are tools for helping rendering a single view, but with a
> >> view that is composed of several components - either spread across
> >> multiple windows, or a view that requires multiple passes such as
> >> distortion correction, field of view etc.
> >>
> >> The only reason you drawback you state about using CompositeViewer is
> >> multiple update traversals. Is this correct?  If so then the
> >> discussion should be about what problems you are having with
> >> callbacks, as the solution will likely related to how you are doing
> >> callbacks rather high level viewer configuration.
> >>
> >> Robert.
> >>
> >> On 11 April 2017 at 12:08, Hannes Naude <naude.jj at gmail.com> wrote:
> >> > Hi all
> >> >
> >> > I am trying to render a single scene from multiple viewpoints. I
> >> > initially
> >> > implemented this with a compositeviewer as per the osgthirdpersonview
> >> > example. This worked fine except that my update callbacks appeared to
> be
> >> > getting called more than once per render cycle. I assumed that the
> >> > update
> >> > traversal was being done for each view separately and therefore nodes
> >> > that
> >> > are present in multiple views will have their update callbacks called
> >> > multiple times. So, at this point I tried to do the same thing but
> with
> >> > a
> >> > single View, somewhat similar to the osgCamera example. But, I do not
> >> > want
> >> > to add my cameras with viewer.addSlave as I want them to move
> >> > independently
> >> > of one another. So I tried adding them into the scene graph and giving
> >> > each
> >> > their own GraphicsContext, but even though the windows corresponding
> to
> >> > these GraphicsContexts get created, it appears as if all rendering is
> >> > done
> >> > in a single window with multiple viewpoints being rendered over one
> >> > another.
> >> >
> >> > Obviously there are many ways to skin this cat, but I would appreciate
> >> > some
> >> > guidance on the recommended approach. To recap my requirements are :
> >> >  - Multiple cameras viewing the same scene.
> >> >  - Camera positions and orientations must be independently controlled.
> >> >  - Node update callbacks should be called only once per Node per
> render
> >> > cycle.
> >> >
> >> > Any help will be appreciated
> >> >
> >> > Regards
> >> > Hannes Naude
> >> >
> >> > _______________________________________________
> >> > osg-users mailing list
> >> > osg-users at lists.openscenegraph.org
> >> >
> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >> >
> >> _______________________________________________
> >> osg-users mailing list
> >> osg-users at lists.openscenegraph.org
> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> >
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170411/2680d4c3/attachment-0002.htm>