Efficiency of FSX scenery library?

[Guest cbuchner1]

Hi there,before running an actual experiment on it...Would anyone have a rough idea how FSX would deal with massive amounts of BGL files in the scenery library? I am considering covering the globe at LOD 8 with individual BGL files for elevation data. Summed over all land mass, this could result in about 150000 files in total.Will FSX come to a grinding halt or does it actually have something like an efficient lookup mechanism for coordinate to BGL (binary trees, quadtrees, whatever)? ;-)Christian

[LuisFelizTirado 33]

Hello Christian,The QMID grid is your friend. Modulate the amount of files loaded through the LOD radius slider.Best regards.Luis

[Guest cbuchner1]

I am aware of the fact that FSX will only load a subset of the provided "mesh tiles" in BGL format. The question is: is the lookup fast enough or will it FSX take seconds to locate each bgl file...

[Holger 0]

Hi Christian,don't know the technical details but you can check in Filemon or similar tools when and where FSX touches elevation files (within the "infamous" 4.5x radius). We found that, in general, bigger seems to be better because it reduces the number of file touches. On the other hand, complex add-ons like UT-X handle thousands of files and performance remains OK.Not sure what your LOD8 global mesh idea is about. For many areas (North America, Europe, parts of Australia, etc.) it wouldn't even be displayed because default is already at LOD9 or 10. Or are you talking about areas outside the higher-res coverage?Cheers, Holger

[Guest cbuchner1]

I am merely talking about physical dimensions of the tile, not about the resolutions of the elevation data they contain.

[LuisFelizTirado 33]

Hello Christian,I imagine that this is the purpose of the scenery data base that is updated every time we modify the scenery library.As for the time it takes to check the files, I am not a systems expert, but it seems to me that a few thousand file queries a second would be imperceptible to Giga-cycle processors. So, I am only guessing that we would count the number of bgl files, estimate the processor cycles needed to query the header information ( 20? 30? you should definitely have a much more precise idea than I could ever have), multiply the number of cycles by the amount of bgl files that must be queried, then see the ratio compared to processor speed. Again, I have no idea about all of this, but it does not seem to me that a few thousand file queries can have any impact at all on the performance of contemporary processors. So, perhaps we are simply misunderstanding your concern. Would you please be more specific?Best regards.Luis

[Guest cbuchner1]

I will run some experiments on this."Here's a million BGLs. Eat this, sim". And then we check the frame rates and flight loading times ;)

[LuisFelizTirado 33]

If you are really interested, Adam put together a technical explanation of the manner in which the terrain engine works - it is on the FS Insider site. Too short and somewhat superficial, though.From what I have gleaned over time, the answer to your question is "quad tree" although I have no details to give. You can search the beta forum if you want to put the time into it, but that is long and tedious. Nonetheless, questions of this sort have been asked there before and I seem to remember that the developers have never really tested that aspect so responses have been generally vague. Such as "a few big files are better than many small files", they think! (So, why LOD 8? Could you not use bigger quadrants?)The default files must run into the many thousands anyway, although I have never counted them, and the game seems to handle them without any problem. That is something to take into account.In truth, you are breaking new ground here and you may be the only person in the entire world who will test this and get an answer. So, please share whatever you find. We shall all appreciate the information.Best regards.Luis

[Guest cbuchner1]

So, why LOD 8? Could you not use bigger quadrants?The answer: Streaming mesh ;)

[LuisFelizTirado 33]

Do you know, Christian, it does not seem as if you should be testing for that many files. Your users probably do not load the terrain for the entire world, and probably nobody has ever flown over most parts of the Flight Simulator world. At most, we could imagine that your normal users will never get more than a hundred or so LOD 8-size mesh files, and that they do not now get very large areas of photo textures, given the long times to download.So, perhaps you should count on at most, and only in extreme cases, a thousand new mesh files. There is no point in testing for that since this is a trivial amount of files and Flight Simulator should be able to handle querying that extra number without any problem.Best regards.Luis

[Guest cbuchner1]

I cannot modify the scenery library during run time.So the BGLs already have to be there and "registered" in the library with their respective edge coordinates. The file's contents will be blank ("no data") and the files get replaced with actual data on first access before or during flight.I really have to place a lot of dummy files there so that I can add actual content at any land mass on earth. And the tiles have to be relatively small (in terms of miles or kilometers), such that a download of a 3m mesh for this tile remains feasible.If Microsoft provided a dynamic API to modify the scenery library during runtime, I'd be in heaven. Something API functions like "Add BGL", "Remove BGL", "Update BGL" would be *sweet*... Then I could implement a fully dynamic LOD system for meshes.

[LuisFelizTirado 33]

Ouch! Is that what you do with the custom ground as well? If so, how many of those bgl files do you add to the scenery library to cover the world?Just curious.Best regards.Luis

[Guest cbuchner1]

My custom ground has about 2500 BGLs if I am not mistaken. Authored with FS 2004 SDK. Each square covering 257x257 landclass definitions.