MSFS materials

Since last week ModelConverterX supports reading and writing of glTF files for MSFS. But this version did not yet support all the material attributes that MSFS has. There are 15 different material types that can be used in MSFS and each of them have a different set of attributes.

The latest development release of ModelConverterX adds support for all these material attributes. This means that you can read them from the glTF file and also export them to glTF again.

The material editor does also show the available attributes. To work with the MSFS materials you can best select the MSFS filter at the top. If you change the material type attribute to the different types that are supported, the attributes will be updated to only show the ones that are supported by that material type.

Since the MSFS materials are quite complex, I have not been able to test all attributes. So let me know if there is a bug in how certain of the materials are implemented.

glTF support for ModelConverterX

I am happy to announce that from today the development release of ModelConverterX supports the glTF format as used by the new MSFS. With this addition I have also changed the version number of the development release to 1.5.

You can now read glTF files and the MSFS BGL files that contain the object models into ModelConverterX. When reading the BGL files that have been generated by the package tool of MSFS ModelConverterX will show the texture mapping incorrectly, that’s because MSFS stores the texture coordinates in a non-standard way. I hope to figure that out later.

You can also export models in the glTF format, so that you can include them in your scenery package. At the moment the exporting is limited to static objects, so you can export the geometry, material settings, levels of details and lights. Other features like animations, mouse rectangles or visibility conditions are planned to be added later.

In the material editor you can select MSFS now as a filter as well. That will only show the material settings relevant for MSFS. I have mapped the material attributes on the already available ones where possible, to each conversion from older formats to MSFS. But this also means that the names are sometimes slightly different from what the MSFS SDK uses. I plan to update the help texts to clarify this more. For some of the more exotic material types in MSFS not all attributes are implemented. Those will be added later.

At the moment I am not sure if ModelConverterX should call the package tool for MSFS directly, as the package tool typically makes all BGL files of the package, while ModelConverterX is now designed to only make a single BGL file. So for the moment I think it is better to export a glTF file and then create the package from inside MSFS. But if there are suggestions on an easier workflow, let me know.

As can be seen from all the details above, the glTF support is not yet finished. And I’ll continue to add more features. So please let me know if you encounter any issues while using it.

FS2020 support

With FS2020 being available I would like to let you know that I have started on adding support for the glTF models in ModelConverterX already. But it’s not yet finished or fully tested as my current machine doesn’t meet the FS2020 specs.

Once I’m back from vacation I’ll continue on this feature. By that time the dust of the release should have settled a bit as well.

And I’ll have to see how to upgrade my machine, so that I can properly test things.

Ground Polygon Wizard update and seasonal models

The latest development release contains an updated version of the ground polygon wizard (GPW). The user interface has not changed a lot, but under water a lot has changed. So if you run into small issues with the new GPW, please let me know.

The following changes are included:

  • Before the GPW would set the layer number and other attributes at the level of the texture name. This meant that if you had different materials that used the same texture, the GPW would all give them the same settings. In the new version the GPW settings are set at material level, which means that multiple parts with the same texture can now have a different layer or other setting. This also means that you can see the same texture name mentioned multiple times in the list in the GUI.
  • Before the GPW only supported seasonal texture for FS2004 and FSX output. Now seasonal textures are also supported for P3D v4 and P3D v4.4 output. Below I will explain more how the seasonal textures are supported.

So how does MCX support the seasonal textures? This can be done in two ways and the way that is used is selected with the “Use season material script” option in the exporter settings.

  • When this option is set to true, MCX will create a LUA material script that will switch the textures based on the season. The LUA files are saved in the same directory as your BGL or MDL file, so you need to copy them over to your addon. It’s probably easiest to create a local script folder in your addon and load that via the add-on.xml file.
  • When the option is set to false, MCX will use visibility conditions to switch between different model parts that have the seasonal textures on them. The downside of this approach is that your MDL file gets bigger.

You can determine how the seasons need to look in the Season editor. You can select there which seasons are active for your area and in which day of the year each season starts and ends. If you have a heavy winter (with snow) season in your area, you can use winter and winter2 to have a non-snowy winter representation before and after the heavy winter.

In the ObjectModel settings the suffixes that are used for each season are defined. The default values use no suffix for summer, and the logical _SP, _FA, _WI and _HW for the other seasons. But you can change that to your needs.

And the good news is that this functionality to add seasonal textures is not only available in the GPW. You can also use it on a normal model that you export to P3D v4 and above. In the material editor you can set the HasSeasonalTexture option to true and then MCX will create the material script or visibility condition on export of your MDL file. The Season editor can be used to define the seasons again, as this editor can not only be started from the GPW, but also from the toolbar in MCX (it’s just left of the scale object button).

I hope you all enjoy these new functionalities and let me know if you have any issues with it.

scenProc autogen building bug

This week I have fixed a bug in scenProc that could result in autogen buildings showing incorrectly in Prepar3D. This especially affects buildings that are oriented exactly north-south or east-west. They would show with a roof of the correct size, but with the walls too small, like in the image below.

This bug has been in scenProc for many years already, so it will affect autogen files made with scenProc v1, v2 or the latest development release. It has been fixed in the development release of April 20th. So if your addon uses autogen buildings made with scenProc and you target the Prepar3D simulator you can best generate your autogen files again with the latest development release.

