From within ModelConverterX and scenProc you can upload an error report directly to my bug tracker. There is an option to include the file that caused the crash as well. Recently I noticed that most users did not try to upload the file anymore, which makes debugging harder. Today I found out the problem was that uploading failed because the server could not be reached correctly. This will be fixed in the next development release. But please feel free to report this kind of issues in the forum as well, I never use the error report functionality myself, so I never spotted this was not working anymore.
The latest development release of ModelConverterX contains some new functionality that help you to inspect if your model is likely to have texture distortion issues in MSFS and also allows you to minimize this effect by updating your model. The video tutorial below explains all these functions.
I would also like to mention that the background information chapter of the ModelConverterX manual gives more technical background on why this distortion happens in MSFS. So if you want to understand that I encourage you to read that.
In the latest development release of ModelConverterX a new feature has been added to the hierarchy editor. You can now also modify the material of model parts in the hierarchy editor. When you click on the material name you get a list of all materials in the model and can select which one should be applied to the part. If you hold down the control key while selecting a copy of the selected material is made, so that you can change attributes without affecting other parts that use the same material. The video tutorial below shows this new functionality.
With the recent changes for scenProc to export to MSFS as well, I have added writing a scenery to a MSFS package to the exporter capabilities. This means that ModelConverterX now also has the same export capability. So if you select “Export scenery” you will be able to export to a MSFS scenery package.
The created package contains a PackageSources folder with the XML and glTF files of your objects and their placement. As well as the PackageDefinitions XML file and a project XML file. This means you can directly compile this package with the MSFS package tool. So this capability can be used to have a quick start with making a package.
If you have just modified a single model, it is probably easier to export it as a glTF file as before and insert the new glTF files in your existing package manually.
For me it is also a bit searching to see which workflow makes most sense for MSFS. So if there are ideas to improve or change the package export, just post your suggestions in the forum.
The latest development release of scenProc does adds initial support for MSFS. Since the release of MSFS I have been waiting to update scenProc as it was not clear to me what purpose the tool would still have. For example the new autogen format is still largely unsupported by the SDK tools, so making autogen for MSFS is not an option. But over time it become clear that placing objects or exclusion rectangles based on GIS data is still useful when working on a scenery of a larger area. Therefore support for MSFS has now been added. If there are other scenery elements that should be supported or if the functionality of the steps should change just post in the forum with your ideas.
So what has been added in the latest version?
- With the ExportMSFS step you can write XML and glTF files in the MSFS scenery package structure. This step will create a basic package that you can directly compile with the package tool. Of course you can also choose to copy the XML and glTF files into your existing packages, that just depends on the workflow you prefer.
- With the CreateXMLRectangle step you can make MSFS style XML rectangles. These can for example be used to make exclusions. The ExportMSFS step will write these rectangles to XML output.
- With the CreateXMLSimObject step you can place an instance of a SimObject at a certain location. This step works like CreateXMLLibObj, but then for SimObjects. The ExportMSFS step will save the generated placement information to XML file again.
The manual has been updated as well, so all new steps are explained in there as well. I hope this addition to scenProc is useful and if there are more suggestions just let me know.
The last ModelConverterX development release adds a cool new feature. You can now select nodes of the object by clicking on them in the preview. The hierarchy editor will then directly jump to that node or the material editor will show the material used on that node. The video below illustrates this new feature.
I have made a change to the hierarchy editor, when you drag and drop a node onto a new parent node, the location in the world of the object that you are dragging will no longer change. Before this change the object would suddenly move if the new parent has a different transformation applied to it, for example because it is animated. Now the hierarchy editor calculate the correct transformation so that the location in the world of the node no longer changes. This should make it easier to add attachpoints to animated parts or change the general structure of a model.
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.
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.
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.