Simulating the Pilot's view

Figure 3: Looking east from Mount Sutro, just south of Golden Gate Park. The scenery shows the shoreline, variations in land use from scrubland on the hill and urban beyond, randomly placed trees in the scrubland and buildings in the urban area, custom created additional objects for the tower, downtown buildings and the Bay Bridge, and an interstate freeway. The sky shows the limited visibility due to haze and some scattered clouds.

The new FlightGear pilot will probably not want to remain within the San Francisco bay area, which is the small scenery patch included in the Base package. The scenery server allows the selection and retrieval of any region of the world. Joining other users in the sky is another possibility.

Due to limited monitor size, the view that is available on a normal computer is a poor substitute for the wraparound windows of general aviation aircraft. This is especially true when the simulated aircraft has an open cockpit and an unrestricted view in almost all directions.

FlightGear can make use of multiple monitors to provide a nicer external view, possibly even wrap around, without special cabling. The additional computers and monitors need not be dedicated to this purpose. Once the command lines and fields of view (relative to the pilot) for each of the additional computers have been established, the main computer will make the necessary data available irrespective of whether those other computers are actually running FlightGear. In consequence, each of the additional computers can change from a `cockpit window' to a office software workstation (for someone else) and, when available again, rejoin the FlightGear simulation session.

FlightGear has built in support for network socket communication and the display synchronizing is built on top of this support. FlightGear also supports a null or do-nothing flight model which expects the flight model parameters to be updated somewhere else in the code. Combining these two features allows you to synchronize displays.

Here is how Curt Olson set up the example in figure 2:

1. Configure three near identical computers and monitors.
2. Pick one of the computers (i.e. the center channel) to be the master. The left and right will be slaves s1 and s2.
3. When you start runfgfs on the master, use the command line options
   -native=socket,out,60,s1,5500,udp
   -native=socket,out,60,s2,5500,udp
   respectively to specify that we are sending the ``native'' protocol out of a udp socket channel at 60 Hz, to a slave machine on port 5500.
4. On each slave computer, the command line option
   -native=socket,in,60,,5500,udp shows that we expect to receive the native protocol via a udp socket on port 5500. The option -fdm=external tells the slave not to run it's own flight model math, but instead receive the values from an ``external'' source.
5. You need to ensure that the field of view on the scenery matches the apparent size of the monitor to the pilot. -fov=xx.x allows you to specify the field of view in degrees on each computer display individually.
6. -view-offset=xx.x allows you to specify the view offset direction in degrees. For instance,
   -view-offset=0 for the center channel,
   -view-offset=-50 for slave 1, and
   -view-offset=50 for slave 2.

There is no built in limit to the number of slaves you may have. It wouldn't be too hard to implement a full $360^o$ wrap around display using 6 computers and 6 projectors, each covering $60^o$ field of view on a cylindrical projection screen. Ideally, the master computer should be chosen to be whichever visual channel has the lightest graphical workload. This might be the dedicated instrument panel, for example. If the master computer has a heavy graphical workload, the other channels will usually lag one frame behind. Select the graphics realism parameters to ensure that all the visual channels consistently achieve a solid and consistent frame rate ($30\,Hz$ for example) and, if your video card supports it, lock the buffer swaps to the vertical refresh signal.

For optimal results, make sure the FOV each display subtends, matches the actual FOV that display covers from the pilot's perspective. From the top view, draw a line from the pilot's eye to each edge of the display. Measure the angle and use that for your visual channel configuration. Draw a line from the eye to the center of the display. Measure the angle from that line to the dead center straight ahead line. Use that angle for the view offset. This ensures that all objects in your simulator will be exactly life size.