Bounding Sphere Issue / LODs / Screen Size

With the proposed change to a linear curve, 1% would become 2500 vs 300 today. Isn’t it quite a jump (above x8)? Think about lots of vehicles such as that you used as an example yesterday, in a busy airport - isn’t there a risk that, if the vehicle developers decide to stick to the limit, performance will be affected?

I think you also mentioned VRAM in your previous posts, mainly focusing on textures - but those meshes would sit in VRAM too so the minimum VRAM consumption might increase significantly which such a change.

I am not saying the idea is totally wrong, but what about the impact on the overall performance?

Best regards,

Eric / Asobo

I think this discussion is great. The final result is going to take some testing. Maybe an Alpha for devs to test several different methods?

The main point is the current method is too aggressive. We can’t have Instruments switching LOD when you move your head back a few inches for example. And as Py noted, you don’t want to see a minecraft car when it’s only 200 ft away. And I don’t want the plane wheels to disappear when a plane is only 3 parking spots away from me.

I think setting rules to keep the offenders under control is probably the wrong way. The marketplace will do that, offending products should weed themselves out as people note they lose performance. As @SimbolFSReborn noted, the good devs want their customers to have a good experience.

1 Like

The change does seem significant, but only because we’re referencing a very small number. 2500 verts is not that many, especially if you consider geometry is easier for the hardware to handle than textures. There are airports with millions of abundant vertices yet seem to work fine-ish. Also many vehicles, like the one in my example, can be instanced to further reduce the load.

Yes, ofcourse there is. But isn’t that the developers’ fault then if they receive complaints that THEIR product performs poorly and up to THEM to improve it and make LODs more drastic if need be?

We are now back to my original example of what a big, medium, or small airport is and that developers themselves need to think about this topic more critically. Let’s say I make a very small airfield, which suffers from obvious LOD popping just because some big sceneries COULD perform poorly because devs don’t do LODs properly. Why should devs, and subsequently the quality of their product, be punished just because other products don’t have proper optimisation?

Just because the system is less strict doesn’t mean that devs themselves cannot do proper optimisation anymore.

Your point is only valid if one single add-on is responsible for the poor performance the user is seeing - just think about a correctly optimized airport, with some external add-on spawning dozens of correctly optimized aircraft. Performance will crawl - who do you think the user will turn to?

We (Asobo) must have some control over this to prevent “emergency situations” where some resources start being exhausted on the platform we run on (this part of the sim is actually being reworked to be more efficient). We also have to provide guidelines and mechanisms to avoid these situations in the first place. :slight_smile:

Best regards,

Eric / Asobo

1 Like

If there are multiple instances of one single object, yes. But if you load an heavy airport right now and look at the number of objects drawn in the distance (hence capped at 300 vertices), and multiply the number of vertices by 8, is it still “not that many”?

Best regards,

Eric / Asobo

Everyone is following the same rules so I don’t think anyone is punished over someone else. Are you saying that someone building a castle in the desert should be allowed to use more vertices/faces than someone building a complex airport?

This brings me to my previous question which none of you (but one!) answered yet: what would be “fair” limits according to you? Would the proposed curve (well, straight line) from @pyreegue do the trick? Or do you just want to have no limit and hope for the best when add-ons reach your customers?

Best regards,

Eric / Asobo

Hi Eric,

I only meant that setting “extreme” measures based on the results of a few offending developers is the wrong path.

Right now it seems nobody can develop with the detail they want, even if they follow the best practices precisely, this consequence happening because Asobo is trying to allow people to use their Xboxes even though they have purchased an addon that was developed very poorly.

I’d rather see values set with the assumption that developers are using the best practices as best as possible, assume complexity high, but development good, rather than assume complexity high and development very bad as the deciding factor.

That way, when somebody uses bad practices, it will become immediately apparent, and users will turn those packages off.

In fact, to that end, some sort of method (that doesn’t pop a window up on the screen!!!) for notifying a package is using excessive resources would be awesome. I’m imagining a development or options screen that lists in order the resources a package will use, so users can optimize their systems and decide which packages to use and not use. (I realize that’s not an easy task, but, it’s an idea).

I hope that makes sense. Don’t punish good developers so users can use bad packages. It sends the wrong message, and developers start using bad practices, like we’ve seen of even 1st party developers.

