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. 
2.6 release candidate should work fine.


 > 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
Flightgear-devel mailing list

Reply via email to