Hi, Nice description. If I could describe a couple specific usecases, just to wring out the distinctions:
1) an immersive car cockpit display: front windscreen, left/right side windows, inside/outside rearview mirrors. That indicates Viewer (even tho the eye orientations are quiet different, and also have some mirror flips) 2) a 3rd-person stealth watching a UAV sensor platform: the UAV is collecting sensor data from its viewpoint; an operator is watching the UAV and a wireframe of its sensor volume sweeping the terrain. That indicates CompositeViewer (the scene database could be identical, but the sensor wont see its wireframe nor the UAV) Correct? Thanks -- mew > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Robert Osfield > Sent: Friday, January 18, 2008 8:11 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] osgViewer::Viewer vs > osgViewer::CompositeViewer > > On Jan 18, 2008 1:49 PM, Jean-Sebastien Guay > <[EMAIL PROTECTED]> wrote: > > Wow, thanks for the great explanation! I think I'll start a wiki page > with this > > stuff, as well as a list of examples. Might be useful to others in > the future. > > Yes that would be useful. It's not the first time I've made a similar > explanation. > > > Most of the typical use cases that were described to me seem to fit > the single > > View(er) as I thought they would. > > Yes, you explanation suggests Viewer is in order. > > > I have a few follow-up questions, though. > > > > > Implementation wise > > > this is where you have a master Camera that provides the overall > view > > > and projection matrix and slave cameras which have their own local > > > offsets relative to this master Camera. > > > > Do the slave cameras have to be relative to the master camera? > Couldn't they > > have an ABSOLUTE reference frame and then be positioned in world > space? > > Yes indeed, in fact the distortion correction example I gave where RTT > cameras are used followed by a second set of cameras render the final > result has the second set of camera using ABSOLUTE_RF. Have a look at > the code in src/osgViewer/View.cpp to see how its set up. > > > > > > ...or a 3D scene and a map view, ... > > > > Say we want a 3D scene and a "radar/sonar" view which has a different > scene > > graph, would that fit that example as well? In general I would have > done the > > sonar as an RTT camera, but I guess it could be done with a separate > View, and > > in that case, a CompositeViewer would be required, right? > > Your words "has a different" view tells us straight away that adding a > "radar/sonar" makes it a case for CompositeViewer. You could do it > with render to texture or slave cameras added to the Viewer but its > really not conceptually a good fit, nor is it as practical as the > implementation would get really awkward quite quickly. > > > Though I still wonder if it's worth it to use a CompositeViewer > everywhere for > > just that one case. > > The most general purpose viewer is CompositeViewer so its no bad thing > to consider using it if you app does chop and change its requirements > from the viewer. > > One thing to note is that CompsiteViewer and Viewer share the same > ViewerBase class so its possible to have an app that just has a > ref_ptr<ViewerBase> and can use either CompositeViewer or Viewer, and > the fact that Viewer "is a" View can even permit it to be added to a > CompositeViewer (all its viewer functionality will be bypassed, but > its View functionality will still work). > > Also code that works on Viewer utilising the various View derived > functionality can very easily be ported across to code that just sets > up a View, making it very easy to change you mind about how you write > put together the viewer at the application level. One minute you > could be using osgViewer::Viewer, the next you could decide ohh I'd > prefer CompositeViewer and it'd only take a few minutes to recode, and > visa-versa - the fact that so much is shared between the viewers and > view makes it very easy to refactor things. > > The ease of moving between Viewer and CompositeViewer also means you > can defer decision about what to use till later in your project when > you have a definite juncture when one particular solution becomes > necessary. > > Robert. > _______________________________________________ > 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
