Presentation Recipe: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (suitable demo spots/aircraft and flights)
m (cat: FlightGear)
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
This presentation recipe is intended to be very prescriptive about what you can do or a demo.
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]].


The presentation isn't so much a formal presentation, but what is needed to have flightgear running in a booth.


This recipe can (should) be also used as a "''this is what FlightGear can do''" demonstration as well.
This recipe can (should) be also used as a "''this is what FlightGear can do''" demonstration as well.
Line 9: Line 11:
* [[Suggested Aircraft]]
* [[Suggested Aircraft]]
* [[Suggested Flights]]
* [[Suggested Flights]]
* [[Challenging Airports]]
* [[Suggested Prerecorded Flights]]
You may want to check out [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] for help with hardware-related decision making.
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]].


== Scenario ==
== Scenario ==


The basic premise is that you don't want a demo 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.  
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...
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...
Line 18: Line 27:
This demonstration would be also suitable for benchmarking flightgear on different hardware as well as showing users what is possible for a new install.
This demonstration would be also suitable for benchmarking flightgear on different hardware as well as showing users what is possible for a new install.


== Video ==
Here is a video in a simple 4+4 configuration.
http://www.youtube.com/watch?v=brG3-yyvv9Q


== Hardware ==


For this particular demonstration recipe, a single Linux machine with an AMD Phenom 9550 processor with 4 FireGL v5600 cards with a AMD RD790 chipset, each running 2 displays for a total of 8 displays. 
== Sample Monitor Layouts ==


The layout used was a 4+4 layout as shown below
=== 4+4 ===


   +-+-+-+-+
   +-+-+-+-+
Line 36: Line 39:
   +-+-+-+-+
   +-+-+-+-+


http://www.youtube.com/watch?v=brG3-yyvv9Q


3+5 layout as shown below would be slightly better since the all cameras are offset from the centre screen (indicated by an X).
=== 3+5 ===


     +-+-+-+
     +-+-+-+
Line 45: Line 49:
   +-+-+-+-+-+
   +-+-+-+-+-+


If space is tight, then a 1+3 configuration is good as well, like this URL http://www.youtube.com/watch?v=iPO-9sf8HJ0
=== 1+3 ===


     +-+
     +-+
Line 53: Line 57:
   +-+-+-+
   +-+-+-+


== Software ==
http://www.youtube.com/watch?v=iPO-9sf8HJ0
 
=== 7+9 ===
 
(Yes, really, on one system)
 
    +-+-+-+-+-+-+-+
    | | | | | | | |
  +-+-+-+-+-+-+-+-+-+
  | | | | |X| | | | |
  +-+-+-+-+-+-+-+-+-+
 
== Setup ==


This recipe is based on the CVS version of FlightGear as of 9 August 2008.
This recipe is based on the CVS version of FlightGear as of 9 August 2008.
Line 66: Line 82:


   aticonfig --initial=dual-head --adapter=all
   aticonfig --initial=dual-head --adapter=all
=== Flightgear Setup ===
Ideally, setting FlightGear up for a demonstration sholdn't be onerous, but the ''under the hood'' configuration of flightgear is quite imposing.  Follow this description to get flightgear running in this demo.
# Config file
The stock configuration file from CVS for data from July 2008.
: ==== Maximum Eyecandy ===
:
: Turn on maximum eyecandy (maximum LOD, scenery, AA, etc).


===== Cameras and Screens =====
===== 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]].
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 ====
==== 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. The data used in this demo was http://www.jentronics.com/fgfs/flight2.out.gz.
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 ==
== Running the Demo ==


=== Commandline ===
=== Command line ===


Use the command as follows
On [[command line]], use the command as follows


   ./fgfs --enable-fullscreen --generic=file,in,25,flight.out,playback,repeat --fdm=external --aircaft=f15c3d
   ./fgfs --generic=file,in,25,flight.out,playback,repeat --fdm=external  


This runs flightscreen with the primary screen as fullscreen, using a 25 cycles/sec data from a playback file called flight.out, and repeats forever.  The video above is using an F18.
This runs flightscreen using 25 cycles/sec data from a playback file called flight.out, and repeats forever.


