Visibility conditions in the preview

The last development release adds a new feature that had been in my mind for a while already. I have added a way to control which visiblity conditions are shown in the preview. Until now all visibility conditions were rendered as if their condition was true. Now if you click on the Visibility Condition State button (the eye next to the LOD selection) you can select which condition is true (and thus shown) and which one is false (and thus hidden).

The screenshot below shows how the control looks for the default Extra 300 of FSX. I have selected one of the three propeller states to be shown in the preview. This makes it easier to inspect how the model looks under these conditions.

Whatever selection you make for the preview has no impact on how the model is exported. All visibility conditions are always exported.

Texture related changes

The latest development release contains two texture related changes.

Size multiple of four

The first is that MCX now also supports resizing textures so that their size is a multiple of four. This is the requirement that MSFS has for the textures. FSX and Prepar3D have the more strict requirement that the size should be a power of two. The material editor has been updated so that it can perform both actions now. If you set the preferred version to MSFS in the options the default behaviour is to resize to a multiple of four. Any other preferred sim will give the previous behaviour of resizing to a power of two.

The fact that MSFS has the requirement that the texture size is a multiple of four, does also imply that MSFS does not use mipmaps when compressing the textures. Because if you want to ensure that mipmaps can be generated the size has to be a power of two.

DDS and DXT BMP generation without ImageTool

The second change in the latest development release is that DDS and DXT BMP textures are no longer generated using the ImageTool tool from the FSX/P3D SDK. For people with only MSFS or X-Plane installed this dependency on the FSX/P3D SDK did not make sense. So I have implemented my own exporter now for DXT compressed textures.

Based on the preferred FS version and the characteristics of the alpha channel of the texture MCX will automatically select if it uses DXT1, DXT3 or DXT5 compression for the textures. In the texture settings there are a few new options that influence this selection as well.

From the testing I have done the new DDS export seems to work just as well as ImageTool, but if you find any texture that has issues when exporting, just let me know in the forum.

DIY or not?

When developing my tools I often have to choose between implenting a functionality myself or using a third party library that provides it. Both approaches have their pros and cons of course.

When coding something yourself you possibly reinvent a wheel that somebody else already did. But on the other hand it gives you more flexibility to implement it the way your tool needs it. And when there are bugs in a functionality they are often easier to solve.

When using a third party library the arguments are kind of reversed. It’s often quicker to use a library, but glueing all kind of libraries can result in a messy architecture of the tool as well. And for bugs the library is sometimes a black box where you can’t look into.

For MCX I have been meandering between these approaches for quite a while already. For example initially I made my own COLLADA reader, while later I switched to the Assimp library to read COLLADA and other formats. But sometimes there are issues where the library just throws an error and you can’t easily debug them, so then I wish I still had my own reader (of course forgetting at that moment how much work I can be to maintain that code).

So why am I talking about all this now? At the moment I’m implenting a feature to write DDS files without ImageTool. I tried to find a library for that, but the only good one I found targeted a much newer version of dotnet and updating MCX to thst version proved to have a lot of errors. So in the end I decided to write my own DDS writer and that’s what I’m working on now.

And of course there is one more pro of writing some feature yourself, you learn a lot from it. And this understanding, in this case about the DDS file format and its limitations, also helps to understand better why the sim works like it does.

ModelConverterX 1.5 stable release