Oh, and I have definitely found instances of very bad products I turn off (or attempt to fix). And, I hate using specific examples because like statistics, anecdotes can be used to prove anything; But I would say, if that product showing dozens of planes is killing performance, it’s a poorly designed product, and needs options to reduce complexity so it can play well with other products. To me, the airport detail comes first, and “Living World” has a lower priority. But I realize that’s me.

Yes? That is exactly what I am saying?! Becuause one single building with let’s say 2 million or even more verts would not cause a performance issue whatsoever. I have exported a test object with 5 million verts and it had almost no performance impact at all…

I don’t get what you don’t understand here to be honest. Like please don’t take this the wrong way. I am just questioning if you don’t understand it or if I lack the ability to explain it properly…

Let me try it again:

Imagine a very simple GA scenery. 2 or 3 hangars and a few GSE carts. Nothing around it, maybe in the middle of a forest. You could model those with 2 million verts or more (just as an example) and use 10 4k texture sheets on it, and it would still not have a worrisome performance impact at all. Probably not even on lower end systems. Because it has no or a very small performance impact, why would I not be allowed to do it if I want to and if the sim and hardware would be able to run it? exactly, Because of the LOD limits.

Now let’s say I want to do a bigger airport. I, as the developer, MUST take this into consideration and design the scenery accordingly. I have to obv cut-back on the modelling, and take a close look at how I utilise textures in order to keep performance to a desireable level.

Please do not say you are not punishing anyone, because this example clearly shows that small sceneries cannot be done with more detail than the LOD limits allow, even though the sim would be able to handle it without major issues.

1 Like

No worries, you explained properly. :wink:

I wonder if the misunderstanding comes from the fact that all of you are presenting situations where you only consider your own add-on - in my view, your castle in the desert (or your airport/airfield for a more realistic situation) could be populated (by someone else’s add-on) with new objects or SimObjects. If you already exhausted (or largely used) available resources for objects spawned by your add-on, what’s left for these people? Should I consider that you are punishing them? :stuck_out_tongue:

Of course if you’re 100% sure your add-on will always be the only one in this tiny part of the world, you could have more budget. Now, how do we ensure this? And we still need limits for lower-end platforms - are you 100% sure the 2 millions verts model with 10 4K textures will work as intended everywhere?

Best regards,

Eric / Asobo

@EPellissier Can you present us with a model of a moderately complex building (Hotel, Ops Office, Hangar) built and textured according to the published LOD Limits and demonstrate its behavior in FS24’? I’d love to see a properly made object and learn from it because now I believe my knowledge is considerably lacking.

1 Like

I have to agree with everything Raul has said so far. I understand the goals behind the new LOD limits, but they’re just too restrictive in vertex count and far too aggressive on switch points currently. I’d like to offer my own small example of this.

I decided to try fitting an ADF gauge to my plane, and since there’s a provided sim attachment object for it in the VFS (thank you very much for those!), I figured I’d use that one to save time.

But when I drop it in, this is what I get…

The instrument is maybe 3 feet away from the camera, in the full LOD0 cockpit, but it has already dropped to LOD 2 of 3 and looks very poor and out of place in the panel. It should be showing its LOD0 at this distance / zoom, then switching to LOD1 if I move 6 feet back into the cabin, and finally using LODs 2 and 3 when the camera is outside the plane. Unless I’ve missed something there doesn’t seem to be a way to adjust the LOD switching points for provided sim attachments, so it is effectively unusable at the moment.

I’ll need to make my own gauge, which is fine, but I hope this helps illustrate the issues being raised.

Thanks!

2 Likes

There’s been a lot of valid discussion here, and I want to add a perspective specifically from the aircraft development side—because I think that’s where the current LOD system in MSFS 2024 is hitting the hardest.

At Got Friends, we’ve shipped multiple aircraft for both MSFS 2020 and 2024. We’ve always aimed for high visual fidelity, but we also recognize the importance of performance—especially with Xbox compatibility now in play. That said, the LOD system in MSFS 2024 has become so aggressive that it’s actively working against the quality and immersion our users expect from aircraft.

Here’s the reality: most MSFS 2020 aircraft—ours included—were built around two models: one exterior and one interior. These models were tightly optimized and structured to blend seamlessly for in-cockpit and external views. Now, with 2024’s strict reliance on the bounding sphere and projected vertical screen size, we’re being told that unless we modularize those aircraft into 30+ separate attachments, our highest-detail models will disappear prematurely or never render at all in certain views.

