• 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.

One Bgl Vs multiple bgls: Which is faster to load?

Messages
558
Country
newzealand
Does anyone have any idea/done any testing about which is more efficient: Covering a large area with one Bgl (Sim only has to load one file....but it is a large one) or multiple smaller bgl (sim has to load many files, but they are smaller files and it doesnt have to load data that isnt in proximity)


Cheers
 
Does anyone have any idea/done any testing about which is more efficient: Covering a large area with one Bgl (Sim only has to load one file....but it is a large one) or multiple smaller bgl (sim has to load many files, but they are smaller files and it doesnt have to load data that isnt in proximity)


Cheers

I can't be sure but it seems that this might relate to the value you have in FSX for how far away scenery loads from your current position - don't have FSX open here and can't recall what that setting is called. FSX will try and load at least that much I think. I suspect this is a very coplex issue that depends on a lot of factors such as the speed you are flying at, the speed of your PC etc etc. Probably not going to be the same for any two installations :)
 
Hi,

I think in general it is best to not have to many files. Each file will have a small overhead on loading, so therefore it is best to put as much in one file as useful.

But on the other hand putting the whole world in one file does not make sense as well, so the things you put together should be loaded/needed around the same time.
 
I can confirm, just ran a battery of tests for 5m elevation data for California and on 35,000 files covering all LOD's from LOD13 to LOD03 you'll want to cram as much area into one BGL as possible...

There is a 2GB or 4GB limit on BGL's though...

It's better to have 1 large BGL compared to many small BGL's because:

A) Load times will be faster
B) Stutters will occur with many small files
C) Frame rates will be better in sim

I had to go back and revise my whole scenery design tools in order to speed things back up again...

In other words, CA took 3 hours+ to load when done as a series of small BGL's... When it's combined into 1x1 degree cells it loads in a matter of a minute or two...

I'm personally working on 1x1 degree regions now as it helps track coverage areas more easily... Also easier for providing support to end users...
 
Thanks heaps for that information...

The data im working with underwent a change in supply format from sets of files per region to 1 file covering the whole country per type (presumably as computers were able to handle displaying and processing larger datasets)

The thing I was worried about was 'blurries'...but I guess FS is pretty good at pulling what it needs out of a single large file based on proximity as opposed to choosing a file based on proximity.

As an aside (and I may answer this question myself this weekend), if you want to add custom autogen to a vector line, do you HAVE to use a pre-existing GUID (from VectorGUID property list) in the attribute table?

I tried compiling my shapefile using a new GUID but couldnt get the linked autogen to show. Im unsure whether the problem lies in my new terrain.cfg entries calling the new GUID, my Autogen model (entirely possible) or just whether the GUIDS are hardcoded.

Im going to try linking it to a Utility line to remove an unknown...
 
I'm afraid I can't help you much on the vector stuff as I've not explored it enough, although I did go through a similar process as you when trying to build firelines but shelved the idea for a future season...

Yeah the blurries are more likely to occur under loading a bunch of files in, I've run some pretty extensive tests when it came to building ProMesh California and I found that the sheer number of files choked the system and led to stutters and more blurring...

The trick is to keep file numbers down and to find the best compromise in terms of compression settings for the lossy data...

For example I've decided to go with FractionBits=2 for elevation data which gives vertical resolution to 25cm compared to FractionBits=3 which gives vertical resolution to 10cm...

Even though the sim can handle fractionbits=3 the file size becomes an issue and you tend to lose detail on the imagery as the highest LOD's then aren't able to be loaded...

The great thing now is that FSX supports being able to render future higher levels of fidelity now, and eventually hardware will catch up, I'm looking forward to the day we have a quad core GPU with 4GB of RAM.....

*drools*
 
There is a 2GB or 4GB limit on BGL's though...

The limit is 2 GB (at least for resample generated photo BGL files). I once loaded a 6 GB photo BGL (which took the whole night to compile), just to find out FS did nothing with it :D.
 
He he I remember you telling me that and I'm sure glad to have learned that from ya :)

The other thing too is that most Linux based web hosts can't serve files larger than 2GB under Apache... Being that BGL is already compressed it's good practice to keep BGL's slightly under 2GB as zipping them up will either reduce the file size slightly and sometimes can increase the file size slightly...
 
Back
Top