15 minutes ago, MattNischan said:

It is indeed! That is why the LOD setting in the sim directly controls how much screen space an object can take up before it switches to a lower detail LOD.

Issues with AI traffic aircraft models incorrectly using the new LOD system and having things like gear culled early (because they don't have sufficiently low detail enough LODs at distance) is something that is included in the things I said Jorg mentioning were being addressed. It's an art issue, not really an engine issue. Appropriately constructed (with the latest limits), you would not need anything like square wheels to keep under the vertex count (1000 vertices from 0% to 1% screen size) and the gear will stay visible long after they would be indistinguishable from the rest of the plane (2-3 pixels).

Technically speaking correct, it should be possible to amend any model to show appropriately.  The issue I fear is that AI traffic packages contain a LOT of independently created source models that may not be possible to update (eg rights issues) or it proves uneconomic to update them all as necessary because there is insufficient ROI for the development time.  Where does that leave us?  Relying on third party developers or worse, freeware creators, to spend time optimising models for little or no return, isn't going to fix the issue, however technically possible it is?

38 minutes ago, MattNischan said:

This has been changed to be 5x smaller (0.1% screen-size).

This would be the variable a user could manage via graphics settings (the option).

38 minutes ago, MattNischan said:

If you want more detail for longer, you can increase that setting

Already at the max value offered and the problem still exists in MSFS 2024 "native" and in non-native/compatible.

 

38 minutes ago, MattNischan said:

usual normal culling happening

There are several implementations of culling (and combinations, occlusion, frustum, back-face, etc.), modern games use mesh shaders (DX12 Ultimate) as they are GPU accelerated for complex geometry culling (render engines like UE5).  Sounds like LOD is the driving solution with MSFS, but my limited understanding of DX12 is that if a lower LOD is not present the object is NOT culled (remains visible) which can impact performance as we know.

I agree, for LOD based system, the assets provider needs to implement the necessary LOD group.  So when an assets are created, does the MSFS SDK (be it 2020 or 2024) not generate the LODs on assets save?  Perhaps I missing something, but in most cases when a detailed asset is created (LOD0 if you like), the process of generating/saving the asset, the LODs are automatically created?  I think it would be daunting for the content/asset provider to manually manage every LOD?  Most game engines/SDKs will automatically generate the LODs ... is this something MSFS SDK does not do?  I guess I'm puzzled at how a content provider could only have a single LOD0 if using MSFS 2020 or 2024 SDK?

Edited November 26, 2025Nov 26 by SayAgain

23 minutes ago, MattNischan said:

It's an art issue, not really an engine issue.

Hmmm ... most graphics engines/SDK will automatically create the LODs.

On 11/25/2025 at 3:32 AM, bobcat999 said:

Please, no SU4 yet.  Still plenty to do, and the feedback snapshots say 'in progress SU4' on lots of stuff. 
It still needs more time in the oven, otherwise we will have to wait until SU5 and we don't know how far off that will be.

I hope at least they can tweak some of the LOD issues, and look at the slow redraw on cockpit instruments before release - this used to be a minor issue in SU3 but is loads worse in SU4 for me.  As they have made it worse with something they have adjusted, there has to be a solution for it - they can reverse whatever is causing it.

The PS5 implementation would be a bear.

dd

1 hour ago, SayAgain said:

Hmmm ... most graphics engines/SDK will automatically create the LODs.

I do not think this is even remotely accurate to claim (although, as always, I'm happy to be proven wrong if you have other examples). The closest thing I can think of that exists at the moment is something like Nanite in UE5, which is extremely new and also has some serious performance and usage constraints still.

Asset creation in modern game engines indeed is almost entirely done with by-hand LOD creation. There are some automated tools to help this baked into various modeling tools like Blender and 3DSMax (and there are a few specialty standalone tools as well), but they can generate very suboptimal topologies even when used very, very carefully (examples of the kind of potentially poor results and recommended techniques here in the SDK docs). As an artist on a game project, you are expected to be able to create assets with all of the required LODs (usually 3-5 of them). This has been the case for decades so is not really a new paradigm at all.

That being said, the flight simulator development community also comes from a lot of different areas; a good deal of hobbyists turned second-job, single developers doing all the work, retirement gig folks, etc. This is not a knock on them at all; they all do simply outstanding work and I am constantly humbled by what gets produced in the flight sim world! But, certainly, the transition to a more modern asset pipeline has caught some folks out understandably, and it does also represent additional workload to build those LODs. Nonetheless, sim users of all hardware levels continue to clamor for more and more performance all while also clamoring for more and more graphical detail, and keeping the old addon style viable where everyone just shipped single LODs makes it impossible to hit those targets as graphics and processing power continue to slow in advances.

LODs like this have been standard since engines in the 90s, and indeed every version of Flight Simulator (and derivatives) since I believe FS95 has had them; it's just the enforcement that is new.

Edited November 26, 2025Nov 26 by MattNischan

Simplygon (extremely popular and used in many AAA titles)

Unity AutoLOD

LODs maker (blender)

Rapid Pipeline

Meshmatic

InstaLOD

and as I mentioned UE5 tools

EDIT: but as I pointed out earlier, there is no way content creator/modelers are going to return to older products and add 3-5 LODs manually … just not going to happen.  

If content providers are manually hand crafting 3-5 LODs for all their objects, the cost to produce would likely exceed the revenue generated unless it’s an extremely popular airport.

iniBuilds Manchester was just released and is claimed to be native MSFS 2024, so I’ll run some tests on it.

Edited November 27, 2025Nov 27 by SayAgain

It might be a lack of competence on my part in explaining, but I feel like there are little bits and pieces of info being repeated here (maybe from bits read on the web) but not really an understanding of the modern game rendering pipeline.

Culling and LOD are orthogonal concepts. They can work together, of course, to reduce performance load, but they're not one and the same. MSFS uses multiple culling techniques to avoid drawing geometry where it is not visible, and also uses (separately) LODs to reduce the overall triangle load of the scene. Mesh Shaders are new, and need recent GPUs above the 2024 lower spec range. Very few UE5 games have this feature enabled. DX12 is not a fixed function pipeline, and so doesn't enforce or provide its own LOD system.

As far as the automatic LOD generation tools go, AutoLOD has yet to exit from experimental in Unity, and UE5 doesn't make LODs at all. Nanite in UE5 is not a LOD generation device, it's a real-time geometry decimation which works best right now for terrain, although it can be enabled on other types of assets. But it also has pretty high I/O throughout requirements as it streams geometry mashlets from disk, and has its own performance issues still.

The other tools fall into the category I described (and aren't part of any game engines), and manual LOD creation is still the primary way by which asset LODs are created today (though with careful use by professionals, these tools can be an assistive boost).

In any case, we may be talking past each other more than we're meeting, so I think I'll bow out here. Hopefully this has all been informational for folks!

Holy cow you guys! You are all boffins! I cant almost understand all the techo stuff you are mentioning! Just tells me how word not allowed i am when it comes to programming and the back-end side of things... i am truly learning an awful lot from all your fellas input Thanks!

2 hours ago, SayAgain said:

iniBuilds Manchester was just released and is claimed to be native MSFS 2024, so I’ll run some tests on it.

i was thinking the same thing. 

5 hours ago, SayAgain said:

but as I pointed out earlier, there is no way content creator/modelers are going to return to older products and add 3-5 LODs manually … just not going to happen.

And they don't need to.

The new LOD rules only apply to packages built with the MSFS 2024 SDK. So until a developer rebuilds their package for 2024, it's going to continue to display as it did in 2020.

If you do want to rebuild for 2024 (maybe to take advantage of 2024-only features) but don't want to go to the trouble of LODding all of your assets, there's a well-known workaround that was discussed on fsdeveloper.com and here shortly after release: Put your un-LODded assets in a modellib built with the 2020 SDK, and use that modellib in a scenery package that you build with the 2024 SDK. This way, you'll be able to use 2024-specific features in the scenery package, but the 2020 LOD rules will still apply to the assets in the modellib. A lot of freeware developers have been going this route (I think I saw @vbazillio talking about this at some point.)

5 hours ago, MattNischan said:

I'll bow out here. Hopefully this has all been informational for folks!

Matt, please don't, it's always educational.  This type of discussion is really interesting and helps to inform the wider community about why things that initially appear simple and frustrate them, are actually in reality really complex and interdependent on many other things.

Could you address this one points Rob queried please?

11 hours ago, SayAgain said:

if a lower LOD is not present the object is NOT culled (remains visible)

My understanding was that if a lower LOD is not present then precisely nothing is displayed?

I'll stop quoting the published SDK regarding LODs, because from what you've said its out of date and inaccurate at the present time! 😄 (In a good way hopefully)  

7 hours ago, kevinfirth said:

My understanding was that if a lower LOD is not present then precisely nothing is displayed?

That’s not the default case … at least in terms of DX12, it would have to be coded to not display … which seems to be the case per the 0.5% to 0.1%.

This really should be a variable users can control via graphics setting … maybe it is via SU4 LOD curve?

This still feels like Deja vous from P3D era.

 

 

This sounds more complicated that I thought. I guess this makes a real headache for 3rd party devs when updates mess around with LOD related "stuff." 

It would be nice to have less popin/out. Though I hardly notice it as much lately. 

1 hour ago, Sonosusto said:

This sounds more complicated that I thought. I guess this makes a real headache for 3rd party devs when updates mess around with LOD related "stuff." 

It would be nice to have less popin/out. Though I hardly notice it as much lately. 

A lot if it has been addressed.  But there's still some pieces of default 2024 planes that are removed even with a modest zoom level.  And a door on my C700 N55BS paint turns white in and out of certain zooms (lods)

On 11/26/2025 at 8:21 PM, MattNischan said:

Ultimately it is up to addon developers to create LODs that are appropriate to the object screen size and that fit within the (generous IMO as of SU4) rules that govern which LOD is displayed. If addon developers choose to remove objects completely at certain LODs or not provide lower detail LODs at all, that would be up to the individual developer to address.

Not saying this in any sort of argumentative way, but I am very aware of this happening with just general default MSFS 2024 landscape, not just with the whole airport signs/static planes wheels etc environment and/or particular addons. I run 4k, LOD 300 or 400, PG on, mostly ultra settings off a 3090ti, and things were just fine in terms of "popping" in 2020 originally, but have always been horrible in 2024. I don't fly tubes, and tend to be low n'slow so probably notice it more than some, but I do see trees, suburbs, general buildings and features popping in and out of existence constantly in most "visually busy" areas, for example around EGGD and from KSAN up to KLAX to name just my most recent couple of trips.

I appreciate your explanations, and understand (and applaud) the thinking behind all this, but the bottom line for me is that this is simply not working as designed if it is happening with the default scenery. I realise there's nothing I can do about it, and moaning about it on here is not likely to have any effect, but it also seems that reporting it via the MS site is not terribly fruitful either.

For me, this is another example of what was probably a great idea at the conceptual planning stage that is being dragged down by poor implementation. I'm not in the beta, so I await the official release of SU4 with interest, and it may well be that 2024 will eventually have all the things that irritate me fixed, but for now it feels a bit like a broken promise.