Are multiple objects separated by many miles in one package more taxing than each in a separate package?

[PhysicsTeacher]

I built 8 lighthouses spread over 250 miles, and some downloaders complained that their Community Folders were too crowded; could I please put them all in one package. I did it both ways, and then published them allowing choice. No one commented further.
I included a warning that one package spread over hundreds of miles would require that the simulator load them all even if only one was "visible" at a time. I recall one download from an unnamed contributor that had many objects spread over a large area brought complaints from users that they lost a lot of framerate. Also, no one else who made one of the same models - not all - could exclude any of the all-in-one.
I maintain that it doesn't matter how many items you have in your Community Folder, the only ones that will be loaded and use up processing power are those that are nearby and need to be seen.
Anybody have any ideas?
I have not been able to find any lore on this subject. If you have a link I missed, please let me know.
Thanks.

 

[rhumbaflappy]

You should probably ask Asobo. https://devsupport.flightsimulator.com/index.html

 

[=rk=]

I think it's possible that the glossy MSFS graphics can "overstimulate" some of us and the virtual miles somehow become realer. Indeed, flight simming itself spans continents, which are not separated by hundreds of miles, but a few lines of code. It raises the question, "well, if there was any sort of simulated distance inspired resource drain, how would Asobo not be affected, but only addon sceneries are?" Also and rhetorically, did you find out how your discriminating downloaders are able to tell that a scenery that is clearly resource intensive to some, is not itself "simply" overly complex, prone to conflicts, or otherwise inhibited - except by the numerical drain of simulated distance?

I built 8 lighthouses spread over 250 miles, and some downloaders complained that their Community Folders were too crowded; could I please put them all in one package.

Community folder crowding should only be about organization, not resources. The cryptic little lower case, unspaced FORTRAN like scenery titles don't help visually, but folder structure, like simulated distance, has no effect on runtime, in my experience.

I included a warning that one package spread over hundreds of miles would require that the simulator load them all even if only one was "visible" at a time.

Your reason to suggest potential issues seems unclear. Do you expect your models to drain resources? Why would the fact that the scenery is "active," be more of a drain? I am thinking of maybe, I don't know, New York City, at night and comparing it to, how many lighthouses? Thousands? Or maybe a few dozen? Also, I suggest that instead of giving them ideas, you nurture people's creativity and wait to see what they come up with.

Also, no one else who made one of the same models - not all - could exclude any of the all-in-one.

This one is a little confusing. Are you saying that people wanted to use your scenery, but they wanted to use other scenery that needed your scenery to be inactive, simultaneously? I'm not practiced on editing other people's scenery, but I believe the correct procedure is to create a scenery project that specifically "amends" yours. By my understanding, it is not adequate to simply exclude addon scenery package elements, one must edit what is active, just like replacing a default airport. The user would have to start a new project, based off and as an edit of your scenery, remove whatever elements, build that scenery, put it in Community folder, then it will work.

 

[rhumbaflappy]

Hi PhysicsTeacher. I think you have a legitimate concern, But Asobo may give you a definitive answer, rather than a bunch of guesses.

That being said... In FSX it definitely was the case. But MSFS is a different animal.

 

[PhysicsTeacher]

Thanks for understanding what I was asking. I'm reading avidly in the link you sent. I need to phrase my question carefully so it is not misunderstood. Your comment on FSX lends credibility.
All my models have minimum 3 LODs and are tested carefully before I let them go. If Asobo can't answer my question, I'll make up two huge models, ones I know will show up on framerate, and place them a hundred miles away or more. That way I'll be able to get a better handle.
If I had to make a guess, loading one package loads all the textures at once but mipmaps them as needed for the objects bounding sphere. Thinking logically again, maybe I should also check memory usage between the two test cases.
More later. I've got to finish poring over that link you sent.
PT

 

[rhumbaflappy]

FlyingRacoon and Boris_ are the 2 main Asobo responders. There are also many knowlegeable members there from the 3rd party devleopers.

 

[=rk=]

If Asobo can't answer my question, I'll make up two huge models, ones I know will show up on framerate, and place them a hundred miles away or more.

