Away…

Next week I will be attending the Flight and Ground Simulation Update 2006 at the university of Binghampton (NY). I am really looking forward to this course, that I will attend for my work. While I am on the other side of the Atlantic I am also going to spend two weekends over there as a sort of short holiday (going to visit New York for example). So don’t expect any new blog posts during that period.

Once I am back, I am sure that I have some interesting things to post about. Maybe I can even apply some of the things I am going to learn at my FS scenery design activities.

Object library mania

Since the release of EZ-Scenery I have seen quite a few discussion of people who asked if they could convert a Rwy12 library into a library for EZ-Scenery. Or I read about other people who started to decompile object libraries, so that they could create a EZ-Scenery library using the supplied library manager.

I find this a worrying development. EZ-Scenery is a wonderful tool, that allows someone who is not a hardcore scenery designer to place a few objects on his local airport very easily. But when those people start to decompile other libraries, it is very easy to create a complete chaos. Without knowing it, you could easily end up with the same object getting a lot of different GUIDs. You might even have the distribute different libraries with the same objects, because you chose the from library. This is certainly not the point of an object library. So therefore I want to make a few things about a library very clear:

  • An object library is an object library. There is not something like an EZ-Scenery library and a Rwy12 library. They are all the same. The only difference is that there are object libraries in the pre-Fs2004 format and in the Fs2004 (XML) format. But most modern programs (like Rwy12, EZ-Scenery, ObPlacer XML) use the Fs2004 format.
  • The purpose of an object library is that you have a collection of scenery objects, that can be used by any scenery. Just make sure that the user has all the required libraries installed.
  • Although it is very easy to extract a MDL object from a library and use them again in a different one, this is not something to encourage. Most scenery designers will see this as violating their copyright! So just ask your end users to install the same libraries you have installed and don’t start stealing stuff.

I know there are some differences in how the different placement tool use the object library. EZ-Scenery for example reads your scenery library and shows you all object libraries that are available. Rwy12 requires a special XML file that specifies which objects are available, while ObPlacer XML uses the XML source used when the library was created. But in the end they are all able to use the same object library. I really hope that we will see more general object libraries in the future, instead of libraries for Rwy12 or EZ-Scenery. It is time that people start to see they are all the same…

How to crash FS

I think every scenery designer will know how to do this. Just do something slightly wrong in your addon BGL file and FS will clearly tell you it does not like your new file. Especially when you start to tweak the ASM or SCASM source codes manual it is very easy to do something wrong.

But while working on MDL Tweaker II last evening I was able to make it crash even better. As you might know MDL Tweaker II does edit the MDL files directly, so I am writing the binary code to it directly. And while testing the feature to add conditions I by accident made a jump that jumped ahead 0 bytes. So it would jump to itself, and then jump again to itself, and then… Well I guess you can guess where this ends. FS clearly did not like this new MDL file (although BGLComp did not complain during compilation). Once I fired up Fs2004 the loading screen showed up for a little while and then I was back at my desktop, without any error or warning.

Now I understand a bit better why MS does not very actively encourage this kind of object tweaking. The chances that you make an error are quite large and their support will not appreciate problems like this as well. But that is no problem for me, I have already accepted that most of the crashes I get here are caused by myself. That is just the price you have to pay, when you try to extend the use of your scenery.

How about some presents from Santa?

Are you all anxiously waiting for you presents from Santa? I am not, as here in the Netherlands Santa is usually called Sinterklaas and already comes at the beginning of December (this is a long story, but actually both are the same. You can read more about it on Wikipedia). But this interesting story is not really the reason of my post.

I do have a week off between Christmas and New Year, so I plan to play for Santa a little bit myself. I want to finish some work I have been doing on my tools. There are some versions that are almost ready for release, expect a few small details. And I hope to iron these out in these few days. Tools that come to my mind here are the docking systems for ActiGate, the updated ObPlacer XML, the Library Creator 1.03 manual, CAT and of course MDL Tweaker II.

Somehow I have the feeling that those few days off might not be enough, but we’ll see…

OpenFlight

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 :).

TerraVista

At work we use a tool called TerraVista to create the visual databases. This tool has some very interesting features, that are certainly part of my imaginary ultimate-scenery-design tool.

TerraVista for example allows you to import a lot of different data types. DEM altitude data, aerial or satelite photos, vector data for roads, etc. You can import them all, from a lot of different formats. If TerraVista knows the projection used in the data, it is able to combine them all for the project you are working on.

