Tim Moore wrote > Sent: 26 June 2008 11:53 > To: FlightGear developers discussions > Subject: [Flightgear-devel] RFC: changes to views and cameras > > 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. > > 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. > It all looks well thought through and comprehensive ... BUT what's the likely/possible impact on framerate? There's little enough to spare on all but the most modern and capable machines already.
Of course if there is significant negative impact on the frame rate that would be Comprehensive Rational And Purposeful ... Vivian ------------------------------------------------------------------------- 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 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
