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 [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
