ModelConverterX user interface update

I have just released another update of ModelConverterX, this time the changes mainly affect how the user interface works. I have made the code more modular, so that it is easier for me to develop. But this also has a benefit for you as end user. With this new design you can keep all editors and windows open. So for example the Object Information Form, the Material Editor and a Scale Editor can all be open at the same time.

Well, I hear you say, that is not really something new is it? I can do that in the old version as well. Yes, but the difference is that the content of those editors is now correctly updated when you perform an action in another editor. So for example the Material Editor will be updated correctly when you use the Drawcall Minimizer while the Material Editor is still open.

As you can probably understand these changes to the design meant that quite some code had to be edited. I did not find issues while testing it here, but please let me know if you find a function that no longer works or if you have other feedback.

X-Plane OBJ reader

I have added a new object reader to ModelConverterX, this time for the X-Plane OBJ format. From tomorrow this new reader will be available in the development release. I don’t have an extensive collection of test objects in the X-Plane format yet, so it might be not all commands are properly supported yet. But the reader should support the following features:

  • Reading geometry
  • Reading LODs
  • Reading animations
  • Most of the material/appearance attributes

Aircraft specific elements, like cockpit regions are not supported at the moment, since these can not be exported by ModelConverterX to any other format. If you find some additional commands that are not supported or have other feedback please let me know.

While testing with X-Plane OBJ files I also noticed that the DDS files that X-Plane uses are not vertically flipped like those in FSX (or should I say that they are vertically flipped while FSX is not). So I have added an option to ModelConverterX to determine if the DDS files should be flipped or not. When set to false FSX DDS files will read and show fine. So you might need to set it to true when reading X-Plane DDS files.

Initially I planned to release a X-Plane OBJ reader and writer at the same time. But as you can see this is only the reader. The writer has to be delayed a little bit, because the X-Plane OBJ format only allows you to use one texture per object. That would mean that most FS object would not be exported correctly anyway. I will first modify the drawcall minimizer a bit more, so that it can more aggressively reduce the object to only one texture. After that I will add a writer for the X-Plane OBJ format, so that object conversions can be done in both directions.

Back from Slovenia

The last two weeks I have on vacation, camping in Slovenia, but now I am back home again. I am still in the progress of cleaning, unpacking and storing all the camping stuff. But once that is done I hope to spend some time on flight sim things again. I have some cool features for ModelConverterX that I want to work on and of course I need to catch up with the FSDeveloper forum as well. So expect some more activity from me again in the next few days. The image below is lake Bled in Slovenia where we spend a couple of days.

How to deviate from your roadmap…

I usually keep a list of bugs and features that I want to work on first for ModelConverterX. This is sort of my roadmap to the next stable release. But as it goes with a hobby project like this, sometimes the fun things push you away from the planned roadmap. Let me give you an example.

Last week I made a video tutorial about placing effects using ModelConverterX. In some of the discussion that evolved after this a user, I won’t say it was you Bill, mentioned that it would be cool to have the actual effect also displayed in ModelConverterX. This was a nice idea of course and I think it was already somewhere on my todo list. So let’s just check that it is and go back to the higher priority items on the roadmap, right?

Well not really, this idea kept spinning around in my brain. I started reading the special effects part of the SDK again and searching with Google how to make a particle system. At this moment I even think that it shouldn’t be too hard to implement the display of the actual effect. So I’ll be heading back to my paper and pencils after I finish writing this blog post to work out the design a bit more.

And do I find this annoying? Well, not really. This is what makes it fun to make tools for FS. By such comments you get new ideas and all the time explore new parts of FS. I think I have a much better understand how effect file work now already. And once I have finished this feature I think I should understand them even more. So don’t feel guilty to mention such ideas in discussions. Just don’t hold your breath for the stable release, while I jump around to implement some of those cool ideas…… (did I hear somebody say X-Plane support there in the distance as well) ……..

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.