Flying has never been so impressive — or free. FlightGear is a flight simulator that boasts surprising technical realism, supported by an equally sophisticated pedigree — several of its active developers work in the aeronautics industry. "What keeps the project going is a wide range of people who care deeply. This is not a typical open source project — many of our contributors are closer to middle age," says David Megginson, a 39-year-old programmer from Ottawa, Ontario, Canada, who has contributed his time and skills to FlightGear's development. "We have the benefit of contributors who know a lot about their domains, including pilots and aeronautical engineers."
Thus, with FlightGear, the emphasis is on simulation. Its developers are proud of the fact that their flight simulator replicates the real kinks and quirks of airplane flying, even if the end result might not always necessarily be "fun." One of their primary development goals is for FlightGear to be used for serious aeronautic research and academic purposes. This doesn't mean there's no room for entertainment, though — you can still fly around idly and see some beautiful landscapes based on actual locations that are generated by real-world mapping technology.
FlightGear began in 1997. It now runs on Linux, Windows, Mac OS X, and other platforms. Its code is released under the GNU General Public License.
FlightGear's origins date further back, to 1995, when Curtis Olson, a simulation engineer from the "Twin Cities" suburb area of Minnesota, USA, looked into building an add-on to Microsoft Flight Simulator. While he found the experience to be productive and interesting, he spent more of his time trying to hack, reverse engineer, and understand the Microsoft Flight Simulator file formats and internals than actually working on making his add-on.
"I said to myself, 'Wouldn't it be nice if the community had an open source flight sim, so that people who want to build add-ons and contribute can spend 95% of their time working on their contribution, and maybe 5% learning the open and, hopefully, reasonably well-documented infrastructure and formats?'" recalls Olson.
The result is that, ironically, this 35-year-old programmer has spent the last five and a half years developing FlightGear, far more time than he ever spent tinkering around with Microsoft Flight Simulator. Today he is the project leader of FlightGear.
Separately, Jon Berndt, an aerospace engineer supporting the NASA space shuttle program, had planned on developing his own desktop flight simulator. The 42-year-old from Houston, Texas, USA envisioned making one that would model flight not only very accurately, but also in a way that would be instructive to students of aerospace engineering. "When I came upon the FlightGear project, it seemed natural to team with them, as the only part I was really interested in developing myself was the FDM [flight dynamics model]," says Berndt. Relieved to find that FlightGear already had good rendering code (an area outside his expertise) under development, he focused on programming an object-oriented, highly configurable FDM for FlightGear called JSBSim. "Fortunately, shortly into the development of JSBSim, engineer Tony Peden came onboard and was followed by several others."
In addition to JSBSim, FlightGear has a second physics engine called YASim, written by Andy Ross. YASim takes a completely different approach to modeling flight, inventing aerodynamic data to explain the plane's (user-specified) behavior rather than deriving the behavior from aerodynamic data. Since performance data for most aircraft is easily available on the net, contributors have been able to add flight models for dozens of new aircraft quickly using YASim. In the CVS version of FlightGear, there are now several YASim-based helicopters as well.
FlightGear is mostly written in C++, but includes some bits and pieces of C code. "FlightGear would be a bugger to manage in C. Java would be even easier, but the sim world hasn't really taken to Java, and the APIs are not well broken-in," says Megginson.
The program has an open architecture, and network-based mechanisms for interfacing with external scripts or code. This allows external scripts or modules to be written in just about any language. Such examples have been written for FlightGear in C++, Java, Perl, Perl/Tk, and Python.
FlightGear uses several libraries, including OpenGL, Plib, zlib and SimGear. All of these libraries are handled by other organizations, but SimGear is actually maintained by the FlightGear developers and has been developed in parallel to FlightGear — it's a set of lower-level, generic-simulation infrastructure code. "The most important non-system library we use is Plib, which provides outstanding scene-graph support, along with other modules we need for simulator development," says Megginson.
Optimizing the frame rate of graphics tops the list of technical issues for FlightGear. The simulator taxes the capabilities of graphics processors due to the amount of scenery it has to churn out. With 20 miles of visibility at altitude, the program has to render and display over 1,200 square miles of terrain, in addition to the cockpit and control panel graphics. Players who are used to playing games with "restricted 3D graphics" (where elements in the gameplay environment are limited in visibility range) may be surprised to see how much the frame rate drops, even if they have powerful 3D graphics cards on their systems, when playing a sophisticated simulator like FlightGear.
Organizing the FlightGear team — bringing together people who have specific knowledge needed to contribute to the building of a realistic flight simulator — has been perhaps more challenging than any technical tasks with the code. Olson says the biggest surprise has been how far into a variety of diverse fields in science and engineering they have had to delve: "You need aero engineers and physicists, of course, but beyond that: you need GIS [geographic information systems] people for creating scenery. You need astronomers to correctly place the ephemeral objects. You need historians and researchers to find information on aircraft. You need electrical engineers. Even a few psychology/human perception people on board can't hurt."
"We have people with many years of aviation or simulation industry experience. Because we are doing this as open source, we gain access to a huge pool of talent and experience that, otherwise, wouldn't be available to us because of cost considerations."
New features for future versions of FlightGear will include enhancements to the JSBSim flight dynamics model. One potential new feature calls for adding the ability to model multiple objects that would have a relationship to the player's aircraft. An aircraft's configuration file could reference the configuration file of another object in the simulator — such as another aircraft, a missile, or even a delivery of several MREs. "It would allow modeling the flight of multi-stage rockets, missiles fired from aircraft, and drop-testing of an X-15 from a B-52, for instance. Each vehicle would model its own flight path independently," Berndt describes.
As for FlightGear itself, not much new is planned besides additional scenery and aircraft models. But the project has grown quite a long way in this respect over the past year — from featuring only a handful of planes to fly. Since then, volunteer 3D-model artists have created so many more that some of the main FlightGear team developers haven't had the time to try them out. With so much eye candy now for this "serious" flight simulator, these elements will soon need to be distributed and maintained separately from the main program package.
Other additions and possibilities for FlightGear remain, well, up in the air. "We don't do a lot of planning ahead," admits Megginson. "Managing a pseudo-real-time, interactive, cross-platform program is a bit like sledding down an icy hill — we don't look very far past the next bump."
Curtis Olson, Jon Berndt, and David Megginson recently participated in an interview with the O'Reilly Network. Here's what they had to say.
O'Reilly Network: Specifically, in regards to developing a flight simulator, what are the unique challenges in performing such a feat?
David Megginson: The hardest part of a simulator of any kind is making it hard to use. It's easy to design a flight model that just flies the airplane wherever the user points the controls; it's hard to design one with all the minor aerodynamic effects that make an airplane hard to fly. For example, our single-engine planes have a lot of adverse yaw on takeoff, just like real planes — the [question asked most] from new users is why the plane usually doesn't just fly straight when they point the controls straight ahead.
We're also working on making the instruments more realistic. For example, none of the instruments is exactly correct — we model the same lags and inaccuracies you see in a real plane. We can simulate failures at different points for pilot training.
When you're dealing with a flight simulator, there's the extra problem of scenery. From almost the start, we've insisted on modeling the whole world, rather than just the U.S. In fact, we have a very large proportion of non-U.S. contributors in the project. The U.S. releases more and better free geographical and aviation data than any other country in the world, so the U.S. scenery is the most detailed. But we work to model every part of the world as accurately as we can with what we have available, and we focus on data sources like VMap0 that have worldwide coverage.
ORN: How would you say FlightGear compares to commercial products that are similar to it (especially Microsoft's Flight Simulator series?)
Curtis Olson: I'd say that, in terms of graphical whiz-bang, pretty stuff, MSFS will always be hard to beat. But as we progress in development, FlightGear implements more and more of the functionality of these other sims, and we are getting very close to the point of having all the basics covered.
Jon Berndt: From a flight dynamics angle, we have been told that in some respects, our flight model is better. I have not looked at aircraft modeling for MSFS, but we have very few limits placed on potential aircraft modelers. Aircraft flight models that use the JSBSim FDM can be as complex as desired. If you have flight test data for an aircraft, you can use this to define how that aircraft flies in FlightGear using the JSBSim configuration file format.
Note: Regarding our configuration file format, we define aircraft models using an XML format (more or less). Our work provided some early inspiration for, and an example of, the use of XML for the definition of an aircraft simulation model. NASA Langley engineer Bruce Jackson is coordinating an effort aimed at formalizing a standard for the exchange of aircraft models using XML. Not coincidentally, Bruce Jackson is the author of LaRCSim, which was the first flight dynamics model used by FlightGear, and which has been updated by students and faculty at the University of Illinois, Urbana/Champagne (UIUC). This flight model is one of several available for use with FlightGear.
DM: We decided a while ago not to compete head-to-head with MSFS. While our GUI has gotten better, FlightGear really isn't a program for an AOL-type computer user to play with. MSFS contributors have been coming over to FlightGear, though not because FlightGear is technically better, but because it's open. Of course, if you're not running Mac OS or Windows, there are not really any alternative flight simulators.
ORN: Are there features or technologies that have been added to FlightGear that aren't found in other flight simulators?
CO: I believe FlightGear was the first PC-based sim to cover the entire world with TIN DEM-based terrain.
We have a real star database correctly placed in the sky for your location, time, date, season, etc. The sun, moon, and planets are also correctly placed. The moon is drawn with the correct phase, and even the planets' brightness — partially affected by their phases — is modeled.
Another huge advantage of FlightGear is that it is completely open source — it has a rich set of existing external interfaces, and most of the major configuration can be done with standard XML-based text files. We make no attempts to obfuscate or hide our internals. This is big win for people using FlightGear as an academic or research platform, or for those that want to interface it to their own home-built cockpits.
DM: Our property system really sets FlightGear apart. Almost all of the significant internal state is kept in a property tree that can be loaded or saved, and can be examined and modified interactively at run time.
We even have
telnet and HTTP interfaces so that you can connect to a running
instance of FlightGear over the net, and examine or manipulate its internal
state, starting a sudden updraft or emptying the gas out of a tank.
ORN: What sorts of contributions could FlightGear use from outsiders willing to volunteer their skills?
JB: If we could find someone with relevant experience to model ground reactions, that would be nice! There is room for improvement in our landing gear modeling. Prior to just this fall, we had been lacking a good turbine engine model. Fortunately, we were introduced to an engineer with directly applicable experience: an engineer who can program in C++ and also just happens to have experience in flying turbine-powered aircraft. Now our turbine engine model is under active development and test.
We could use people to help with "data mining;" that is, finding or calculating — and subsequently tabulating — aircraft aerodynamic data for use in eventually modeling new aircraft.
CO: From my perspective, a big area in need of attention is to have people build aircraft models including the flight dynamics, the 3D model of the aircraft, the instrument panel, the sounds, animations, etc. The infrastructure is all there to do this, but what we need is to crank up the assembly line and start producing some end-to-end complete aircraft models of fine quality.
DM: Everything: C++ coding, GUI design (no C++ required), flight modeling, testing, documentation, packaging (including user-friendly installation), geodata collection — you name it.
ORN: What advice do you have for those who want to modify the FlightGear code to develop flying games, or applications, with it?
DM: We're working right now to separate all of the non-flight-specific stuff into SimGear. SimGear is designed as a basis for any type of simulator with 3D scenery, and once we finish the reorg, it should be easy to build a driving or boating sim, for example, on top of it.
CO: Go for it! Subscribe to our mailing lists. Ask questions. Download the source code and compile it yourself. Once you get over that hurdle, you are only limited by your imagination.
ORN: For you as a programmer or game designer, what have been some of the lessons you've personally learned as you've worked on FlightGear?
CO: Some of what I've learned is related to interaction with people. It helps a lot to leave my personal agenda aside and concentrate on doing positive things for FlightGear. Leave the open source advocacy and politics to other forums specifically designed for that purpose.
A big lesson in a project of this magnitude is to viciously and tirelessly hunt down bugs as they appear. If you leave odd stuff hanging around — maybe you don't have the energy/time to track it down right now, or you hope that is the only time it will crash, or who uses that feature anyway? — it will become a nightmare later on. Random bugs stack up on each other and can make a huge mess out of an otherwise promising application. Down the road, these sorts of bugs can be nearly impossible to stamp out.
DM: I don't think that what I've learned and am still learning can be distilled down to a few catchy aphorisms. Working in a talented, geographically distributed, all-volunteer team is always a challenge. Code organization helps a lot — break things into small modules, use standard interfaces, and refactor constantly. If the code is too hard to understand, new developers will be less likely to join in.
You mentioned "game designer," and raise an interesting point. The development team never calls FlightGear a "game." Part of that may be snobbery, but there are some real differences: FlightGear is non-competitive and does not have victory conditions of any kind. Unlike a game, FlightGear has no way to win. More importantly, we've designed FlightGear to be used in the real world, both by research engineers experimenting with new designs, and pilots looking to learn or maintain currency. Some of our users have gone on to get their pilot's licenses — I'm one of them.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the LinuxDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.