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.osfi...@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...@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.osfi...@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...@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@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 > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org