ModelConverterX magic

The last few days I have been working hard on improving the ModelConverterX tool again. Some other members of the Netherlands 2000 Scenery Design team were busy trying to convert some of the old API macros in the project to new FSX MDL files, so they provided me with a fresh stream of bugs.

While testing one ship object I came to an interesting conclusions, illustrated by the screenshot below. In the screenshot you see the ship in ModelConverterX in the top left corner. On the right you see it twice in FSX. The ship at the back is the original API macro. It is obvious that FSX has trouble to display some of the features of this object. Apparantly this object uses some opcodes that are soo old that FSX no longer fully supports them. But the ship in the front is the same object, placed as a FSX MDL file after converting it with ModelConverterX. This looks a lot more like the ship it is supposed to be.

I found this a nice example to illustrate the benefit of converting your old objects to the FSX format. That is also the purpose I started making ModelConverterX for in the first place.

Some Wiki updates

I have added some additional information to the FSDeveloper Wiki.

  • Update of the information on the FSX MDL format. This is mainly what I figured out while adding support for animations to ModelConverterX.
  • Added an article to explain the different DXT compressions that can be used for textures. I would be happy to receive any feedback wether the information is understandable for a normal developer in the way I have written it.
  • Added an article about the FSX AGN format. It is far from complete at the moment, but hopefully it provides a start for more information on this format to be collected.

Replacing the object market

Before we had a forum called Object market at the FSDeveloper site where people could share
their work with other developers. This forum has now closed and all
objects from it have been added to the downloads section.

Of course users are still free (or I would even say encouraged) to contribute their work to the download section. Here you can find all instructions on how to do so.

New categories

I have added two categories to the FSDeveloper forum. One for autogen related questions and another one for Microsoft ESP specific discussions. The ESP forum is meant for things that are related to ESP only, if it is a design question that applies to FSX and ESP both please use the existing subforums for scenery and aircraft design. I have also tried to move all posts that should belong in these forums to them already.

Merry Christmas and Happy 2009

The last time I have been quite busy, so therefore there have not been any new posts on this blog recently. I have just come back from a short vacation in Belgium and am full of energy again to do some interesting FS related things in the remainder of my Christmas break. I plan to for a bit on the FSDeveloper forum and Wiki, work on the ModelConverterX tool and what else comes to mind. Probably I will have more plans than time, just like the years before…

Let me wish everybody a Merry Christmas and a happy 2009 already.

The tool I should have made earlier

I think it was more than a year ago. Nick asked me if I would make a tool and my answer was that it was not necesairy because the tweak only involved a few easy lines of ASM code. Yesterday I started making a tool for this simple tweak, plus some other features. What am I talking about? Ground polygons. If you look at the forums they remain a hot issue all the time. Having to use the FS2002 gamepack, having to tweak the ASM code by hand.

So now I started working on a tool that I called GroundPolygonAssistent. It will help you to do the following things:

  • Tweak the ASM code of ground polygons to make them proper ground polygons
  • Combine different layers of ground polygons in one BGL file
  • Split the polygons if they are bigger than a certain size, this can be useful for FSX, where they have to be smaller than 100 meter to work correctly with the curvation of the earth
  • Output the polygons with different reference points, this can be useful for big airports where accuracy errors occur at big distances from the reference point and it can also increase the overall performance a bit
  • Reproject the polygons, sometimes the data might be in a different projection than the flat earth one used by FS for its XYZ coordinate system, in that case the tool will help you to keep the accuracy of your origional data

Below you see a first screenshot of the user interface. As the tool is not finished yet (actually the buttons have no functions yet at this moment), things might change a bit. I will keep you informed about the progress.

Why is the 3DS format giving me trouble?

Over the weekend I have been continuing with the ModelConverterX tool again. A while ago I improved the FSX MDL importer so that it could read levels of details and animations, but at that moment I did not update the different exporters to handle these more advanced features as well. So now I decided it was a good moment to address these issues. I should mention right away that getting animations to work in the exporter is a step that I did not try to take yet, now I focussed on getting the static transformations and the levels of detail right.

For the X file exporter, which is used to make FS2004 and FSX MDL files, it was relatively easy to add the support for these features. And also for the OpenFlight exporter it did not give me too much trouble. I was actually quite pleased to see that my translation from the FSX level of detail numbers to distances, as used in the OpenFlight file format, worked out very well. After I loaded the object with the OSG viewer, the transition between the different levels of detail was very smooth. So that indicates the distances were choosen quite well.

But for the 3DS file format things were not as easy unfortunately. The more I look at that format, the more I start to wonder why it is used so much to interchange models between different formats. I know the answer in this case is that 3DS is the only format GMax can import, so that is why I am bothering myself with trying to implement it. But the format has some quite annoying drawbacks. The texture names in the materials can only be in the old 8.3 format from the DOS days for example and not so many people seem to restrict themself to using only eight characters at the moment. Another annoying one is that the part names can only be 10 characters. Giving the fact that FS uses a LOD naming schema like _LOD_100 you can do the math yourself to figure out how much characters are left to name the part apart from the LOD part.

But the good news in the end is that I also got the 3DS exporter to work relatively well, considering all these limitations. Now the next item on my todo list is to look at the code to automatically generate lower detail version of your model for the levels of detail.

Back from London

Yesterday I visited the ESP Developers Conference in London and I must say that it was very interesting. Being active for a long time in the FS community already the overviews of the SDKs and the basics of extending ESP did not provide much new things to me. But especially for the panel and gauge side, which is not my area of expertise, I did learn some new and interesting stuff.

But the main part that made the conference interesting was meeting the other people there. For example it was nice to meet Todd Landstad from ACES, after talking with him earlier this year when I gave a presentation about ESP on the Dutch DevDays. Fellow MVP Lefteris Kalamaris was also there and a lot of other people as well, but if you don’t mind I won’t mention them all.

A third aspect that made it a good trip for me, was that it gave me a lot of new ideas for possible future developments. But I will blog about those when they have turned into more concrete plans.