This presentation recipe is intended to be very prescriptive about what you can do or demo. The presentation isn't so much a formal presentation, but what is needed to have FlightGear running in a booth.
Note: From the perspective of somone who actually does public presentations of FlightGear, this list appears to have diverted into a rather unrelated feature wishlist. Therefore please read with care. As an alternative, check this FlightGear Expo Checklist.
This recipe can (should) be also used as a "this is what FlightGear can do" demonstration as well.
For a list of well-populated scenery locations, feature-rich aircraft and interesting flights you may want to check out:
- Suggested Airports
- Suggested Aircraft
- Suggested Flights
- Challenging Airports
- Suggested Prerecorded Flights
If you are possibly interested in connecting multiple instances of FlightGear via network in a multiplayer fashion, you may want to check out Howto: Set up a multiplayer server.
- 1 Scenario
- 2 Sample Monitor Layouts
- 3 Setup
- 4 Running the Demo
- 5 Tweaks
- 6 Wishlist
The basic premise is that you don't want a demo to allow people to crash or involve a lot of time with people controlling the system rather than selling your wares. The basic premise is that the system can run unattended for a number of days without needing either a pilot or a technician on hand to babysit the system.
Of course there will always be a Top Gun that walks past and wants to fly, the restart of the demo should be trivial as well...
This demonstration would be also suitable for benchmarking flightgear on different hardware as well as showing users what is possible for a new install.
Sample Monitor Layouts
+-+-+-+-+ | | | | | +-+-+-+-+ | | |X| | +-+-+-+-+
+-+-+-+ | | | | +-+-+-+-+-+ | | |X| | | +-+-+-+-+-+
+-+ | | +-+-+-+ | |X| | +-+-+-+
(Yes, really, on one system)
+-+-+-+-+-+-+-+ | | | | | | | | +-+-+-+-+-+-+-+-+-+ | | | | |X| | | | | +-+-+-+-+-+-+-+-+-+
This recipe is based on the CVS version of FlightGear as of 9 August 2008.
This recipe calls for Linux, the above example used Ubuntu 8.04 and the ATI Proprietary Linux Graphics driver.
This recipe used "multi-head" mode. With a Linux Catalyst 8.9 (Driver version 8.53 or later) and FireGL cards, this is as simple as
aticonfig --initial=dual-head --adapter=all
Cameras and Screens
With CVS OSG based flightgear (basicaly CVS flightgear from July 2008), you can set up multiple cameras as using the repeated sections of the code below.For more info, check out Howto:Configure Camera View Windows.
Prerecorded Flight Data
This is probably most important part. Most people suck at flying aircraft with a mouse and keyboard, so having prerecorded data is must. Get your flight data from the Suggested Prerecorded Flights
Running the Demo
On command line, use the command as follows
./fgfs --generic=file,in,25,flight.out,playback,repeat --fdm=external
This runs flightscreen using 25 cycles/sec data from a playback file called flight.out, and repeats forever.
The demo is on rails, the only thing that can be changed is the view by pressing "v". Right-clicking the mouse twice will allow you to adjust the view angle for the particular view that you want.
In preferences.xml, add the following lines to the sim/rendering section.
You can choose from SingleThreaded, CullDrawThreadPerContext, DrawThreadPerContext, CullThreadPerCameraDrawThreadPerContext.
To make a demonstration of FlightGear even more compelling there are a few things that would make life a lot easier, and also take less explaining for the floor staff.
Since we are talking about multicore systems, one of those cores could at-risk pre-load the geometry and textures well before flightgear needs them. This prevents the annoying stalls on the first pass through the recorded demo.
Given that there is currently no easy way (available in the UI) to create/save flights in a native FlightGear format (to exchange/share such flight data for replaying), it might be interesting to investigate the possibilities of using the Nasal programming language to create scripted flights, so that scripts could be run in order to fly an aircraft (using the autopilot), in the beginning this could be a simple standard pattern in a no-wind situation, later on the script could be modified to also allow for more involved scenarios (flying holding patterns, instrument approaches etc). This would be an interesting option as it would require no changes to the fgfs core and could be implemented using purely Nasal and XML, but also because "exchanging flights" would not require exchanging actual pre-recoded flight data, but only tiny scripts or XML files to really fly the aircraft (most of this could be based on the already existing Nasal/XML tutorial system). In fact, having support for this would facilitate using FlightGear as its own regression testing framework, too.
Flying on your own is interesting, but having other things in the air is even better. Having this recipe updated with extra links to data would be great.
Without multiple monitors, FlightGear looks quite simplistic. Use of shaders and other visual touches would add to FlightGear's appeal.
Adding more models and improved textures in the area the precorded data goes would go a long way in improving the visual experience.
Runtime Aircraft Changing
Different people like different aircraft, being able to change aircraft mid-flight would be great - particularly if you are using precorded data.
Runtime flight data Changing
Being able to switch between pre-recorded data and free-flying would be a great asset to flightgear. This is lower on the priority list, having this is a nice to have, but shouldn't be necessary with the right recorded flightdata.
Continuing replayed/pre-recorded flights
The ability to replay arbitrary flights (via Instant Replay) to a certain point and then interactively continue a flight would be a great addition in order to enable people to easily redo certain portions of a flight (i.e. shooting approaches or entering holds), this is something that's supported by many simulators used for professional pilot training and allows for really rapid turnaround times, so that either multiple users would get a chance to easily redo a flight, or one user could easily redo different segments of one flight (this has been previously requested on the mailing list ).
Option to save replay buffer to a file
Having an option to easily save the active replay buffer (as detailed in Instant Replay) to a file would make it much easier for users to provide pre-recorded flight data.
Easier initial camera setup
A nice simple way to set the screens rather than modifying an XML file would be ideal, this could be made possible by binding SGPropertyChangeListeners to the currently used properties  so that the screens could be set up and modified dynamically, possibly even using an XML dialog.