AJ MacLeod schreef: > Your original issue was, I think, a desire to have different parts of > the FG > 3d environment (including instruments) displayed on different screens, on a > PC with multiple graphics cards and monitors. As far as I can see, it's > already possible, with no extra coding, even for fully 3d cockpits. You can > already set your viewpoint(s) anywhere relative to the a/c, facing any > direction at any zoom level. You can have multiple views of any part of the > same aircraft. Of course it should be even simpler now that we're using > OSG... there was some mention in a thread in June (Impressions from LinuxTag) > of using four osgViewer "cameras" configured in preferences.xml to output > displays from one instance of FG. > > Mind you, I haven't seen the promised instructions materialise... it would be > nice to see those - did they get onto the wiki when I wasn't looking? > > The one instrumentation-related thing that we definitely lack at the moment > is > a really flexible method of implementing "glass cockpit" displays within FG. > Fortunately, it's not something that affects the type of aircraft I'm most > interested in ;-) > > Cheers, > > AJ > No, my original issue was to make external instrumentation possible over the network, not on a single PC with 6 monitors on it. Distribute the computing power, allowing more processing power for the flight dynamics and visuals and a flexible instrument setup.
Take a real simulator as an example: The flight dynamics are run from a system that does only that -- flight dynamics. Pure math that is, and it's mostly done as a double redundant unit instead of a single one. The only data the FDM machine will output is that relevant to flight dynamics. That's basically all of the position data and 2 levels of derivatives of it (thus including forces on the airframe). Other systems, mostly composed of real-world avionics, pick up on that data and generate the relevant instrumentation, either as an image or as a control signal for a real aircraft instrument. Mind you, most flight deck builders, including the FS200x users, do not use a single machine for all the work. More and more of FS is ripped out of the FS logic, leaving only the raw FDM and visual data up to that system. All of the system logic is done "outboard" communicating with FS over a network link. The only downside of this, is that FS panels themselves are defined in "gauges" (DLL files) which can never be used outboard because of Microsoft's closed API. There are some really good payware aircraft on the market with tremendous levels of realism, but they are all limited to that one system running FS, so they are not suitable for cockpit builders. Mind you, most of my ideas ARE targeted at glass cockpits, which are mostly composed of vector based graphics. (Historically, aircraft even had vector-driven CRT's before the flat panel era.) If glass cockpits are built up of bitmap-based graphic material, it will look ugly and unrealistic. The Citation in FG, for example, has a very clear and visible display for the PFD/ND, but you can immediately see that it doesn't look like "glass". Most cockpit builders will want 2D displays since most of it is hidden behind paneling. Only a few display elements are revealed, and these should look like they belong there. You don't want to be looking 'through' the display glass at some piece of 3D cockpit, you will want to be looking AT the display glass because it is part of the cockpit hardware. Everything will have to look flat. My ultimate goal is to model a flight deck after the professional sims -- each part of the simulator is dedicated to a system. This adds both redundancy and flexibility -- if a system crashes, it doesn't take the entire simulator with it as is the case with FS2004 based setups. The data exchange doesn't stop, because it isn't tied to a single 'master' unit -- if one unit should cease to respond (function), the rest of the system is notified and possibly another unit or a hot standby might take over. Likewise, if another aircraft is being simulated, the only thing that needs to change (in principle) is the system logic and flight model, instead of needing a hard simulator reset. My proposal for the project would be to create a working framework for 2D instruments, suitable for cockpit builders. The system would be similar, if not identical in functionality, to X-Panel for X-Plane users (I would like to give you a URL but some fool took down the X-Panel pages, every Google hit turns 404), which allows X-Plane instruments to be displayed on a different system (or multiple). As for glass cockpits go, an example is either OpenGC or Project Magenta, but both of these have the design of their displays hard-coded, what I would really like to see is that GC or steam panels could be designed in a WYSIWYG graphics environment, and interactive script added later. SVG has specifications for that. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
