I have improved the buidling generation algorithm that scenProc uses to create 3D building models from footprints. Additional roof types, chimneys and dormers can now also be generated. I had started on these improvements over a year ago, but got disrupted by the FS2004 aircraft MDL export that I worked on last year a lot. So now I have finihsed this functionality.
Since this building algorithm can also be useful to create generic buildings in ModelConverterX, I have decided to add a building creator wizard to ModelConverterX as well now. In that wizard you can interactively draw a building footprint and then turn it into the building you want.
The video tutorial below shows both the new building creator wizard of ModelConverterX as the way that scenProc uses the new algorithm.
In the latest scenProc development release there are a number of changes to how the machine learning steps work. This post gives an overview of them:
Besides the SVM machine learning step that has been available for a while, a new one has been added now. This one uses the Artificial Neural Networks – Multi-Layer Perceptrons (MLP) algorithm for the machine learning. While working on detecting of water data, I had the impression this algorithm gives better results. But I’m not an expert on the differences of these steps and they both have a lot of attributes to tune them. So I guess you best see for yourself which one works best for you.
When you change attributes of a machine learning step or add sample points, the machine learning algorithm is not trained automatically every time. This was quite annoying as the training can take long with many sample points. Now the step will be rendered in red in the step overview and you have to manually trigger the retraining of the step with a button on the toolbar when you are ready for it.
Besides training machine learning steps with sample points, it is now also possible to train them with raster data. So if you have reference raster data of the required classification or if you have good vector data so that you can make such reference data you can use this as an alternative way to train the algorithm. The machine learning steps have two optional inputs for this, for the labels and the reference data. If any of those two inputs are not connected in your filter the sample points are used for training. Be aware that training on raster data typically takes longer as it includes a lot more training data.
I have updated the object placement editor so that a more accurate footprint of the object being placed is shown. Before the editor would show the bounding rectangle of the object, but now a more accurate footprint is shown. When you have multiple buildings in a single MDL file each of them will show with their own footprint. This should make placing objects even easier.
My tools have the ability to report errors that encounter directly to my bug tracking system for a while. This helps me to fix these issues and make the tools better. Due to some recent changes in the bug tracking system the method I had implemented is no longer working. In the development release I have now fixed this so that hte error reporting works again. But this also means that errors reported from older version (including the current stable release) will not reach me anymore.
I have updated ModelConverterX now so that the additional PBR material options that Prepar3D v6 offers are also supported. There are a number of new material properties related to precipitation effects (including a new precipitation texture) and some other new material flags as well. Besides that P3D v6 also supports exporting vertex colors, so that has also been added to ModelConverterX.
You still need to export as P3D v4.4 MDL file from ModelConverterX (the MDL format is still called PV44), but you need to use the Prepar3D v6 XtoMDL to be able to use the new options.
A while ago I got the feedback that the change log that is included with my tools and can also be viewed here on the site was not really clear. The change log was automatically generated from the commit message in my version control.
Yesterday I have modified the script used to generate the change log, now it will be generated only from the merge requests and no longer from all commits. Also does it list more clear which tools are affected by a certain change. The only downsite is maybe that the layout is less fancy, but I didn’t want to spend too much time on that.
The improved change log is included in the tools from now on and can also still be viewed here on the site of course.
Over the last months I have been working on improving the FS2004 aircraft MDL export from ModelConverterX. While working on this I have made some changes that affect the general usage of ModelConverterX as well, so I want to give an overview of them in this post.
Attachpoint orientation
While making sure that landing lights and taxi lights of FS2004 aircraft export correctly, I have refactored the way the X file are writen by ModelConverterX. While working on this I have also double check that all attached effects, attached library objects and attached platforms are still working correctly in both FS2004, FSX and P3D. Everything is working consistently now.
But there is one change and that is that for some objects the orientation is now shown differently in MCX. For most attached objects the Z axis is the upward direction. For example an attached smoke stack will flow in the direction of the Z axis. But for landing lights and spot lights the direction of the light is different, they shine along the -Y axis. Before this used to by the +Y axis, so be aware that you need to position your lights differently now inside ModelConverterX.
Representations
FS2004 stores the virtual cockpit representation in the same MDL file as the external representation, while in FSX and P3D these are stored as two separate MDL files. To be able to export these representations to FS2004 correctly I have made a change to the internal representation that ModelConverterX uses for the objects. It is now possible to store different object representations and you can also select which one you want to render in the preview with a dropdown box. ModelConverterX supports the following representations:
External.
Internal (for virtual cockpit).
Shadow (used for custom shadow model, at the moment this representation can only be read from file and not yet exported).
The image below (which comes from the updated ModelConverterX manual btw), shows an example of the external and internal representation for an aircaft model.
When reading FS2004 aircraft MDL files or when reading aircraft using the aircraft.cfg file for FSX (or the sim.cfg file for P3D) ModelConverterX will now read the different representations into one object. If you just load a MDL of a specific FSX representation you only get the representation that you have loaded.
On export the FS2004 aircraft MDL exporter will write both representations to the MDL file when present. For all other exporters it depends on a new setting in the exporter settings. You can set them to either:
Give preference to the external representation and only write that one when present (this is the default value).
Give preference to the internal representation and only write that one when present.
Write separate files for each representation.
Found any bugs?
I have spend quite some time on testing all these changes, but I do also realize that they have a relative big impact on ModelConverterX as well whole. So if you encounter any issues or weird things with the current development release, please let me know by posting it on the forum. And I will make sure to look at them as soon as possible.
Some features are on the ModelConverterX wishlist for quite a while already. For example the feature request to export FS2004 aircraft mdl files with working animations and such is on the list for over 10 years already. And given that FS2004 is less popular nowadays I thought I might never come around to implement this feature request.
But sometimes strange things happen. A question from an user on the FSDeveloper forum triggered me to have another look at how MakeMDL handles custom animations and suddenly I realized it is not that different from how XtoMDL does it. Because I thought it might not be too hard to implement therefore, I decided to give it another try.
Of course reality is always different, because it still took me around 2 months to work on this. Once I had the animations exporting correctly, it turned out the reading of visibility conditions was not optimal and this affected the FS2004 aircraft mdl export as well.
But now that is all behind me and the latest development release of ModelConverterX can export a FS2004 aircraft MDL file with working animations and visibility conditions. I’m sure it will not work perfect on any aircraft around, but I think it should be a start for developers still working for FS2004. And if you encounter any issues with a specific model, just let me know via the forum.
Today SceneryDesign.org is 20 years old. On 17 August 2003 I started this website as a new community for Flight Simulator scenery designers. I did this because there was a scenery design forum at AvSim.com at the time, but I thought a dedicated community where developers could share experiences would be useful as well.
After a couple of years the community expanded into other addons than scenery design as well and it was renamed to FSDeveloper.com, so in a way this is also the 20th anniversary of the FSDeveloper.com community.
A few years after the community was renamed to FSDeveloper.com I restarted the SceneryDesign.org website, but now the central website for information about my flight simulation tools and for my personal blog out my flight simulator activities. And that is what this website still is today.
With the release of the new stable releases ModelConverterX 1.6 and scenProc 3.1, the development releases have also been updated. The ModelConverterX development release is now version 1.7 and the scenProc development release is now 3.2.
In these new development releases there is a big change directly, they only support 64-bit now. This means you can no longer run them on a 32-bit OS. A recent poll also showed that nobody was using the 32-bit version anymore. Therefore I have decided to simplify the build process and remove the support for the 32-bit version. A factor in that decision was also that I test and develop on 64-bit only, so the 32-bit version of the tools was already tested much less.
With these changes it is recommended that you do a clean install of the new development releases, instead of installing them over an older version.
SceneryDesign.org 