=== User interaction ===
=== User interaction ===


The demo is on rails, the only thing that can be changed is the view by pressing "v".
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.


== Wishlist ==
== Tweaks ==
 
=== Enabling Multithreading ===


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.
In preferences.xml, add the following lines to the sim/rendering section.


=== Multicore ===
<multithreading-mode>CullDrawThreadPerContext</multithreading-mode>


Currently, a high end system is going to have 1 or 2 Quad-core processors.  Seeing a 25 fps frame rate with a system load at 25% is a little bit sad.  Working out where multiple cores can be used within flightgear would make life a lot nicer :).
You can choose from SingleThreaded, CullDrawThreadPerContext, DrawThreadPerContext, CullThreadPerCameraDrawThreadPerContext.


=== Preloading ===
== Wishlist ==


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


=== A library of flightdata ===
=== Preloading ===


Having some nice tours of several favoured areas would be a great help. Getting the flightdata referred to above took quite a lot of smooth talking on IRC :).
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.


=== Scripted Flights ===
=== Scripted Flights ===
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).
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 [[FlightGear Headless|regression testing framework, too]].


=== More Traffic ===
=== More Traffic ===


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


=== More Eyecandy ===
=== More Eyecandy ===


Without multiple monitors, FlightGear looks quite simplistic. Use of shaders and other visual touches would add to FlightGear's appeal.
Without multiple monitors, FlightGear looks quite simplistic. Use of shaders and other visual touches would add to FlightGear's appeal.


=== More Models ===
=== More Models ===
Line 140: Line 145:
=== Runtime flight data Changing ===
=== 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 nive to have, but shouldn't be necessary with the right recorded flightdata.
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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17126.html]).
 
=== 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 ===


=== Easier initial 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 [http://cvs.flightgear.org/viewvc/source/docs-mini/README.multiscreen?revision=1.1&view=markup] so that the screens could be set up and modified dynamically, possibly even using an XML dialog.


A nice simple way to set the screens rather than modifying an XML file would be ideal.
[[Category:FlightGear]]

Revision as of 16:24, 12 March 2014

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:


You may want to check out Hardware Recommendations and Notebooks known to run FlightGear for help with hardware-related decision making.

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.

Scenario

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

4+4

 +-+-+-+-+
 | | | | |
 +-+-+-+-+
 | | |X| |
 +-+-+-+-+

http://www.youtube.com/watch?v=brG3-yyvv9Q

3+5

   +-+-+-+
   | | | |
 +-+-+-+-+-+
 | | |X| | |
 +-+-+-+-+-+

1+3

   +-+
   | |
 +-+-+-+
 | |X| |
 +-+-+-+

http://www.youtube.com/watch?v=iPO-9sf8HJ0

7+9

(Yes, really, on one system)

   +-+-+-+-+-+-+-+
   | | | | | | | |
 +-+-+-+-+-+-+-+-+-+
 | | | | |X| | | | |
 +-+-+-+-+-+-+-+-+-+

Setup

This recipe is based on the CVS version of FlightGear as of 9 August 2008.

Operating System

This recipe calls for Linux, the above example used Ubuntu 8.04 and the ATI Proprietary Linux Graphics driver.

X-Windows Setup

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

Command line

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.

User interaction

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.

Tweaks

Enabling Multithreading

In preferences.xml, add the following lines to the sim/rendering section.

<multithreading-mode>CullDrawThreadPerContext</multithreading-mode>

You can choose from SingleThreaded, CullDrawThreadPerContext, DrawThreadPerContext, CullThreadPerCameraDrawThreadPerContext.

Wishlist

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.

Preloading

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.

Scripted Flights

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.

More Traffic

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.

More Eyecandy

Without multiple monitors, FlightGear looks quite simplistic. Use of shaders and other visual touches would add to FlightGear's appeal.

More Models

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 [1]).

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 [2] so that the screens could be set up and modified dynamically, possibly even using an XML dialog.