I want to start with a little warning. I am afraid this post is going to be rather long, so if you are already desperately in need of coffee now, you’d better get a cup before reading the rest of this.

So what is this OpenFlight you are talking about you might think? OpenFlight is not some sort of open source Flight Simulator or so. No it is a very common format to store your scenery in, for professional flight simulators. In this article I want to talk about the similarities between this format and the BGL format of Flight Simulator. And also about my attempts to make a converter between the two formats. Let’s get started.

The OpenFlight format has been create by MultiGen-Paradigm and is very common in real flightsimulators. At work we also make use of this format to store our visual databases (or scenery as most of you will know it). Rather soon after I started on my job, I had to learn more about the OpenFlight format, as I wanted to create a few tools to make our work easier. As I can almost dream the FS BGL/MDL format by now, it was rather logical that I compared this new format for me to what I knew. Slightly to my surprise a lot of things are almost the same. All materials are defined with the same properties (diffuse, ambient, specular and emissive colors for example) and the way to to store vertices and create triangles using them is also very similar.

The biggest difference for me was, that the OpenFlight format is a sort of a database. So each polygon has a few vertex nodes as children. And as a parent the polygon node can for example have a group, object or LOD node. This makes the structure of your object a lot clearer. A downside of this, is that the file format itself takes more diskspace. While learning about OpenFlight, I started to understand that MS has chosen a nice compact format to store the objects in.

There is another difference I should note. When I am talking about FS BGL/MDL files, I am talking about the object files mainly. The terrain has its own BGL format in FS, which has its own logic. In the OpenFlight format we usually create an entire database in one file (or a set of files that are linked together). So you have terrain, roads, 3D objects, airport all defined in the same file. As a result of this, the structure of your file is much more important, when trying to optimize your scenery. In FS scenery the MDL files usually contain only one object, so that makes their structure less important. All the placement is done with different (XML based) code and that has its own logic and structure again (I won’t start to talk about that as well here).

At work we were working on a database for Schiphol, the airport of Amsterdam. And because I had already created a FS scenery for this airport (as part of the NL2000 scenery team), the question soon came if we could not convert some of those 3D objects for use in the real flight simulator. One of the other NL2000 members had already created a converter the could create OpenFlight files from SCASM source code. But as we had created these objects with Fs2004 MDL files, they could not be decompiled to SCASM code. I had also started with the new version of my MDL Tweaker tool (which contains a nice MDL loader) at that moment, I decided that it would be cool if I could also add an OpenFlight export function to it.

In theory this conversion is not that hard. You have an object, that contains of a collection of vertices, materials, textures and triangles and you need to read the MDL format and write the geometry to the OpenFlight format. And the logic behind the conversion was indeed finished rather soon. But then the trouble started for me. I had to code this logic. The API provided with the OpenFlight format provides functions to create an OpenFlight file, but unfortunately for me these are in C++. And because I still need to find an easy way to create a nice GUI in C++, I am coding my MDL Tweaker project in Visual Basic.

So I first tried to use the functions of this API in Visual Basic. I won’t bother you with all technical details, but it proved to be more difficult then I had expected. Either the export function worked correctly, but crashed on big MDL files, or it worked on big files, but the properties in the OpenFlight format were not set correctly. So a few days ago, I decided that it would be easier if I wrote directly to the binary OpenFlight format from MDL Tweaker. A good discription of this binary format is luckily available.

So just this evening, I was able to finish that part of MDL Tweaker and the good news is that now everything works fine. So I can create OpenFlight files from my MDL scenery objects created with GMax. Now you also know the reason for the delay of a new alpha version of MDL Tweaker. The last few weeks I have mainly been busy to implement this new function (I could not accept that it did not work as I wanted).

After reading all this, you might think what can I do with all this? The answer for most of you is probably that the OpenFlight format is not of very much use to you. But if you want to play with it a little bit, I would advice you to give OpenSceneGraph a try. The OSGViewer that comes with OpenSceneGraph is able to load OpenFlight (FLT) files. So after I have released the next alpha version of MDL Tweaker, you can view your own objects in the OpenFlight format is you ever wish to do so :).