On Sat, 28 Jun 2008 09:04:59 +0200
Mathias Fröhlich <[EMAIL PROTECTED]> wrote:

> 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
> 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 ...
I received a private comment about this point too. Mapping cameras to
different windows, which can be opened on arbitrary screens, will
absolutely still be supported. I know that multi-GPU setups are
important for professional users and our demos. The setup you just
described would be an important test case for my proposed system: 4
monitors attached to two GPUS. As I understand it you will get the best
performance with each GPU treated as a large virtual screen, so here
you want two graphics windows -- one opened on each display (GPU) --
with two cameras mapped to each window.

> > 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 ...
Interesting to know. OK, perhaps no matrix syntax.

> > 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.
Yup. We can think about how to specify that.
> > 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 ...
It sounds like the arrangement I described could be easily hooked up to
your animation.
> > 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 ...
You bet.


Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Flightgear-devel mailing list

Reply via email to