You can also determine rather flexibile how you want to use your data. Based on some attributes of your vector file, you can for example determine if it should be used to draw a road, a river or maybe a line of light poles. After you have defined these processing passes, the compiler takes care of the rest of the work, while it generates the visual database.

One of the things it can for example do during the generation is cut out different polygons. In Flight Simulator we are used to layer polygons if we have different ones on top of each other, but the Image Generator we use at work prefers to have only one polygon at a certain position. So TerraVista makes sure that the overlapping parts are cut away.

This is of course a very short discription of what the tool can do. It is so flexible that it sometimes even becomes hard to get something done, because you get lost in all the parameters that you can set.

But what about the ultimate-scenery-design tool? I would love to have a tool that I could provide with some altitude data, some photos, data for roads and that would then create the proper scenery files for me. Without me having to wonder about the LOD of the terrain and complicated things like that.

In that perfect imaginary world we would only need two kind of tools. One to design our 3D objects (GMax for example) and another tool that takes care of all the mesh and XML parts of the scenery. Maybe somebody would create that perfect tool in the future?

I know there are tools that can do part of this, but wouldn’t it be cool if we had all this in one tool? Especially for new designers it can be very frustrating to learn that they have to use yet another tool to get something done that sounds very simple at first.

As I design tools myself, I know how much work it would be to create a tool like this, that is powerfull on one hand and easy to use on the other hand. Maybe I can better keep dreaming…..

The projection hell

The different projection systems used in geographical data might be one of the aspects of MSFS scenery design that most designers know hardly anything about. But it surely a very important thing.

Almost each country has its own projection system and although most of these systems will give you the position in either degrees or meters, that does not mean that it will all fit together. So when using data to design your scenery it is a good idea to take a look at which projection system they use.

In the terrain SDK it is written that the MSFS mesh terrain uses the WGS84 projection system. But an interesting question remains which projection is used for the scenery objects (so the coordinates in meters you define in the MDL object file). As objects are in general small, the influence of the projection system will be a small, but it would still be interesting to know.

While working on my Dutch sceneries I first met all the trouble that different projections can give. We got some data that used the Dutch Rijksdriehoekscoordinaten system (the position is defined in meters from a church tower near the center of the country). But compared to the WGS84 projection system, the Dutch RD system also has an additional rotation of a few degrees. So when you think you can just use the position in meters, you end up with your scenery in the wrong location. In the end we luckily found a set of good formulas to do all the transformations to WGS84 and back.

Another example where you will meet different projection systems is when you use a background image in a program like Ground2k4 or SceneGenX. The mesh scenery and the XML style scenery are all defined in WGS84, but a lot of maps are in meters. So in that case you would have to reproject the image to get a perfect match. SBuilder is a tool that has added this reprojection functionality. If you do not take notice of this, you might be positioning your scenery at the wrong position, especially when you get further from the reference point.

For those that have become really enthousiastic about projection systems after reading this, take a look at the Proj4 library. With this library you can easily convert between almost any projection system. At work I have also used this library to build some conversion tools.

I’ve got my own blog

As you can see I do now also have my own blog. Welcome to all who have found it. Most will probably now me from my scenery design activities for Microsoft Flight Simulator. And as the name of my blog suggests I will post mainly about this subject as well. But that’s not all.

Let me start with a slightly longer introduction about myself. Besides MS Flight Simulator and especially the scenery design, I also have a big interest in aviation in general. That all started when my parents took me in a plane for the first time to go on vacation. I was 8 years old at the moment and since then I have been crazy of aircraft.

When I had to decide what I was going to study, the choice was not that hard to make. I was going to do Aerospace Engineering. During the study my interest in simulation grew stronger and in the end I graduated on the “force feedback” of the control column (which was a powerful hydraulic function in that simulator).

Shortly after my graduation, now almost a year ago, I started to work at the National Aerospace Laboratory (NLR), which is the Dutch aviation research laboratory. I do work at the simulation department and part of my job become to design the visual databases (that is how scenery is called in that world) for those simulators. Slightly to my surprise I found out that there are quite a few similarities the MSFS scenery and these visual databases. I will try to post some interesting things about this link between the MSFS “hobby” world and the “professional” flight simulation world on this blog as well.

That was about it for my first blog entry. I hope to see you back later, when I post most useful material.