FXEditor update

I have just released an updated version of the FXEditor tool. In this new version the following new features are included:

  • In the text editor you can use code folding on emitters, particles and particle attributes. This means that for complex effects you can collapse some of them and thereby navigate easier through the file.
  • There is a Remove emitter button now, which will remove the emitter, particle and particle effect sections of the emitter that the cursor is currently in. This way you can quickly remove an entire emitter.
  • You can now add templates to the FX file. This way you can for example add another emitter more easily. The templates themselves are stored in the FXTemplates folder in FXEditor, so you can add your own if you want. And if there are suggestions to improve the default templates or add more templates, just let me know.
  • I have added an up to date manual to the FXEditor tool as well now.

Prepar3D v5 support

I have just released new development release versions of all my tools with added support for Prepar3D v5. The impact of the new version on most tools is limited. Below I list the details per tool.

Overall the impact on the tool is not that big. But let me know if you encounter any issues or if Prepar3D v5 support is still missing somewhere.

ModelConverterX

There is one new material attribute available for PBR materials in Prepar3D v5. ModelConverterX has been modified to read and write this attribute correctly now. Since the MDL version, as coded in the MDL file itself, still reads PV44, I have decided to not add a new version when you export. So for Prepar3D v5 you would still need to use the v4.4 MDL format. But make sure that you use the Prepar3D v5 SDK to be able to save that one additional attribute.

scenProc

In the scenProc options you can specify the Prepar3D v5 location now, so that it can be used for the auto completion of the autogen configuration details.

FXEditor

FXEditor has been modified so that you can specify that you want to read the textures and sounds from the Prepar3D v5 folder.

Autogen Configuration Merger

For Autogen Confguration Merger I have posted a beta build in the forums that should support Prepar3D v5. But since I don’t have the new version installed myself yet, I haven’t been able to test it. So this is a beta build, that needs some more testing before it is promoted to an official release.

Bug reporting broken

I was quite happy the last few weeks that hardly any crashes were reported in my bug tracker from my tools. But today I found out why, the bug reporting is actually broken at the moment. It seems the interface into the bugtracker does not like the newer PHP version that i had to enable for using the latest version of WordPress for SceneryDesign.org.

So now that I am aware of this issue, I’ll try to fix it. Probably the best way forward is to update the bugtracker software to a newer version that will hopefully give a working interface with my tools for newer PHP versions. So let me try to find some time for that upgrade soon.

Edit: the bug tracker software has been updated now and is running fine again. So you can report bugs from my tools again. Although I hope you don’t do it too often….

Image result for work in progress

Autogen object size distortion

That autogen objects have a distortion in their rotation is something we found out 6 years ago already. But until recently I was not aware that not only the rotation of the objects is distorted, also their sizes can be different then you would expect from looking at the objects in the Annotator tool. I guess most of use work in the zones around N40 and S40, where the distortion is minimal, so it took a developer who works outside of that area to inform me of a bug in scenProc that resulted in objects being rendered in the sim with wrong sizes.

So what I did is make a test photoreal scenery where I burned polygons with a known size in the photoreal. Next I placed autogen objects and tried different settings until I could get them to align correctly for each latitude where the objects are placed.

Below you see a screenshot of this test scenery at a latitude of 60 degrees, where you have quite some distortion already (around 41 degrees latitude the distortion is minimal, due to the way the autogen tile sizes are designed). As you can see for some polygons the rotation is off from what you see in the photoreal, but also the sizes of the objects need to be defined incorrect, to have them show correctly in the simulator. Some of the buildings need to be made longer and more narrow for example.

The good news is that you don’t have to apply this kind of rotation and size corrections by yourself. scenProc has been modified to do it automatically for you now. So with the latest development release you will find that the output generated should align more accurate with your photoreal scenery.

How does it work? In Annotator you are seeing your photoreal shown in a latitude and longitude projection. But the heading of the objects should actually be defined in the AGN file for flat earth projected version of the object. And for the size it is even weirder, the sizes are defined in degrees as if the object has a heading of zero. But even when the object does not have that heading, which means you need to provide an incorrect size in degrees to still get the correct size of your object in the simulator in the end.

And just as the proof of the pudding, below is a screenshot of the test scenery in the simulator, where you see things align well.

New steps to place points

The next development release of scenProc will include two new steps for placing points: LineToPoint and PolygonToPoint. In the future these steps will replace the existing steps to place points along lines or inside polygons. As i realise some of these steps are used in many of your scripts, I will not deprecate the old ones very soon. But for new scripts I encourage you to use the new steps.

Why did I make this change? There are a couple of reasons:

  • When I add the LineToPolygon and PointToPolygon step a while back, the idea was already to have similar steps for other conversions between feature types. So the new LineToPoint and PolygonToPoint steps are in the same philosophy.
  • Until now there were multiple steps to place points along a line or inside a polygon. Each with slightly different characteristics, but also with a lot of overlap. So it is easier to have all this logic in one step.

The manual has been updated to reflect these new steps as well. Both in the description of the steps and in the sample scripts.