• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

When are BGLs unloaded?

F

fs1

Messages
302
Country
argentina
I saw a lot of complaints on OOMs reports when flying let's say from one to another airport/scenery with heavy RAM load.

Does FSX unloads from memory the BGLs that aren't used anymore or let's say that are more than 'x' NMs from the airplane?

How does the FSX dynamically manage this? Is there any way to force dynamically a BGL to unload?

Thanks for the insights!
 
Last edited:
I think it must be distance related although I have never checked the values. I don't know of any way to force a bgl file to unload other than going to a far distant place.
 
scruffyduck said:
I think it must be distance related although I have never checked the values. I don't know of any way to force a bgl file to unload other than going to a far distant place.
Click to expand...

Thanks Jon for your message. Are BGLs always unloaded ? There are some users experiencing OOMs when flying from one to another scenery stating that the origin never gets unloaded. For example, in a EGLL-LIRF flight, EGLL never gets unloaded even at arrival being more than 500NMs away !

Thanks for your insight.
 
Last edited:
To be honest I have never investigated it other than the requirement that bgl files cannot be updated if they are in use with FS. ADE checks to see if a file is in use - which I assume means loaded. I know that various tricks are employed to so that users don't have to shut down FS in order to update a bgl file. This isn't really what you are referring to and my knowledge does not stretch that far. I can imaging a lazy loading or lazy unloading system. If FSX behaves anything like a NET program then it will have some sort of garbage collection to remove files no longer being used from memory. However there is nothing to say when that file gets unloaded. It would be nice if there was a mechanism to poll loaded files and say - the user is more that 100Nm away so I can get rid of this one. That could be wishful thinking though and I could imagine that once loaded a file is just using memory if it is out of range of the graphics display and will stay there unless the sim needs memory

Also an OOM exception or error is one of the most misleading in the windows programming world. It does not mean - oops ran out of all the memory (though it might) but it means that some process cannot find enough memory or handles to complete a process. Often with graphics engines and images this means continuous memory. Programs could only need a Mb or two but if they can't find a continuous chunk that big then they will declare OOM and fold the tent.
 
If I remember correctly, FSX loads data in a ring around the current user location. The size of the ring depends on your settings, also on the type of data. Some BGLs are loaded for the entire world at all times, but only at extremely low detail. Generally the highest detail is around the user and it gradually drops with distance. The rate that it drops off is based on the terrain lod radius setting in fsx.cfg. Scenery and autogen have similar "rings" around the user but I think their distances might be hardcoded.

Also, there is some caching of certain data going on so it is possible that there is something loaded that is farther away, but it wouldn't be getting used. It just keeps it in memory incase it gets accessed again soon, and these are all bounded.

If people are running out of memory, their best bet is to turn down their settings and make sure they are using a modern (Win7 or newer) 64 bit OS.
 
Thanks Steve. So I get they get cleared from memory by some form of garbage collector that looks at the files and if they are out of range then removes them?
 
That sounds right, Jon. I personally wish that instead of a 'ring' they'd use an offset 'oval' such that stuff behind the aircraft could be flushed earlier and more quickly.
 
n4gix said:
That sounds right, Jon. I personally wish that instead of a 'ring' they'd use an offset 'oval' such that stuff behind the aircraft could be flushed earlier and more quickly.
Click to expand...

That makes a lot of sense Bill but I suppose if the user makes a turn then suddenly there is a lot of stuff to load?
 
Well yes, in the case of a sudden 180º course reversal, that would be the case, but even then such turns take some ten's of seconds, which should allow plenty of time for the scenery to load and render.
 
Thanks all for the insights.

Regarding your comment Bill:

n4gix said:
That sounds right, Jon. I personally wish that instead of a 'ring' they'd use an offset 'oval' such that stuff behind the aircraft could be flushed earlier and more quickly.
Click to expand...

How fast/far do the BGLs behind the aircraft are unloaded? Does the lod radius control this ?

Thanks!
 
Fed, I have no real idea whatsoever, but I suspect that it is indeed the LOD radius of each .bgl file, in which case that's something that cannot be changed by us.
 
Well, someone could quickly look behind them. It is all about viewing area, and not predictive of your position.

Jon, I think some bgls are probably thrown out shortly after they are loaded. It is more useful not to think in terms of BGL, but in terms of runtime data. A lot of data is loaded from the bgl, processed into some other form, and the bgl is thrown out immediately even though that runtime derived data is still in memory. The terrain system also makes a lot of use of LRU cache of data, so even though no data from a file is being used, it might still be loaded just because some newer data hasn't been loaded in yet.

Autogen is a good example of this. When an AGN file is needed for a particular level 15 qmid it gets loaded and put into an LRU cache. It is then used to generate autogen placements for that particular spot in the world using the AGN file as a template. Afterwards the AGN is no longer used, but it is still in memory because it is in the LRU cache. The generated autogen placements for the qmid is in memory as long as you are in the ring of autogen, even if the AGN gets unloaded. If enough other AGN files are loaded, eventually the original one will be removed form the cache and unloaded. Unless there is another 15 qmid cell in the area that uses the same AGN, in which case it is either used from LRU cache if it is still there, or it just gets loaded from disk again.

Terrain textures work in a similar way. DEM, OBX, and vector data probably don't use a cache since they are specific to a certain spot on Earth.
 
Thanks Steve - that is an interesting insight.
 
Steve, thanks for your insights.

Also, Bill and Jon thanks for your inputs as well.
 
You must log in or register to reply here.
Back
Top