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

[Mathias F. <Mat...@gm...>]

Hi Tim,

On Thursday 26 June 2008, Tim Moore wrote:
> 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.
This is true in general. Mostly I agree.
But I would like to be able to still use displays and screens for some parts 
of the viewer. So while this would be very good to have and probably better 
for the end performance where you are heading to, we should have that as an 
addition to the way we can now redirect views to different displays and 
screens.

Just think of a 2 gpu machine. You get the best performance with 2 screenn 
each on one gpu. Then have exactly one graphics context per gpu. When you 
have two monitors on each gpu, subdivide that single graphics context among 
two cameras like you are probably heading to ...

> 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.
Ok, in principle yes. I do not know projdesigned. But Note that you have to be 
careful with osg. You just can have a  sheared frustum in osg as a 
perspective projection matrix. If you specify arbitrary projection matrices 
osg bails out when culling ...

> 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.
Sounds good in general.
What we just need is the ability to still redirect some windows to an other 
display/screen.

What would be good to have is the specify a completely different scenegraph in 
some subcameras. I think of having panel like instruments on an additional 
screen/display for example.

> 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.
Well, I have an animation that I call rendertexture, where you can replace a 
texture on a subobject with such a rtt camera. Then specify a usual 
scenegraph to render to that texture and voila. I believe that I could finish 
that in a few days - depending on the weather here :)
The idea is to make mfd instruments with usual scenegraphs and pin that on an 
object ...

> 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.
Good thing to have!!!
Just still support graphics context on different screens/displays too ...

GReetings and thanks!!!

Mathias