FlightGear Glass Cockpits

From wiki.flightgear.org

Jump to: navigation, search

Contents

Intro

While FlightGear's current texture-centric way of allowing contributors to easily develop pretty realistic (and possibly even photo-realistic!) instrument gauges (relying on various layers of conditionally runtime-animated openGL textures;animations being based on property tree data) is pretty straightforward and relatively flexible for many purposes, it is getting more and more obvious that this approach is severly limited when it comes to implementing more complex instrumentation systems, i.e. glass cockpit-type systems such as EFIS, FMCs or navigation displays combining many different data sources visualization/display modes requiring a high degree of flexibility and the ability to dynamically create, draw and transform textures.

Problem

This can be considered the main reason behind certain types of aircraft (namely, most modern airliners) and certain types of aircraft-instruments (i.e. highly integrated glass-cockpit type instruments) being so far either incompletely/unrealistically depicted or even significantly underrepresented within FlightGear altogether.

Currently, contributers wishing to equip their aircraft models with corresponding modern instrumentation systems would have to resort to hardcoding the required systems directly within FlightGear's core source code (as it happened for example for KLN89 GPS emulation), while this is definitely a viable option for contributors with a developer's background, this turns out to be a showstopper for most non-developers, as is being illustrated by the fact that most such complex avionics are so far mainly depicted using texture stubs to visually show the right thing in the right place, which however usually ends up being just a dysfunctional photographic texture of a device that users may be accustomed to being properly simulated in other flight simulators.

Contributors != Developers

Unfortunately, as things are standing now, it turns out that most of the regular long-term aircraft authors and contributors within the FlightGear community who have in the past contributed by doing 3D and aircraft modeling, have usually no background in programming in general, or C++/OpenGL programming in particular, which results in such contributors not being directly able to contribute the way they might want to.

This is a very unfortunate situation, as contributors with non-development background basically have to resort to waiting, until they are enabled to make certain types of contributions because someone implemented a required feature and it even made it into CVS/HEAD.

Hardcoding vs. Scripting

A similar situation was faced before, and successfully addressed shortly after, FlightGear incorporated scripting facilities by using the Nasal scripting language, which -all of a sudden- allowed contributors to implement, modify and add custom logics to FlightGear without having to recompile the FlightGear binary, and without having to know any of the underlying low level internals.

Nasal's very success is in fact illustrated by the wealth of features it is currently being used for as the first choice for implementing them.

However, in the last couple of years it has become obvious that non-developers would like to make more complex and challenging contributions, which they currently cannot accomplish without modifying FlightGear's core source code, because the corresponding hooks are not yet provided.

This however, requires not only a corresponding programming background, experience and familiarity with the underlying code base and its various dependencies, but also a number of other skills which may be different in scope, depending on the type of features contributors would like to implement.

Hard-coding custom new features has in the past always been critically discussed within the FlightGear community, thus it is not surprising that this also turns out not to be necessarily the ideal choice for many situations and conceivable features that are now being discussed, particularly due to FlightGear's emphasis on providing support for a high degree of customization.

In fact, back when the hard-coded KLN89 emulation was committed to FlightGear CVS/HEAD, this was not only being critically discussed but it was highlighted by some contributors that it would be desirable to eventually have the infrastructure in the scripting system evolve to a point where it would be possible to implement such and similar devices purely using the Nasal scripting system and corresponding low level hooks to improve performance. [1]

In fact, comparing hardcoded FlightGear instrument implementations to instrument types that are mainly implemented using dynamic means (i.e. XML & scripting) shows that the latter components usually end up being superior as they experience a more rapid evolution (including willingness to adopt new instruments and continue development) in FlightGear due to their flexible and dynamic nature. This is also backed up by the stagnation that the KLN89 instrument experienced pretty much directly after having been committed to CVS [2]..

Core developers acknowledge the fact that FlightGear needs a 2D drawing API to implement Head Up Displays (HUD) and Multi Function Displays (MFD) (see [3]): 

What we will need is some cairo/glitz like 2d api to draw the HUD and do some 
MFD's. I believe that this is even more apprioriate for such rendering areas 
like issuing raw OpenGL commands.
With such an abstraction we are open to map that to an immediate more 
rendering pass to a texture or if this is used to build up a part of the 
scenegraph in case we do not have RenderTexture available.


FlightGear, having a long-standing history of a development philosophy that encourages modular, flexible and dynamic implementation of components and features, with an open design (that may thus be highly customized by end users) should again concentrate on providing the required low level building blocks of functionality that is minimally needed to provide underlying features to enable contributors to easily implement specific features on top of them, while ensuring that the core's source code is in fact mainly based on code contributed by people who understand the underlying architecture.

Even core developers agree that most MFD features can be implemented using scripting means [4]: 

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

Proposal

This proposal is a summary of the various places (in the wiki & mailing list discussions) where contributors and end users are asking for ways to provide said means to more easily implement more complex aircraft instrumentation modeling facilities by adding the required low level hooks to FlightGear.

Use Cases / MFDs

  • Moving Map
  • EFIS
  • FMC/CDU

Required Hooks

This is meant to become a list of features that have in the past been requested, please feel free to populate with contents.

Scripting

Using OpenSceneGraph for 2D drawing

Related Pages:

Related Discussions


More related discussions can be found here.

Retrieved from "http://wiki.flightgear.org/index.php/FlightGear_Glass_Cockpits"