Minimum MSFS LOD values

In MSFS 2024 the level of detail (LOD) system has been changed. As specified in the SDK, based on the number of vertices in the level of detail representation there is a minimum minimum size value that is allowed in MSFS 2024. This means that objects with a certain amount of vertices will disappear at a certain distance and if there is no level of detail representation below it.

In ModelConverterX I have now implemented a number of changes that will help you to work with this new system more efficiently. It should be noted that ModelConverterX does show the FSX/P3D LOD values in the different forms and not the minimum size value that MSFS uses. On export to MSFS formats this is automatically converted.

  1. The glTF writer has an option now called “Limit MinSize based on vertex count”, when enabled (which is the default value) this logic will modify the LOD value of the object to match with the table of the SDK based on the number of vertices in the object.
  2. In the LOD Creator form you can now see what the minimum LOD size is that MSFS 2024 supports based on the complexity of the object. So that helps you to select the best value and also gives an indication when you would need to add additional LOD. In the screenshot below you see an object that has LOD 100 in FSX, but given the 14097 vertices in the LOD MSFS 2024 would allow a LOD value of 239 as minimum value.

Preserve node names

After importing an object ModelConverterX does optimise the scenegraph, the structure of all the nodes in the object, as you can see in the hierarchy editor. During this process the node names that ModelConverterX can read from certain file formats were often lost. After multiple requests from users that they would like to keep those names, for example because it make it easier to edit the MSFS model XML or to find a specific node, I have now modified the optimisation logic so that it will preserve those names.

By default the logic to preserve the node names is off, since it can result in a less optimal model structure and thus more drawcalls. But you enable it in the ObjectModel settings in the Options form. Just set the value PreserveNodeNames to true.

ASToFra libraries for developers

The libraries that are used in my tools, like ModelConverterX and scenProc, are called the ASToFra libraries. Which standards for Arno’s Scenery Tool Framework. Other developers are sometimes using these libraries in their (freeware) tools as well, for example to have a 3D preview of Flight Simulator objects.

Until now these developers needed to pull the libraries from a ModelConverterX development release, but I have now changed this. From now you can pull the libraries from the SceneryDesign.org NuGet feed and that way get the libraries and their dependencies into your tool.

There were some samples available as a ZIP file on how to use these libraries, I have put these in a public Gitlab project now. This project also contains the reference to the SceneryDesign.org NuGet feed mentioned above. So this would be a good starting point for developers:

https://gitlab.com/scenerydesign.org/astofra-developer-examples

.NET version update in next development release

I have finished testing the upgrade to .NET 8.0 for my tools, so the next development release will contain this change. I expect to release it in one or two days.

If you want to keep using the development release on Windows 7 or Windows 8 systems, you better make a backup of the current development release. Once the .NET upgrade has been rolled out these OS are no longer supported.

Upgrade of .NET version of tools

As I already mentioned in this blog post from the end of last year, I am going to upgrade the .NET version that the tool use. Currently the tool use .NET Framework 4.8, but while developing I notice that a lot of third party library are nowadays only available for more recent .NET version. For example the latest version of the Assimp library that is used to read various 3D formats (like COLLADA, FBX) is not available as an easy package for the .NET version I use now. And also when working on the mesh optimization compression of glTF file I noticed that libraries to support this compression are only available for recent .NET versions.

Therefore I have decided that I will upgrade my tools to the current long term support (LTS) version of .NET. At the moment .NET 8.0 is the LTS version. Every two years Microsoft releases a new LTS version, so my intend is to keep track with that. That means every two years the tool will update the .NET version they use to the current LTS version.

I do realize that this change does affect certain users, as has been discussed on the forum already. .NET 8.0 is only available for Windows 10 and Windows 11. So this means that users still running older Windows versions will have to use the older (stable) releases that still target the older .NET version. But given that Microsoft is no longer supporting these old OS versions (even Windows 10 will be end of life later this year), I think the right decision is to switch to an actively supported .NET version now.

The last two weeks I have been working on the migration to .NET 8.0 already and I have all applications and the unit tests running in the new version now. I need to do some more testing to ensure that the functionality is working correctly, but I hope to release the update in a week or two from now. I will post another announcement when the release is imminent, but I wanted to inform all of you now already about the upcoming change.

Reading MSFS 2024 library BGL files

Until now ModelConverterX could not read MSFS 2024 library BGL files, you would get an error that the objects inside were not recognised. This is because MSFS 2024 does store your glTF models differently in the BGL file than MSFS 2020 did. You might have noticed that the BGL files are also smaller for MSFS 2024, that is because a compression is applied to the glTF data.

I have now updated ModelConverterX to support this zstd compression of the objects, so that you can open library BGL files again in the tool. This functionality is available in the latest development release.

I wanted to test it with some more models on my machine, but MSFS 2024 keeps crashing when I tried to compile a scenery package or when I startup the sim. So I’m afraid the testing has been a bit limited. If you encounter any issues, just let me know in the FSDeveloper forum.

FSDeveloper upgrade issue

Just a quick note, I was in the process of upgrading FSDeveloper to the latest forum software version when the process got completely stuck. It seems to be in an invalid state now and I have to manually upload the new version. But since the FTP is very slow I’m afraid that might take a while. So I think we’ll be down for a while…

Wasting performance

With the new LOD system in MSFS 2024 I did notice that more users are using the LOD Creator tool of ModelConverterX as well to add levels of details to their models. So this triggered me to look at a number of issues and feature requests for the LOD Creator that were still on the TODO list.

The first one I looked at is the performance of the LOD Creator. When using a complex object with many triangles it takes a lot of time to calculate the LOD. So I used a profiler this time to have a look which steps of the algorithms take most time. And as usual, it is not where you think the complexity should be of course. The vertex clustering LOD creator was for example wasting a lot of time by updating the slider in the editor user interface at a much too high rate.

In my mind it was not that long ago that I implemented these algorithms, but it turns out that it was 15 years ago already. And I must say that in those 15 years I did learn quite a bit more about programming as well. So the code that I made back then did not look that good anymore with my current standards. I thus took some time to cleanup the code and structure it better.

The results of this are quite stunning if you ask me. An object with 8000 triangles took just over 90 seconds with the old code to calculate a new LOD. After all the changes I have made now it takes less than 2 seconds. Sometimes it is impressive how much performance you can waste in places where you don’t expect it. These performance improvements will be part of the next development release.

Changes to .NET project structure

In this blog post I want to explain some things about the new development releases of my tools that I just put online. This time it is not an announcement for new exciting functionalities, but it is to let you know that the last week I have been updating my .NET projects. I started working on ModelConverterX in 2007 and at that time it was my first C# project. Since then I have of course learned a lot of new things, but the basic why my .NET projects were structured did not change a lot. Recently I was noticing that this limited me to use new libraries and other recently developments. So I have now upgraded all my projects to the .NET SDK format so that I can go to more recent versions of .NET in the (near) future. Also I have used NuGet more to get the 3rd party libraries that I use.

The development release that is now online does still target the same .NET version as before I changed the project structure. So it still uses .NET Framework 4.8. But I plan that somewhere in the next weeks I will try to upgrade to a more recent version, probably I’ll go to .NET 8 directly. Once that is changed I will of course announce it.

The changes I made now have changed quite a lot internally. I did quite some testing to make sure everything still works, but still it could be I missed something. So if you have any issues with the latest development release, please let me know on the forum or by email.