Hi Dan, You are mostly on the right track.
A couple of clarifications: A view "has a" single Master Camera accessed via view.getCamera() A view "has an optional list" of zero to many Slave Camera. A view's Master Camera can be active (have its own GraphicsContext) or passive (no GraphicsContext). A Slave Camera can choose whether to use the same scene graph as the master, or have its own local scene graph A CompositeViewer with multiple Views that share the same scene graph (wrapped up by osgViewer::Scene) will only need to do a single update traversal per Scene. The is no performance advantage of using osgViewer::Viewer with multiple slaves over osgViewer::CompositeViewer with multiple Views, internally all the rendering and threading is the same. CompositeViewer provides event handling/camera manipulators per View, and the option of having separate scene graph, so makes it far more suitable for apps with multiple views. Slave Camera main usage is in doing multichannel displays or distortion correction. Robert. On Mon, Aug 4, 2008 at 5:21 PM, <[EMAIL PROTECTED]> wrote: > I'm starting to convert several apps from OSG 1.X to the current release. > I've read the posts regarding Viewer and CompositeViewer and want to make > sure I'm understanding it right. If you don't mind a few beginner > questions... > > 1) Viewer (which "is a" View) can have one or more Cameras, but if using > multiple Cameras, they are positionally slaved to the single View Camera by > offset matrices, right? > > 2) The slaved Cameras can share the subgraph (Scene) below the View Camera, > but if desired, they could have their own subgraphs? > > 3) It seems that generally, since the slaves are offset from the View > master camera, for most applications, they would share the same Scene, > right? > > 4) CompositeViewer (which "contains" Views) can be more flexible since each > View Camera can be independently positioned (i.e., different views of the > same Scene, but where Camera 2 doesn't necessarily follow Camera 1). > > 5) The View(s) within a CompositeViewer could themselves be single-Camera > or master-slave configurations. > > 6) It seems that a CompositeViewer with a few Views could be functionally > equivalent to a "Viewer with slave Cameras" provided the user positions the > CompositeViewer Views with respect to a designated "master" View in > real-time? > > 7) I see some efficiencies, such as a master-slave View applying the Update > traversal only once to the shared Scene. Are there any other significant > benefits (e.g., cull, rendering, state) that make a Viewer master-slave > setup more efficient than the equivalent manually-slaved Views in a > CompositeViewer? > > Sorry for the length, but I hope this post might be useful to others just > starting the 1.X to 2.X conversion. > > Thanks! > Dan Guinther > > > > ________________________________ > Looking for a car that's sporty, fun and fits in your budget? Read reviews > on AOL Autos. > _______________________________________________ > 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
