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.

Reading of textures

A little while ago I already wrote about the fact that I was working on my own texture loaders for the ModelConverterX tool. I have now finished the first versions of the loaders I find most important for the tool. I say first, as I am sure some bugs will be surfacing when they are used by more users. So I have now made loaders for the DDS, BMP and R8 format.

The DDS format is common in FSX and I can now read DXT1, DXT3 and DXT5 variants. Figuring out what their difference on the binary level are was very interesting to understand how the compression of those files work by the way. I think I should make a little Wiki or blog article about the things I learned, as that would help a lot of other users as well in understanding which format to choose in which case.

For the BMP format I can read the normal 8, 24 and 32 bit BMP files, but also the ones with DXT compression that were used in previous version of Flight Simulator. I am sure there are some other compressions that are sometimes used for FS as well, but I did not yet encounter these in my own collection of test models.

Finally there is the R8 format. If you still remember these textures you are around for a while, as it is the format used by FS5. Basically it is a RAW file with indices into the FS5 colour palette. A wide range of extensions was used for these textures, not only R8, but also PAT, 0AF, 1AF, …, or any other extension the designer could think of. I can now read those textures in ModelConverterX and display them in the preview for old API macros that still use them. Maybe it would be a good idea to convert these old textures to a more modern format when you export to FSX MDL again.

So that is an update on my texture reading progress, I am now looking forward to tackle some of the other wishes still on my wishlist for the next version.

FSDeveloper site is down

While the flu kept me in my bed, it seems something else also affected the webserver of the FSDeveloper website. I just noticed it today when I sat behind my computer again and I have informed support about it. So hopefully the site will be running soon again. As this kind of problems seem to happen semi-regular we will already try to investigate the sources of it.

But if you excuse me now, I will retreat from the PC back into the bed, as I am not fully recovered yet.

EDIT: By now the site is up and running again.

Ground polygon tutorial

Making ground polygons with GMax always seems to be a hot issue, especially the fact that you have to use the FS2002 gamepack and apply some tweaks to make things work. So this challenging part of scenery design gets discussed a lot on the forums. But now there is a new tutorial that might help you. In it Bill Womack explains how he made the runway for his Plum Island scenery. So have a look at this nice tutorial.

Public transport

First, sorry for this rant, but at the moment I am just to annoyed by it.

Since a few moments the public transport company of Amsterdam already decided to make it more difficult for me to get to work. They are renovating some stations, including the one I have to depart from. To make that work easier they decided to cancel half of the metros (including the one I have to take of course), forcing me to change metros at another station.

That alone is something that I have to accept of course, but this week it seems they are really messing things up. There hasn’t been a day yet this week that the metros that are still running didn’t have an extra delay or one of them was cancelled as well. So I am getting used now to spend quite long every morning on the platform, hoping that a metro will arrive soon.

Would this be their revenge for the fact that I bought a car recently? Who knows, at least I am counting down the days that I still have to travel by metro to work every day. Soon I will be joining the traffic jam on the highway in the morning…

Texture file formats

Loading the textures files into the ModelConverterX tool is something that has given me quite some challenges already. I have used different libraries for it already and all of them gave me some trouble. At the moment I am using the library by Martin Wright and although this one can read all the files I want, it is not a very fast library. So this makes the loading of models relatively slow.

That is why I decided to have a look at how the different texture formats exactly work and see if I could create my own texture file loaders. At the moment I have been studying the BMP and DDS formats. Creating a loader for those formats was not so hard, so at the moment I can read these formats. This should allow loading most of the texture formats used by Flight Simulator.

Only the R8 format is still on my todo list, as this is still used by older API macros that the tool should be able to convert. Maybe it is a good idea then to convert the textures to the DDS format when exporting to FSX MDL files.

I still have to test my new loaders with some more models, to see if there are not some “exotic” variants in use that I can not yet read at the moment. But all together it has been quite interesting to study those formats and gave me a lot of useful background information on how they work.