If you didn't want to take my word for it, you could save yourself the time and just explore my scenery at Flightsim.to. It consists of multiple islands separated by hundreds of miles, with AI ships, planes and animations. I know for a fact that one of my ships travels over 600 miles and there is no performance drain whatsoever.

Zhubi Reef Naval Air Station for Microsoft Flight Simulator | MSFS

✓ Zhubi Reef Naval Air Station is a Microsoft Flight Simulator 2020 mod created by Rick Keller. Subi Reef Island scenery in the South China Sea does not exist in the default version of MSFS. During 2014, the PRC started reclaiming land at Subi Reef, and by...

flightsim.to

 

[dale in cda]

I don't know the answer for the OP, but here's the chain of reasoning that makes me say "Trivially minute difference."

Keeping in mind that it is not possible to add a package to the sim after starting. We also know that the sim has some degree of memory management, not keeping all loaded objects in the vram at all times but instead loads it when it comes into some calculated "appropriate" distance (based on size of object, visual distance, memory management method, etc.).
Since the objects are not kept in memory, this implies that they are read from the file when needed.
Thus, the sim must keep internal lists of all objects, their sizes and information about when to load them, and the system file in which they are stored.

I am willing to infer that Asobo has used decently efficient lookup code to identify which objects need to be loaded next. If I were coding it, I would have the system (bgl) files in a look-up table indexed by an integer -- then all objects in the same bgl have that file's ID integer in their data record for lookup, keeping the long text file stored in a single memory location.

If this is more or less what is going on, then it more comes down to the number of bgl files:
1) Using separate bgl files for each object will have a slight sim memory increase to keep handles to the separate files -- but no performance impact.
2) If all objects are in the same BGL file, then there might be a slight performance impact due to needing to read through the file to get to a given object (but this can also be eliminated in the file-reading code) -- possible but not certain slight performance impact.

And, of course, the number of packages also have a small effect on disk storage due to the number of folder and file linkages.

 

[=rk=]

I don't know the answer for the OP,

Well your observation does raise a valid point. We know the project covers a large distance and we know that users have claimed the project causes issues. Here, 3 developers have lent their skills to the problem. Could we promise all would test it? No, but I am pretty sure I'd at least have a look inside and report any anomalies. Without an actual sample of the software at issue, it pretty much is anyone's guess.

My guess is that generous application of draw calls, or similar render bottlenecks, is giving some systems indigestion and I'd know pretty quick from looking under the hood, so to speak.

 

[PhysicsTeacher]

I thank you all for your informed responses. I did not explain myself very well in this forum, but I was more specific in my question to devsupport. I assumed they knew what they were doing with memory/speed management, but I wanted more specifics.
I just got this response from Boris_ at Asobo:

Many objects in one package or many objects in many packages? - MSFS DevSupport

Enterprise solution for all your Social Q&A needs.

devsupport.flightsimulator.com

I therefore now believe that the main problem I've seen with airport and some other massive addons is the total lack of LODs in many instances. Use the LOD debugging facility in Options to see what I mean.
Thanks again.

 

[Anthony31]

Just have a look at the one of the region sceneries. Such as the USA one.

Official\OneStore\microsoft-usa-point-of-interest\scenery\microsoft\ms-poi

It contains a model library (300MB thank you very much with an associated texture folder of 2.77GB) and a placement file (objects.bgl at 1,221kb) which places all those models all over the USA.

 

[GaryGB]

Indeed the Package format may help in grouping collections of objects and various scenery components together for 'convenience'.

I have the impression there may also be some effort by Asobo to create a 'hash' for package file / folder name paths to be used for assignment of loading priority (and perhaps tracking of user / developer statistics, DRM etc.).

While this may be a parameter used by Asobo in determining load order within the MSFS-VFS, AFAIK, the underlying mechanism utilized for determining run time loading / display of objects surrounding a user A/C camera by FS2Kx may still apply ...as summarized in this post:

MSFS RTM default was coded so that certain scenery objects were only able to be displayed within the test radius of an Airport Reference Point (aka "ARP").

Dick has previously tested expanding the ARP Test Radius from its FS2Kx default of 5 Kilometers to 50 Kilometers for MSFS to enable object display when placing scenery content at greater distances from a 'relatively' nearby airport.

