Board index FlightGear Support

32bit and low memory systems, read this

All general support: help on flying, installation, hardware, getting online etc. There are lots of users and developers to help you out.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- where did you download your aircraft/scenery from?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).

Please report any bugs not specific to an aircraft on the issue tracker.
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

32bit and low memory systems, read this

Postby Thorsten » Tue Feb 10, 2015 3:57 pm

The defaults of a current Flightgear installation are appropriate for a fairly modern 64bit system. If these are not changed, problems on 32bit architectures and 64bit systems with <4 GB are likely.

How much memory does FG use?

The answer depends almost exclusively on the settings - what aircraft do you run, what scenery do you want to see, how many scenery objects are to be displayed, what is the selected visibility. In numbers, it can range anywhere from 470 MB (ufo over ocean) to >12 GB (modern airliner, 150 km visibility range in hires scenery).

Most numbers given here are taken from Rebecca Palmer's test with the 3.4 RC posted on the mailing list.

What drives memory consumption?

Roughly, it can be understood as three components as

Memory = Base + Aircraft + Terrain * visibility^2

Here, base is about 450 MB, i.e. what the FG core uses. This contribution can not reduced by any options. Aircraft is specific for the aircraft you select - more complex and more richly textured aircraft need more memory. A few examples:
  • c172p: 250 MB
  • Citation-X: 100 MB
  • 777-300: 650 MB

Typically, the sum of Base and Aircraft is less than a GB, so the rest is terrain - the combination of terrain mesh, objects and visibility is the single most influential factor for memory consumption.

How does the terrain affect memory usage?

The terrain mesh has a certain vertex density which determines how finely it resolves features such as roads, landclass boundaries or elevations. All these vertices have to be available to the graphics card to be rendered, i.e. all visible terrain mesh needs to reside in memory. Hence, if you know the memory consumption for one visibility, you can estimate that it will increase fourfold if you double visibility and decrease by a factor four if you half visibility.

The vertex density multiplies the visibility factor. The old World Scenery 1.0 has a fairly low vertex density, and hence hardly affects memory at all for visibilities < 30 km. The new World Scenery 2.0 has a much higher vertex density - in Europe almost a factor 100 more data - and does affect memory quite a bit.

The difference is (KSFO runway, default settings, default visibility of 16 km - scenery-only memory consumption)

  • new World Scenery 2.0: 1.9 GB
  • old World Scenery 1.0: 300 MB

(i.e. in order to get the same memory occupancy with the new scenery than with the old scenery, you'd have to reduce visibility to ~6.5 km - the situation in Europe is even more drastic).

What should I do to run FG with a low memory footprint?

From the above considerations, in decreasing order of importance follow:

  • disable terrasync and revert to the 1.0 World Scenery (this can be manually downloaded from the FG website)
  • use settings to limit visibility (setting a low LOD bare also works, but this destroys the visible horizon and looks artificial - setting/limiting the visibility directly works equally well and keeps a natural-looking hazy horizon)
  • do not use random objects, trees or buildings (which have their own memory footprint)
  • avoid highly detailed planes
  • manually resize textures to make them smaller (note that this gains you a few tens of MB only - hardly worth the effort in most cases)

Using all of these measures, it should be possible to run FG with under 2 GB of memory footprint.
Posts: 11714
Joined: Mon Nov 02, 2009 8:33 am

Re: 32bit and low memory systems, read this

Postby julianibus » Mon Aug 17, 2015 3:01 pm

With my 32-bit 4 GB RAM machine I can confirm the problems spoken about in the post above.

Nevertheless I've monitored the memory consumption for several hours during a flight from EDDF to KJFK in a Boeing 777-300ER. Bare visibility was set to 5000m.

The result is the following:
(Time in HOURS on the horizontal axis)


The end of the graph marks the point when fgfs crashed after almost 6 hours - probably due to aggressive memory consumption.
So is it true that memory usage continuously increases until the very end when the system has to kill the fgfs process demanding more memory than allowed? That would mean that fgfs will crash on every system after a computable time of flying depending on the amount of available memory...
Last edited by julianibus on Mon Aug 17, 2015 4:35 pm, edited 3 times in total.
Posts: 4
Joined: Wed Mar 18, 2015 4:43 pm

Re: 32bit and low memory systems, read this

Postby legoboyvdlp » Mon Aug 17, 2015 4:20 pm

However, with 3.5 and 5GB of RAM on a 2012 laptop I have no problem - I can run at a stable memory the 777 for ages. And the A330 with canvas too.
Actually I have NOT had more than two or three crashes besides those times you crash when you press X. I know, I know, use Menu > Quit but I tend to be lazy about things like that.
User avatar
Posts: 7743
Joined: Sat Jul 26, 2014 1:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: 32bit and low memory systems, read this

Postby Thorsten » Mon Aug 17, 2015 5:25 pm

The end of the graph marks the point when fgfs crashed after almost 6 hours - probably due to aggressive memory consumption.

Or rather not. At the end of the graph, memory consumption is 2.7 GB, whereas you should have about four available - so why would you think this was an out of memory crash?

That would mean that fgfs will crash on every system after a computable time of flying depending on the amount of available memory...

I would assume there is always some amount of residual leakage, so the statement is true in principle, though if the time constant is exceeding, say, 100 hours, does it really matter?

You seem to add 100 MB every hour, which would give you another 13 hours. A 64bit system doesn't actually crash due to out of memory but starts swapping - and if it swaps leaky (actually unused) memory, it can continue to do so for a long, long time.
Posts: 11714
Joined: Mon Nov 02, 2009 8:33 am

Re: 32bit and low memory systems, read this

Postby Hooray » Mon Aug 17, 2015 5:44 pm

too many things missing here to draw conclusive conclusions. For instance, how do you determine/sample OS/process memory and swap utilization ?

In general, a backtrace is a better way to determine if/why something got killed or simply just segfaulted due to faulty code, especially airliners are likely to use tons of resources, but also subsystems that are not normally exercises, a number of recently identified bugs were related to the route manager component in FG, so I would suggest to be careful when it comes to drawing conclusions.

For starters, you will need a reproducible test case - e.g. a startup profile, or a saved flight (fgtape) and then play with different startup/runtime settings (location/aircraft, enabled/disabled features) to see if/how the bug can be reproduced.

Once that is the case, post this information here, so that others can try to reproduce the bug.
At some point, you will benefit from being able to use a debugger, to get a backtrace - or at least understand your OS sufficiently well to get runtime stats for the fgfs process from it.

Concerning swapping, that too, can be monitored on Windows/Mac OS and Linux, and I have in fact posted patches for *nix based OS (search: "swapping patch subsystem").

In general, there are a lot of uneducated myths about FG resource utilization floating around here, and it would definitely help to document a few "best practices", like sanhozay began a while ago: ... ory_Issues

If you have anything to contribute to this article, feel free to get in touch via its talk page - and/or directly edit the corresponding article
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Posts: 11923
Joined: Tue Mar 25, 2008 8:40 am

Return to Support

Who is online

Users browsing this forum: AhrefsBot [Bot] and 1 guest