After some playing around, the area of FG that I'd most like to see improved, and therefore inclined to work on, is better glass cockpit displays, and the systems behind them. I'm still reading over the code, and looking at different aircraft to get a handle on this (and, err, how difficult it's going to be) In the mean time, some questions:
- in the OSG world, what is the 'right' approach for rendering cockpit displays? The KLN-89b uses a render-area-2d (and I think the weather radar does, but is currently non-functional under OSG?). The obvious candidates are a sub-scene rendered by an orthographic camera, or render texture accessed by 2D drawing. Which is the most likely to work well? In terms of things like supporting rendering displays to alternate video devices (for real cockpits), zooming displays for better visibility, and avoid Z-fighting when drawing many overlaid 2D elements. - As I understand it, the current PFD and NAV displays in the A320 / Citation / 787 / 737 are made using pretty elaborate arrangements of the current XML Panel code. I've also seen talk (I think) of people working on the G1000. What do people think is the right balance between Nasal + XML vs C++ code in this area? I think most features of even a Boeing PFD could be done purely in Nasal + XML panels, even things like the variable Max IAS indication and V-speed / flap- retraction markers. The NAV display certainly needs a C++ core for the showing Navaid DB features and the current flight plan, but the border elements and many other parts could still be built using XML. Equally OpenGC does the whole lot in compiled code, and the PFD might be simpler if a few components (airspeed and altitude tracks, for example) were available as pre-built components. - My plan would be to build some generic classes which can be extended or configured to support Boeing or Airbus displays, or other similar systems (including the G1000). My current perception is that this would be pretty doable - sizes / colours / iconography / positions of elements change, but the fundamental concepts are pretty consistent. Does this seem reasonable? Obviously supporting all the features of each system is an immense amount of work, but I think getting the common features up and running is doable in the medium term. - Any other feedback? I'm interested in docs on the G1000 and Airbus displays / FMS in particular, to see how they differ from what i know about the Boeing ones. I don't know anything about military equivalents, but maybe they are also similar enough to share a C++ core. My initial hack would be to get a NAV display running showing the current route segments and navaids overlays in a specified radius, working as a custom panel instrument. That would be enough to get the FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well as the NAV display modes (compass, enroute, approach if I recall correctly). Regards, James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