That might make sense for massive scenery objects where performance gains are critical—but for aircraft, especially detailed GA or bush planes, the opposite happens. The camera is often inside the object. Screen size logic falls apart, and we end up seeing LOD2s at point-blank range while flying in VR or using track IR. The results are jarring, especially in cockpits where users are scrutinizing every switch and surface.

We’ve tried following the current guidelines. We’ve tried carefully building out proper LOD chains. But we still run into problems where the bounding sphere isn’t behaving as expected, and our aircraft visually degrade even when they fill the user’s screen.

Like others here, we’ve resorted to inflating the bounding sphere using invisible cubes—not because we want to cheat the system, but because that’s the only way we can stop LOD 0 from vanishing while sitting in the cockpit. We don’t want to rely on hacks, but tearing apart our existing aircraft just to appease the LOD system isn’t sustainable—especially when many of us are still supporting MSFS 2020 in parallel.

The official suggestion to “break aircraft into smaller parts” might work for large studio teams starting from scratch. But for most 3rd-party devs converting existing aircraft or trying to maintain quality across two versions of the sim, that approach isn’t realistic. It dramatically increases development time, complexity, draw calls, and testing effort—for questionable gains in performance.

To be clear: we support the direction Asobo is heading. We understand the importance of optimization. But aircraft are fundamentally different than scenery. We’re dealing with small, dense, high-detail objects that are meant to be viewed up close, from the inside. A system that forces us to downscale those visuals at close range—just because the bounding sphere doesn’t hit a threshold—feels counterintuitive.

What we’re asking for isn’t the removal of the system—but practical, aircraft-aware improvements that recognize how different their needs are from static scenery:

  1. Aircraft need LOD logic that prioritizes proximity realism, not bounding box math. The current system breaks down when the player is inside the cockpit or near the aircraft—scenarios where screen size becomes meaningless but detail matters most. LODs should respect camera proximity and view mode (especially in first-person and VR), not just bounding sphere projection.
  2. The two-model workflow (exterior + interior) must be treated as a valid, optimized structure—not a legacy shortcut. This has been the industry standard for years, offering clean separation of interior and exterior without overcomplicating the model hierarchy. Forcing aircraft into dozens of disconnected parts just to pass LOD thresholds is inefficient, error-prone, and unnecessary for performance when done responsibly.
  3. Aircraft are the centerpiece experience of the simulator and should be treated as such. Scenery is viewed in passing; aircraft are where players spend the majority of their time. They demand higher visual fidelity, longer LOD retention, and systems that support close-up inspection. A one-size-fits-all LOD rule designed for buildings simply doesn’t work for highly interactive, player-centric aircraft.

We’re not asking for shortcuts—we’re asking for tools that respect the realities of aircraft development. Without them, quality suffers, workflows break down, and the very experience players come to the simulator for is diminished. Until then, we unfortunately have no choice but to continue optimizing our LOD limits and balancing quality through bounding size hacks—because it’s the only way to preserve the visual fidelity our aircraft deserve.

7 Likes

I 110% support Jonx’s complete description here, but, as a pilot, my total experience is important, aircraft and my locality (scenery). When I land at an airport, I want it to look like an airport. After 40 years, I finally get the ability, in the base sim, to do my walk around. I enjoy exploring my world. So I’d like to change this a bit… “we’re asking for tools that respect the realities of user experience”. I want to see what I see.

I know products like FSTL are killing you, but there has to be a better way.

And, yeah, when it comes down to it… the cockpit experience trumps all. I know those glass gauges are killing you, too, but, the other gauges need to stay at LOD0.

1 Like

Both sides of the barricade suffer from imposed limits. Everything worked fine in FS20’, even ridiculously unoptimized stuff. 24’ is a lot heavier, even in its default state, somehow, and 3rd party developers are now the ones that have to carry the burden. Limits are not acceptable for either scenery nor aircraft, this is perfectly demonstrated by Asobos assets that abuse the system with Cubes, some objects seem to even be excluded from the LODLimit system, like Taxiway Signs. Those objects that comply with these limits are ridiculous to look at. Buses driving around the airport turn into rectangles at close ranges. No need to prioritize one over the other as more important, it’s all a combined effort after all.

