FSDeveloper & X-Plane?

There has been some discussion recently on the FSDeveloper forum about creating a place to discuss X-Plane related topics as well. We have now created a poll to see how much interest there is to discuss addon creation for different simulators. Let us know what you think.

It is a long time ago that I looked at X-Plane myself, but I have been able to compare MSFS development with creating scenery for professional flight simulators (those that airliners use for their training). There are more similarities than you might expect at first. So I am sure that between FSX, X-Plane, FlightGear or whatever simulator platform there are also more similarities and opportunities to share knowledge then we might think at first.

ModelConverterX & crashbox granularity

In the previous post I talked about specifying the crashbox granularity in XtoMDL. I have now added an option to ModelConverterX as well to do this. The picture below shows the Exporter settings of ModelConverterX. If you want to specify the crashbox granularity you need to do two things here:

  • Set the option SetCrashboxGranularity to true, the default value is false which means the standard XtoMDL value is used
  • Specify the granularity you want in the CrashboxGranularity option

An undocumented XtoMDL parameter

At the FSDeveloper forum there was a question about the size of crashboxes in FSX. These are often not so accurate around your object and that can give trouble with the aircraft crashing too early. So the question was how to change that? I did not know the answer, but I found it. There is an undocumented option in XtoMDL that lets you specify the granularity of the crashboxes.

/CRASHGRANULARITY:1.0

That’s the additional parameter you can specify for XtoMDL. The granularity seems to be given in meters. If you don’t specify this option you get a crashbox of 8x8x8 cells. This seems to be the minimum as well. If you specify a lower granularity you get more cells, but they will still be a power of two. So you don’t always get the exact resolution you want.

The more detailed the crashbox, the more it will influence the performance I guess, but I haven’t tested yet how big this effect is. Below you see three screenshots of an object with no granularity specified and with a granularity of 1.0 and 0.25. The difference is quite obvious.

So I think I need to fire up my IDE and add this new parameter to ModelConverterX now…

Alpha test level

ModelConverterX uses certain default values for the material settings when you press the “Set Default Transparent” button in the material editor. On of them is the alpha test value, which had a fixed value before. But with some alpha values in the texture that could result in the transparent part  not showing up properly. This would mainly happen with parts that are very transparent (alpha value between 0 and 128).

Today I have changed how ModelConverterX sets this setting and it now also looks at the texture you are using. So if you have a low alpha value, the setting will be adjusted to that. This will hopefully result in more objects with transparent textures working out of the box when converting with ModelConverterX.

ModelConverterX development release

Those following the forum might have noticed that in the last days the development release had some bugs on 64 bit systems. I posted a link to a fixed version on the forum. From now on you can just download the development release at the normal link again. The fixed version I posted is no longer available. I will make sure that the development release always works on 32 and 64 bit systems.

The bugs have not been completely solved yet, but until they are I will manually fix the issue before putting the development release online. So the development release is not automatically updated every night, but only with my manual labour.

Ground Polygon Wizard becoming more popular

It is great to see that the ground polygon wizard in ModelConverterX is getting more popular. I added this functionality some time ago to ease the scenery design process and let people avoid the manual tweaking of ASM files (it seems most people don’t like to use text editor to tweak source code). So I am happy to see the usage of the tool is picking up now.

How do I know this, you might wonder? Mainly by the amount of bugs that get reported. I tried to make the tool as robust as possible, but it seems end users can always come up with ground polygons that are different and do sometimes break the tool. I do try to fix such issues as soon as possible and would like to thank the users who are happy to try this development release and help me make it even better.

New Prepar3D 3DS Max SDK

For those developers using 3DS Max to make their aircraft or scenery models there is good news. A common question on the FSDeveloper forum is which version of 3DS Max can I use together with the FSX gamepack? The bad news in that case is that it does not work with the latest versions and you can’t legally buy the old versions that do work. But now the good news, an updated SDK for Prepar3D has been released. This SDK includes the tools to export from the more recent versions of 3DS Max. Since the Prepar3D MDL format is the same as FSX, this SDK should also help FSX developers. So thanks to the Prepar3D team for this!

You’ve got an update!

I have added a new function to ModelConverterX, an notification when a newer development release is available. When a newer release is available you will get a notifcation message as shown in the image below. If you click on the balloon you will be taken to the ModelConverterX webpage where you can review the latest changes and download the new release. If you don’t want this function you can also disable it in the options of course.

There is only one catch to all this, you need to remember to get the latest version yourself to get these notifications in the future.

Ground Polygon Wizard change

I have made a few small changes to the Ground Polygon Wizard. These changes deal with the way you can filter out polygons from your object after loading. In the previous version there were two buttons for this. “Filter out non-ground polygons” would remove all polygons that were not on the ground, while “Lower polygons to ground level” would lower all horizontal polygons to the ground level.

In the new version these two buttons are gone. But instead of them you will find two checkboxes directly under the box where you select the file to load. This means that you now specify which filtering you want before you select the file to load. While loading the object the filtering will directly be done. The names of the two options have also changed a little bit.

The first is now called “Project flat polygons on ground”. This does almost the same as the lower ground polygon function before. The only difference is that you can now specify a tolerance for a normal that is still considered as flat. So that means that if you polygons are slightly tilted it will still work. Most of the time the default values should work fine. The second option still works the same and will remove all polygons that are not on the ground. Another difference is that the functions are performed in a fix order now. If you have the checkboxes selected first the polygons will be projected and then the non-ground ones will be filtered out.

I hope these changes make it a little easier to work with ground polygons in the wizard. And be careful with the default settings when you are loading a file that also contains buildings, the project option would project them onto the ground as well. In that case you would like to disable the option.

Better performance for line intersection calculations

Today I was “playing” a bit with a profiler on ModelConverterX. This gave some interesting insights in how often certain functions are called or how much time is spend in certain functions. One of the things I noticed was that while loading SCASM API macros the triangulation of the polygons took relatively a lot of time. So I decided to have a look at the code involved and found out that the calculations to determine if lines intersect were to blame for all this.

So I have rewritten this logic now and that seems indeed to have increased the speed of loading API macros quite a bit. On one of my test models it went from 1.3 to 0.5 seconds. So especially for big or complex files you can expect some increase. Some part are still not as fast as I would like, so I will continue to find places where I can improve the performance.

As a nice side effect of these changes, I have also noticed that the Ground Polygon Wizard works faster now, the slicing functionality uses the same code to do line intersections when using the boolean operations.