The new stable release of ModelConverterX is out. Version 1.5 replaces version 1.4 as the stable release. Compared to version 1.4 many changes and bug fixes have been made. Some of the highlights of these changes are:

  • Many performance improvements resulting in less memory usage and quicker importing and exporting times.
  • Support for MSFS has been added (glTF format and MSFS specific BGL files.
  • The preview can render PBR materials as well now.

Please have a look at the up-to-date manual that is included in the stable release if you want to know how the various functions of ModelConverterX work.

With the release of the new stable release, the ModelConverterX development release will be updated to version 1.6 as well. This new version of the development release contains some changes to the architecture of the tool. These are mainly to make it easier for me as a developer to develop and test the tool and as a user you should not notice it too much. But let me know if there are any broken features.

scenProc 3.0 stable release

The new stable release of scenProc is out. Version 3.0 replaces version 2.0 as the stable release. Compared to version 2.0 many changes and bug fixes have been made. Some of the highlights of these changes are:

  • Many performance improvements resulting in less memory usage and quicker processing of your scenProc script.
  • A new and redesigned texture filter editor that allows more complex texture filters to be made.
  • The ability to create textured 3D buildings from footprints and export them as MDL files.

Please have a look at the up-to-date manual that is included in the stable release if you want to know how the various functions of scenProc work.

With the release of the new stable release, the scenProc development release will be updated to version 3.1 as well. This new version of the development release contains some changes to the architecture of the tool. These are mainly to make it easier for me as a developer to develop and test the tool and as a user you should not notice it too much. But let me know if there are any broken features.

A 12 year old bug and some hierarchy editor changes

Sometimes bugs spend quite some time on my todo list. For example there was a bug in rendering the default FSX EH101 model that has been on that list for over 12 years. At that time I could not found the cause of the rendering issue and since then the problem has not surfaced too often it seems.

But a few weeks ago an user reported a bug with rendering his virtual cockpit and the bug also showed when export the cockpit to glTF for MSFS. So I took the time to dive into the issue in detail this time and I finally found the cause of it. It turned out MCX has been processing certain combinations of transformations and animations incorrectly for a long time already. For all those years the issue only showed as an incorrect rendering in MCX, when the model was exported to a MDL again the problem was not there.

But now with the ability to export to glTF for MSFS as well it turned out to be an issue, as the transformation and animations were also incorrect in the glTF file. The issue has been fixed in the latest development release.

While debugging this issue I also made some changes to the hierarchy editor. I have added an option to add a new child scenegraph node and also to copy and paste transformations and animation between different nodes. Please check the updated manual to see how these new features work. I think they will be useful when working on your model as well.

This was the last bug on my todo list before I release the new stable release. So I guess I will wait a few days to see if no new critical issues appear and then I will start to prepare the new stable release.

Upcoming stable releases

I will be releasing a new stable version of ModelConverterX and scenProc in the next few weeks.The reason behind these new releases is twofold.

On one hand over the last months there have been many improvements to the tools, mainly in the area of performance. So it is worthwhile to have those improvements in the stable release as well.

On the other hand I am also working on some changes to the internal architecture of the tools at this moment. This changes will allow me to develop the code better in the future, as it makes the code more testable. So in the end that should result in better tools, but because it is a relatively big change on the short term it also increases the risk of new issues. So before I make that available in the development release, I want to have a good stable release available for users to fall back onto if needed.

In the next one or two weeks I will closely monitor if the current development release has urgent issues that need to be fixed. If I see none, I will promote it to the new stable release after that period. So the current development release can be seen as a kind of release candidate version of the new stable release.

Vertex colors

One of the new features of MSFS compared to FSX and P3D is that you can specify vertex colors in your model as well. This means that just like a position or a normal, each vertex of the model can have its own color as well. This can be a more efficient way to set colors, as you don’t need different materials in that case.

Until now ModelConverterX did not support the concept of vertex colors. When you would load a glTF file which such colors they would be lost on export and ModelConverterX could also not render this information. That has changed with the latest development release. ModelConverterX can now import, export and render vertex colors as well. So this means you will no longer loose this information when working on your model in ModelConverterX.

Besides the glTF importer and exporter, also the Assimp importer and exporter have been updated to support vertex colors. So that means you can also read and write them to COLLADA and FBX files.

Animation mapping

The latest development release of ModelConverterX has a new feature that can help in converting models between different sims. Often these simulators use different names for their animations. For example FS2004 and FSX have different names for certain types of animations. Before ModelConverterX used a hardcoded mapping when importing these models, but now this mapping has been made user configurable. This way you can control better how the animations are exported.

Internally ModelConverterX uses the FSX/P3D animation names, as defined in the modeldef.xml file. At the moment two mapping tables are configurable, one from FS2004 names to FSX names and one from X-Plane names to FSX names. The manual provides all the details on how to configure the mapping.

If you find that the default mapping table that ships with ModelConverterX is missing an animation mapping that is generally available, please post this information on the ModelConverterX forum, so that I can include it in the default mapping file in future releases.