<div dir="ltr">Could it be that slave camera's show up in the stats viewer, but children in the scene graph do not?<div><br></div><div>Nico</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 21, 2017 at 9:45 AM, 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 Nico,<br>
<span class=""><br>
On 21 February 2017 at 08:19, Nico Kruithof <<a href="mailto:nicokruithof@gmail.com">nicokruithof@gmail.com</a>> wrote:<br>
> There are two ways to add a camera to a view. First, there is the addSlave<br>
> (osgcamera example) and second, you can add the camera to a group node in<br>
> the scene (osgprerendercubemap example). What is the difference between the<br>
> two and when would you use one or the other?<br>
<br>
</span>You can implement the same effects with both approaches so it's mainly<br>
down to conceptual and practical considerations.<br>
<br>
Conceptually a Camera assigned to a View(er) as a master Camera or<br>
slave Camera provides guidance on how the viewer views the scene.  So<br>
if you had a HMD you would naturally use two slave Camera, one for<br>
each eye.  Also if you want to do distortion correction again this<br>
would likely be conceptually something associated with how you view<br>
the scene so again would naturally fit as a slave Camera.  Practically<br>
in both these cases configuring the viewer with different combinations<br>
of slave Camera enables you to vary how the scene is viewed on<br>
different physical devices, completely decoupled from the scene graph.<br>
<br>
With effects like shadows or reflections conceptually these are<br>
related to the scene that you are viewing rather than how you are<br>
viewing it, so naturally you would put such a Camrea into the scene<br>
graph itself.  Again practically this is a good fit as you can<br>
serialize out the scene graph and then load into a application that<br>
has a completely different viewer setup and it'll work, i.e. you can<br>
move from a desktop to HMD or a powerwall and have the scene still<br>
look as intended without having to hardware the application to it.<br>
<br>
The design of osg::Camera and osgViewer is based on these<br>
concepts/practical consideration, the class relationships and naming<br>
all fall naturally from this desire to be able to conceptually and<br>
practically decouple the needs of the viewer from the needs of the<br>
scene.<br>
<br>
Robert.<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nico Kruithof<div><font size="1"><a href="http://nghk.nl" target="_blank">nghk.nl</a></font></div></div>
</div>