Oops, a bug…

In the latest development release of ModelConverterX I have fixed a bug with the export of the metallic, roughness and AO texture (the comp texture) to MSFS models. That there are bugs in my tools now and then is something I am used to (bug free software is hard to find). But for this bug I was a bit shocked that it has been in ModelConverterX for about 9 months and it only got reported to me by two users in the last few weeks. And with the bug present the comp texture in glTF models would not work in MSFS at all.

I introduced this bug while adding support for MSFS 2024 materials at the end of last year. But to be honest I am still not really a MSFS guy. The way of working of FS2004 and FSX is still more in my system. So personally I don’t really notice if the materials are working right, I more look at them from the coding point of view (glTF file format, OpenGL shaders to render them). I would not even know how to make a comp texture from scratch myself.

And the fact that MSFS takes so long to just startup and test a simple object (something that takes very little time in FSX), also means that personally I don’t really enjoy if I have to test something in that sim. I really miss the old SDK tools that you can just run from the command prompt, instead of having to fire up the whole simulator to just compile a project. And then I don’t even mention the fact that each time I start up MSFS I first have to download a few GB of updates before it will run.

Sorry for ranting a bit about MSFS here :). Let’s summarize this post by saying that I am very happy to get feedback from developers who are more into MSFS on things that are broken or could be improved in my tools. I’m sure that together we can fix them and maybe one day I will get more used to the MSFS way of doing things…

Changes to options

In the latest development release of ModelConverterX the way you can specify the different options has changed. Before all options were in one options form, but now they have moved closer to where you need them. That means that the options related to importing or exporting are now found in the same dialog where you specify which file should be imported or exported. And also the dialog will only show the options that are relevant for the format you are working with.

The video tutorial below gives a quick demonstration of where you can find the different options now. I hope you like it!

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…