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. Tim ------------------------------------------------------------------------- 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
