[Flightgear-devel] RFC: changes to views and cameras

[Tim M. <ti...@re...>]

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.