Performance depends on your hardware, you'll typically want to aim for at least 30-60 hz/fps - so something in between (aka 45) should be fine (if steady) - note that your frame spacing latency is separately shown.
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.
20fps is at the low end of the usability range, it's OK but not great - YMMV. Anything lower than this is pretty much unacceptable, at least for VFR, as things start to get very choppy at 15fps. If 20fps is all your hardware can handle then you will still have a usable sim with acceptable results depending on how high you have your rendering options set. For those with lower end hardware you should probably favor frame rate over eye candy. My personal preference is to never have the frame rate drop below 30fps because things feel smoother and you will have more headroom to handle things that can cause choppiness.
Older versions of FG (before 1.9) would get choppy if the frame rate got too high (well above the monitor refresh rate) but newer versions don't do this at least not on my hardware (Intel I7-4770 and NVidia GTX 770 - very high end system) and not on older hardware I was running until recently (IE. with FG versions from 2.0 to 2.6 with an NVidia GTX 7900 GPU). I just let my hardware run at whatever rate it wants to because I now have enough hardware to handle anything FG throws at it. In complex scenes like around KSFO this hardware will run in the 40s and 50s most of the time and sometimes faster with rendering options up all the way at very high resolution (2560X1600). This is definitely very nice and does not feel laggy even at very high aircraft speeds at very low altitudes (350mph to 400mph on the deck). In simple scenes (think desert - no trees, no buildings, no clouds, no AI or MP aircraft) I will see frame rates in the 150s to 180s and I don't see any issues with the high frame rate in FG 2.10/2.12 unlike versions before 1.9. Depending on your system setup you may need to throttle the frame rate to prevent choppiness at high frame rates but I don't think high frame rates will cause issues with current version of FlightGear - again YMMV. Most users don't have enough GPU power to be concerned about frame rates getting too high with current FlightGear versions and those (lucky) users can, to some extent, throttle frame rates by increasing/maximizing eye candy settings.
In general the faster the frame rate the better at least up to your monitors refresh rate. This is typically 60FPS but some monitors support speeds as high as 120FPS. Keep in mind that things like nasal listeners, animations and other parts of the sim run at the video frame (main loop) rate and if your frame rate gets too low these things might not work as well as they should. As an example if your aircraft is one armed with machine guns you may see the guns change rate of fire if your frame rate is too low. This will definitely be the case with the JSBSim P-51D if your frame rates are below 30fps. As more things are decoupled from the main loop this should become less of an issue in future versions of FlightGear.
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.
- 1 Analyzing lag properly (frame spacing and worst case latency)
- 2 Hints for users
- 3 Hints for developers
- 4 Related content
- 5 External links
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!