Tim Moore <timoore <at> redhat.com> writes: > > Hi, > I'd like your comments on some changes to views and OSG cameras in > FlightGear before I start working on them. In particular, my > understanding of how FGViewer works might not be complete. > I've implemented what I described here. The property nodes for creating a CameraGroup are described in docs-mini/README.multiscreen.
As Fred descovered, it looks like you will now need an OSG newer than 2.5.1. The 2.6 release candidate should work fine. Tim > What we have now > > FGViewer calculates the parameters of a view. This includes > camera-independent parameters such as the view origin and > direction. These parameters are calculated differently based on, among > other things, whether the viewpoint is tied to a model and whether the > view direction is fixed, relative to a model, or always tracking another > model. FGViewer filters and dampens some of these parameters. FGViewer > also controls some basic camera parameters such as the field of view (fov) > and a modification of the camera aspect ratio called the "aspect ratio > multiplier." > > There is only one active FGViewer object at a time. This is managed by > FGViewMgr and is accessed using get_current_view(). The origin of the > current view is used by the tile manager to make sure that visible > scenery is loaded. Each frame, code in Main/renderer.cxx uses the current > view to update the Open Scene Graph cameras. > > The arrangement of the OSG cameras is dictated by the osgViewer::Viewer > class that we use to render the view on the scene. There is one master > camera with several attached slave cameras. The master camera sets > principal view (position, orientation) and projection (the frustum) > parameters. The slaves can either specify additional transforms to those > parameters, in both model-view and projection space, or they can be > absolute in their own right. Currently the "out the window" views are > rendered in relative slave cameras, while the GUI and HUD are drawn in > an absolute slave. > > Slave cameras are created using properties in preferences.xml. One slave > is always created that is aligned with the viewing parameters of the > master camera. Others can be opened in different graphics windows, > possibly on other displays and screens. A slave camera is presently > created in its own window. Parameters for the slave are currently pretty > limited; they include the dimensions and position of the window, "shear" > values in projection space, and "heading-deg," a heading offset that I > suspect was added specifically for LinuxTag :) The shear-x and shear-y > values are really only useful for setting up a "video wall" type display > where monitors arranged around the "master view" show a view in an > offset frustum with the same aspect ratio and fov as the master. > > Problems With the Current Approach > > Many features are not now possible using only a single running instance > of FlightGear. There can't be more than one view at a time. It would be > nice to keep the principal "out the window" view around -- in order to fly > the > aircraft -- while having inset model views, tower views, missile-cam > views, an a340 tail-strike view, etc. > > Our OSG camera creation procedure is completely insufficient for many > things that people want to do with FlightGear. The requirement that > slave cameras be opened in different graphics windows doesn't match well > the most common multi-head graphics hardware. Most people are using a > setup that drives several monitors with one graphics card, such as the > Nvidia TwinView or Matrox 2Go products. These configurations work > best with a single graphics window that spans all the monitors; the > graphics context switches needed to render to different windows on the > same graphics card are expensive. The camera parameters we support are > not sufficient to specify monitors arranged around a cockpit for a real > out-the-window view, to say nothing of views projected onto a screen or > dome. Furthermore, for those configurations the FGViewer should never > be able to change the field of view or other camera parameters. > > Proposal > > Define a CameraGroup object that is the bridge between an FGViewer and > the OSG cameras that render the view. An FGViewer points to one > CameraGroup, and only one active view can drive a CameraGroup at a > time. The CameraGroup manipulates osg::Camera objects as > necessary. Subclasses of CameraGroup might not respond to FGViewer > requests to change camera parameters. > > Extend the camera creation options in preferences.xml to specify named > CameraGroup objects. Allow the specification of graphics windows to > which slave cameras in CameraGroup objects are assigned. Allow the full > specification of viewing parameters -- position, orientation -- either > as relative to a master camera or independent. Allow the camera > parameters to be specified relative to the master, as they are now, or > independently. The camera parameters can be specified using the Clotho > / glFrustum scheme (top, bottom, left, right) or a syntax used by > ProjectionDesigner (http://orihalcon.jp/projdesigner/) that uses field > of view, aspect ratio, and offset. A full 4x4 matrix can also be > specified. > > Camera groups can be created and destroyed on the fly; the CameraGroup > will create OSG cameras as necessary and attach them to the proper > graphics window. > > A camera group named "default-camera-group" will be used by FGViewer > objects by default. This group will be created based on the command line > arguments if it isn't specified in preferences.xml. > > FGViewer objects can either use named camera groups or can create new > ones on the fly. I don't know if the creation of new graphics windows on > the fly will be supported. > > Eliminate get_current_view(). There will be a list of active > views. Try to eliminate code that depends on the current view. There > still needs to be a "current location" for the terrain pager, but more > on that later. > > This proposal is a little vague; the specifics need to be worked out > when the CameraGroup is implemented and FGViewer is changed to use it. > > Future Possibilities. > > The cameras in a camera group don't need to render directly to the > screen. They can render to a texture which can be used either in the > scene, like in a video screen in the instrument panel, or for distortion > correction in a projected or dome environment. > > Open Scene Graph supports a CompositeViewer object that supports > rendering from several widely separated viewpoints, complete with > support for multiple terrain pager threads. We could move to > CompositeViewer and support simultaneous views from e.g., the tower, AI > models, drones, etc. > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
