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
