Anything below about 15 frames per second (fps) is close to unusable, or at least, will not be enjoyable. In fact, you'll probably want to aim for 25-35 fps minimum, and a maximum frame spacing (latency) of ~50 ms.
Additionally, the more the framerate decreases, the more other features of the simulation will suffer. The current FlightGear software architecture is such that long rendering times (slow framerates) may prevent other parts of the flight simulator, such as the autopilot, from having sufficient CPU time to respond correctly in the context of the simulation.
FlightGear's framerate is influenced by various factors, including:
- scenery complexity (terrain, clouds, trees, particles, random 3D objects, multiplayer/AI traffic, animated jetways)
- cockpit complexity (2D vs. 3D)
- environmental options (eg. visibility, precipitation)
- FDM update interval
- AI scenarios
- aircraft speed (scenery paging)
- rendering options
- debugging level
You can disable most features that often adversely affect framerate. Here is a collection of settings that you may change to improve your framerate. Please note that some of these will only take effect if they're specified at startup and cannot be changed after the simulation has started.
If you are seeing FlightGear crashing, please see Howto:Debugging FlightGear Crashes (also take a look at this if you find that enabling certain features slows down the simulator considerably). If you are experiencing system lockups, please see System Crashes.
Analyzing lag properly (frame spacing and worst case latency)
In FlightGear => 2.60, use the menu option Debug => Monitor System Performance to analyze stutters.
In a perfect world, min/max/mean values should be almost identical for every subsystem - and standard deviation should be almost 0. Larger differences / high standard deviations result in a sloppy simulation and stuttering movements, though they'll hardly influence the frames-per-second value at all.
Also, imagine a system producing 100 frames in 0.5 seconds, then blocking completely for another 0.5 seconds. The fps display would still show "100fps", which seems great. But the 0.5 second stutter cause the visual performance to be terrible. That's why I prefer to display "(worst-case) frame spacing" instead of fps (View => Display Options => Show frame spacing). The frame spacing for the previous example would show "500ms", while a system producing 100 frames with perfectly even spacing would show "10ms".
So, frame spacing is a much better property to judge visual quality than just watching fps.
For more info, please see Howto: Use the system monitor.
Hints for users
As of FlightGear 2.0.0, a growing number of shaders is being implemented into FlightGear. While these do make your flights visually appealing, they tend to have quite an impact on most computers. Luckily you can easily disable shaders in the View > Rendering Options dialog. As of FlightGear 2.6.0 an advanced shader options dialog is available, in which you can adjust every single shader's setting. To disable the shaders on startup, run FlightGear with:
Leave out the
--prop: prefix when adding the command via Advanced > Properties on the last page of FGRun.
It requires some testing to find out what settings are best for your computer, but it's defenitely worth spending some time on!
Starting with FG >= 2.10, FlightGear releases will default to shader quality level 0 for these reasons.
Don't run FlightGear while also running another application, except if you need it. The two programs are competing for the CPU's proccessing power. As a basic rule, try to minimize the amount of programs open, so FlightGear can have the biggest portion of the CPU Times. Graphics-intensive programs also drain the GPU/graphics card, so you may be able to add a few frames.
Most stuttering, or lag, in FlightGear is caused by AI traffic. Especially heavy models need quite some time to load, eg the F-14 or the B-1B. Every time a new aircraft enters your local area, your computer has to load the model for that particular aircraft. The time required to read the data from the drive creates a stutter, or lag, which can range from a minor annoyance to a crash. The busier the place you fly, the more lag you'll get; eg flying around KSFO will generate more lag than a flight near EGLL, since there is more traffic near KSFO.
Turning off just the computer-generated aircraft (leaving the MP traffic visible), can be done by adding a command to your commandline:
Or via FGRun through Advanced > Properties, add a new property with /sim/traffic-manager/enabled=0
Operating system specific
Many newer Linux distributions, like openSUSE 11.2, come with KDE4 as a desktop environment. While it allows some fancy desktop effects, it is known to consume enough computing power from the CPU and the graphics card to slow FlightGear down by 10 frames per second or even more. Choosing another window manager from the login screen, like xfce results in higher FlightGear performance. Setting "Compositing" to "off" in KDE4 might also help.
The more FlightGear has to write out to the log, the more framerates will be sacrificed. On normal usage, one is best of with the highest log level, which is alert. In FGRun this can be set via Advanced > Debugging, on a commandline you'll use --log-level=alert (or simply remove an existing --log-level command, as alert is the default).
Most notebooks that run Windows 7 have the so called Optimus Technology (NVidia) or Hybrid Graphics technology (ATI) onboard. This is meant to increase battery life, by automatically switching of the powerfull graphics card when it's not needed. However, FlightGear needs it all the time, even if Optimus says it doesn't! This miscommunication results in low framerates (because your computer will run Flightgear on the weak onboard processor) and often FlightGear will quit with the following error:
Unknown exception in the main loop. Aborting... Possible cause: Not enough space
To make use of the powerful graphics card, perform the following steps:
- Go to the NVidia control panel. Probably located in the Windows Control Panel.
- Open the 3D Settings tab. Now there's two options you can take:
- On the "General settings tab", set "Prefered graphics processor" to NVidia. The NVidia card will now be used for all software. This can decrease battery life significantly.
- On the "Programm settings" tab, locate fgfs.exe (eg. C:/Program Files/FlightGear/bin/win32/fgfs.exe) and assign the NVidia card to it. From now on the NVidia card will be used for FlightGear.
It is possible that texture compression is not handled correctly by the graphic card or the driver, causing stuttering (usually when turning left/right or when loading new tiles). Compression can be disabled by adding
on the command line (or in FGRUN options). This is for nVidia and ATI cards . And usefull for Intel integrated chips with MesaGL, that suffer from bugs with texture compression and fgfs.
Hints for developers
Contrary to what many people believe, the impact of high vertex-count models on framerate is fairly minimal. In addition, for graphics hardware built after 2004 and intended for games (example: Nvidia GeForce 6 series), textures are close to, or completely, free. Today (in 2010), the major graphics bottleneck is between the CPU and the GPU. The goal in optimizing models is to store as much as possible on the GPU and reduce the number of rendering commands sent to the GPU. For graphic artists, the key things to remember are:
- Reduce the number of different textures used on a model to a minimum. It's better to use a few (or one!) big textures than many little ones.
- Avoid mixing textured and untextured geometry in the same model. Build the coloring into the texture map instead.
- Within your modeling tool, try work with large meshes instead of groups of small meshes - but please don't mistake this as a request for grouping multiple, distinct buildings into a single AC3D file. I know that this can result in a very unpleasant workflow; we are working on optimizations in FlightGear that will combine mesh parts automatically.
- Textures containing alpha cause various problems. In order to be rendered correctly, translucent geometry must be sorted by distance on the CPU. Furthermore, geometry is sorted on a course level (basically by mesh), so you may see various artifacts. If you have some transparent parts of a model, you should violate the first rule above and assign those parts to their own texture.
- Don't assign an RGBA texture to a model that is completely opaque!