https://www.fsdeveloper.com/forum/threads/ade-and-poi-project.452822/


In theory, one can increase the ARP Test Radius to allow placement / display of objects at greater distances from a particular MSFS BGL containing airport code.

BTW: There was FS Community opposition to the MSFS RTM restriction of certain scenery content to being allowed display "only within the context of airport XML code".

Subsequently, certain scenery content was allowed display independent of the context of airport XML code..

AFAIK, the original 'intent' of ARP-linked display control as authored by ACES may have only pertained to FS2Kx objects placed by BGLs containing "airport" code, or more specifically objects from the default FS airport objects scenery library files.

But, IIUC, ultimately object display is controlled by Geographic extents coded in the headers of BGLs, and local 3D world Quad / Octet context-related LOD / MIPMAP switching as a function of run time Z-sorting object distance and calculated extent of local object vertex geometry (whether visibly textured or not) from the user A/C camera within the domain of its "Aircraft Z-Test Radius" (which is diamond-shaped when visualized in top-down view).

That "Aircraft Z-Test Radius" is further linked to the "Visual Display Radius" which controls display of scenery content in concentric rings of Quad / Octet related LOD / MIPMAP switching in the area surrounding the user A/C camera position of the FS 3D world at run time.

Thus, I am inclined to believe there is now a way in MSFS to place certain objects independent of the context of airport XML code which would not be subject to limitation by ARP Test Radius.

Perhaps Dick might be willing to post (or link to) an example of scenery objects placed using code that is not subject to the display restrictions imposed by an Airport Test Radius ?

GaryGB

IIUC, there may be a potential benefit to grouping objects by LOD-13 / QMID-15 quad BGLs to control "loading granularity".

So, rather than placing objects for a country all from (1) BGL, content placement may be pre-sorted / compiled by Quad size /Area.

[EDITED]

This may allow the rendering engine to function more efficiently by reducing internal VFS "file I/O" and use of RAM / VRAM for Geometry / Textures / Shaders ...by only loading (content from) BGLs Geographically local to (a) user A/C camera position within the MSFS 3D world.

[END_EDIT]

Note as well that for pre-sorting / "granularity" of scenery BGL content in MSFS \Scenery "Areas", the underlying mechanism utilized for determining loading of objects surrounding the user A/C camera by FS2Kx may also still apply at a LOD-5 / QMID-7 level.

See:

[MSFS-2020_Packages install path]\Official\OneStore\fs-base-genericairports\scenery\[xxxx Area #]\ APX*, CVX*, OBX* .bgls


IIUC, Asobos MSFS SDK default package XML templates create a symbolic link to these subfolders within the "Virtual File System":

[MSFS-2020_Packages install path]\Official\OneStore\

...via these path prefixes typically output with BGLs, that redirect their target output / load order to:

[MSFS-2020_Packages install path]\Community\[add-on package name]\scenery\global\scenery\[add-on filename].BGL

...and/or:

[MSFS-2020_Packages install path]\Community\[add-on package name]\scenery\world\scenery\[add-on filename].BGL

If in fact the same legacy FS2Kx mechanism for local run time load / display still applies in the underlying MSFS architecture, pre-sorting via Quad size / Area may confer a significant benefit by reducing rendering burden; thus improved performance may result at run time.

GaryGB

 

[=rk=]

This may allow the rendering engine to function more efficiently by reducing internal VFS "file I/O" and use of RAM / VRAM for Geometry / Textures / Shaders ...by only loading BGLs that are Geographically local to the user A/C camera position within the MSFS 3D world.

Just a quick FYI here, the "render engine" does not load .bgl's, in fact, it does not even load any other LOD, then the one that will be rendered. This isn't to say there may not be a .bgl or LOD bottleneck further up the pipeline, it is just that the render engine only calculates colors, intensities and angles, from information supplied by the rest of the system, that reads and deciphers the .bgls. For understanding, the render engine works like a pair of eyeglasses, or like a television set.

Also, bear in mind we are discussing solutions to a "distance loading limitation," that itself was misdiagnosed and instead caused by an absence of LOD models, for which adding a few LOD's is the recommended solution.