1 Like

Okay so first of all no, Eric, not at all. In fact, I have not mentioned one of our projects once in this thread. We have neither done a castle in the dessert, nor a small GA airport, nor a megahub. All of those examples were purely for demonstration purposes to bring the point across.

And the point still is that the LOD limits, as the name suggests, limits and restricts devs, and also the sim too, in certain scenarios. Like the Castle example that could be done in more detail because the sim is able to handle it but the LOD limits won’t let it happen.

Please, for the love of god, stop twisting the narrative all the time. What other addon could possibly spawn around a castle in the desert… Do you really think someone is doing another addon to add high poly dogs to your castle? Please, this is getting ridiculous… You are the one that always wants factual statements and proof. So let’s stay within a realistic scenario here and don’t think about the fact that someone could possibly make an addon that impacts a castle in the desert…

However, having said that, I of course know what you mean regarding other addons also taking resources (aircraft, GSX, etc), but when you are doing a scenery you OBVIOUSLY already take those into account as a developer… If not then you have a different problem to begin with… You know, the customers of high-quality sceneries, or ppl who are willing to pay extra for a scenery for that matter in general, are probably also the ones who have high-fidelity aircraft and other addons like GSX. So for this reason, whenever we make a scenery for example, it is ALWAYS tested with every other possible performance impacting addon enabled, and the scenery is tweaked to perform with those…

And then again, those would not make a difference either if we go by the aforementioned small GA airport example because GSX is most likely not needed there and you wouldn’t fly a poor-performing airliner into there… And even if you did, devs have to consider this and test it! And if it doesn’t work adapt accordingly…

No, How can I? We cannot even test our airports on XBOX so how would we be able to? (this is worth a whole different discussion btw…) This is what TESTING is for (something Microsoft hasn’t really heard of judging by recent releases… (sorry for the dig but I am really starting to lose it here having to explain OUR point 500 times))

This why you have testers on different hardware configs etc. to ensure it would run well. And if it doesn’t guess what you do? Correct, you fix it by maybe adding more LODs, reducing texture size, reducing overall vert count etc…

But what is a FACT is that this system is limiting developers and the sim itself to deliver what it is actually capable of in some scenarios.

I have told you before that I am 100% for some sort of limits to force lazy devs to actually optimise their scenery. But I think we have enough proof by now and enough ppl have told you that they are simply too strict full stop. And if this means that we have to loosen them overall then so be it. Then it is up to the devs to ensure good performance and if it doesn’t perform well then guess what, it will get bad reviews and they will make less money. So joke’s on them.

2 Likes

I completely agree with your sentiments—scenery is absolutely a critical part of the overall experience, and I didn’t mean to downplay its importance. My comments were purely from the perspective of aircraft development, which is where our team specializes. I’ll admit I don’t fully understand all the nuances and technical challenges on the scenery side, so I try not to speak beyond our lane.

For us at Got Friends, we’ve focused entirely on aircraft because that’s where we’ve seen the highest community demand and long-term viability for payware development. We have huge respect for those working on scenery, especially considering how much it contributes to world-building and immersion—but our experience and concerns are rooted in what affects cockpit-first, high-fidelity aircraft.

That said, I think the core point still holds: aircraft and scenery have very different development realities, and the current LOD system doesn’t fully accommodate eithers distinctions yet. There needs to be separate systems in place.

2 Likes

@Jonx Different realities yet very similar core issue - unrealistic LOD limits. ScreenSize is also calculated differently than it was in FS20’, you can see my original post where I demonstrate this with a quick walk inside the terminal, I’m INSIDE the thing and am looking at LOD02, similar to your cockpit issue.

Apologies, maybe it sounded differently to what I wanted to say: when I wrote “your own add-on” I meant “as if the add-on you are considering was the only one affecting the scenery”. :wink:

Might be why I added: “(or your airport/airfield for a more realistic situation)”

I am surprised by this - there should be a way to test your packages on Xbox, unless it hasn’t been opened to everyone yet (sorry, this is outside my scope).

And I thought we were discussing ways to improve this.
So do we:

  • Use the linear relationship suggested earlier?
  • Remove all constraints?
  • Do something else?

Best regards,

Eric / Asobo

1 Like

text is a horrible communication method…