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