MattNischan

That assumes the party who owns the data was willing to entertain such a thing. The sim's current LIDO navdata equals and in some cases exceeds the quality of the Jeppesen navdata (remembering that taxiway information is not a part of navdata). For the majority of reports since switching to LIDO we have found folks were comparing to Jeppesen, but it was the Jeppesen data that was out of date. Not every single report, of course, but I'm sure both companies are happy for the extra eyes on the data.

Certainly not. That data is owned by Jeppesen and using it to improve a commercial product is absolutely something that requires a (vary large and very expensive) licensing agreement.

There is no global dataset for airport layouts that includes taxiways. No taxiway data is included in the ARINC spec at all. Some companies offer AMDB data (airport mapping database), but there are none that are totally worldwide (and also are hugely expensive), and the airport coverage isn't spectacular (especially for strips like this). So, the data is a combination of AI looking at aerials and OpenStreetMap data. But you can't run that process all the time, as the results have a lot of their own inaccuracies that need a boatload of human intervention still. Areas tend to get special attention and focus with World Updates. No magic bullets here, unfortunately.

It is a volumetric beam. You can test this by making a flat precip layer, and then slewing up and down towards and away from the layer. You can see the returns move towards and away from your aircraft as a result of the beam intersection. As far as the answers to the other questions, I'm afraid it's not really my place to field them. DevSupport would be the appropriate venue for those kinds of questions. -Matt

It is already modeling a 3D beam (not a slice), and has always. It is not doing that, no.

That post is in error. Asobo did the work on this. We (WT) merely added the JS API. Credit should go to them. Additionally, the weather radar was always 3D, going back to 2020 launch. Just some nonsense rumour and misunderstanding that became internet lore that for some reason will simply not die.

The equivalent process in MSFS 2024 is relatively similar in complexity: - Go to the EFB Planner app, Route page - Enter Origin and Destination, then (optionally) press Auto-Route button if you want something not direct - Go to Flight Detail page, and select VFR or IFR - Optional (back on the Route Page): Go to the SEND menu, and hit Send To Avionics and Send To ATC as desired The Auto-Route button in 2024 is exactly the same code that is engaged in 2020 when it creates a route for you on the world map.

This change is part of the other LOD curve changes implemented in SU4 for 2024 native models. These changes apply to all 2024 native models and there isn't any other option to modulate this other than increasing the already existing LOD settings. For stock MSFS AI aircraft, a number of them have also been fixed to follow LOD rules correctly in SU4. My understanding from the dev Q&As is that this work was to be done by new art contractors over the course of SU4 and SU5. For 2020 native models in 2024, they still obey 2020 LOD laws. This is situation purportedly applies to the AIG models. So there is investigation still to be done there to determine if the models or the engine is at fault for the gear on those aircraft in 2024.

If these aircraft have been built in 2020 and are 2020 native aircraft packages, then they should be using 2020 LOD rules. If you are finding that they are not, and you have a solid repro for that, please report it on the DevSupport forum, as that is not the intended behavior and is an important backwards compatibility issue that the team would be very interested in. If, however, you are building these packages in 2024 (despite being non-modular 2020 style), then they will obey 2024 LOD rules, and you may need to separate the gear to model attachments and optimize them for the new rules. If properly done, then they will not disappear. As for folks using the stock AI models, as mentioned by Jorg in a Dev Q&A, those models are being worked on to eliminate breakages of the LOD rules in those models that are causing issues, and the LOD rules themselves have recently been changed to be less stringent, especially at long distances. As mentioned in the same comments by Jorg, there was some contracted art he is not happy with, and it has taken some time to find alternative art teams and resources to assign to these art bugs. However, they are actively being worked on, with updates most especially for default aircraft non-AI models coming in SU4.

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!

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.

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

I'm not totally sure where within what I said would it be implied that there's none of the usual normal culling happening which happens in all modern engines. I can't say I follow what additional option would be needed; the LOD option that is already in the sim multiplies the screen size before which objects move to the next less detailed LOD. If you want more detail for longer, you can increase that setting. What other option could possibly exist? This has been changed to be 5x smaller (0.1% screen-size).

The amount of screen space required before objects switch to less detailed LODs is affected by the graphics settings. The higher the graphics settings, the longer higher detailed LODs will remain on screen before switching to less detailed LODs. 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.

As has been explained in one or more dev Q&As, this is not so. Changing the LOD rules for 2024 3D assets was an intentional design choice in order to keep performance levels high across all scales of hardware, low and high. Unfortunately, throughout the lifetime of MSFS 2020, it was seen time and time again that many developers would not use the LOD system at all, creating one super complex LOD0 that would display no matter the distance. So if a plane was 10 pixels high way off in the distance, you're still having individual pipes and tubes in something like the landing gear drawn, and that eats performance quickly, especially when those models can also be selected by the model matching system for AI traffic, leaving little room for other things that need that performance budget, like clouds. For models that are in 2020 backwards-compatible mode (i.e. MSFS 2020 packages/addons running in 2024), the 2020 LOD rules still apply, thus causing no backwards compatibility issue. But for models in native 2024 packages, then the new LOD rules apply; this puts pressure on developers to properly optimize their models so single addons aren't monopolizing valuable hardware resources and performance can be consistent across varying sets of addon installs. And, the Asobo team has taken developer feedback about this system to heart, making adjustments to strike a reasonable balance at every SU (and especially SU4 with the new LOD selection curve). As Jorg as said, issues with Microsoft/first-party assets relating to LOD are being worked on actively (it was a matter of finding new art teams and resources to work on this effort, to ensure good results), with a large number of them landing in SU4 (especially regarding aircraft).