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
