Apron markings preview

A few days ago I posted about the apron markings I was working on and it works out quite nice I must say. For example, the performance has increased compared to the previous markings that were placed with Fs2000 style roads. And due to the way I generate these polygons now, the connection between the different line segments is also better (no gaps anymore).

Below you find two screenshots of these markings, to show you all what I am talking about. This is not yet the final version, as I still need to optimize things like the line width and the visibility range.

A new home for my blog

As you can see my blog has moved to a different server, thanks to Nick for setting this up. At the moment it is rather empty in here, so I guess I need to move the content to this new home as well. So please check back later.

Edit: All posts have been moved to here now. Only the comments seem to be a little hard to move from the old blog, so they are probably lost. All I have to do now is to setup the links, etc and everything is fine again.

Edit2: The links have been added again as well. So it seems the move is done now. If you find anything weird or not working, please let me know.

Markings

It has been a little quite here lately, but that does not mean I am not doing anything. So time for a little update. Apart from the fact that I have been away for a few days for work (attended a workshop in Engeland), I have also been working on the apron markings for the Schiphol scenery. Let me start with a little introduction on what we want to achieve in that scenery.

We want realistic markings, so that means we need more than only a yellow center line. We also need the red clearance lines for example or the white tow lines. And as the cream on the pudding we would also like to put in the road markings on the airside of the airfield (these will probably be optional, to keep the users with a not so fast PC happy as well). As we want more than only some yellow markings, it is clear that the XML options to place markings are not sufficient for use. Although I hope that in the future these XML markings will become more flexible, so that they allow those red lines and other cool stuff as well.

Another things that I should probably mention, is that we have been lucky to receive some data about which markings are where. That means that we do not have to draw them all by hand, but that we can use this data and convert it to some scenery. In the past I have made a converter for this and it created Fs2000 style roads for the apron markings. I used these as they are the easiest way to place lines with a certain width in the scenery and assign your own custom texture to it. But they also have a few downsides (of course). For example they are not floating point, so to prevent gaps between them you should use a rather small scale of the reference point. And another negative point seems that they are a little heavy on the frames if you use a lot of them. And I can assure we use them a lot, as there are a couple of ten thousand line segments on the airfield.

So now I have been trying to upgrade the converter a little bit and produce these markings in another few. And until now that is working out quite nice. Instead of placing all the markings as narrow roads, I am now drawing them as polygons using the floating point commands (like the Fs2002 GMax gamepack output for ground polygons, but then created by my own tool). The main advantage of this is that it seems to be better for the performance and also it makes it slightly easier to connect all the lines nicely together without gaps. To generate these polygons from the line data I am using the OGR library I talked about before. With this library I am merging all line segments in a certain area together and I then give this total line a buffer (so a width around it). The advantage of this method is that as all lines are first put together, the connections between the different segments are almost perfect. And luckily the library does most of the hard work for me.

I will try to post a few comparison images in the coming days, when I continue to test my new tool.

FsX video

This might be old news already for those hanging around the forums a lot, but there is a nice preview movie of FsX. I think it shows quite some very impressive scenery features. Can’t wait to use these in my addons…

GMax, FSDS3 and MakeMDL

With both GMax and FSDS3 now using MakeMDL to create the scenery MDL object, you would expect that the resulting code of these objects would be very similar, but while testing the output of both programs with some of my tools, it appears that this is not really the case.

Let me start by saying that I do not want to compare the features of GMax and FSDS3 here. Some users prefer the user interface of FSDS3, while others like the one of GMax. I want to discuss the differences in the code of the objects that are generated in the end.

As you might have guessed from my introduction, the created MDL files by GMax and FSDS are not as similiar as I had expected. Although there are some options on the MakeMDL GUI, it seems that not all logic to optimize the object is in MakeMDL itself. The tool that creates the X file for MakeMDL has to do part of the logic as well. So let me give you a few examples of differences.

When you create different objects in one scene, but they all use the same texture, GMax will optimize all these polygons into one list and thus only set that texture once. FSDS3 on the other hand does not do that and will set the texture again for each object (even though it might still be the active texture).

Another example is when you move an object in the design program. In GMax objects this movement will be taken into account when calculating the vertex list, while FSDS3 does use the vertices relative to the local object of that part. So an actual translation command is used in the MDL object to move it to the correct location again.

It looks to me as the GMax X files have been optimized better. Applying transformations that are static into the vertex coordinates seems a useful way to take as much calculations away from the scenery engine as possible.  And sorting polygons on the material or texture used, also seems a logical way to keep the amount of state changes as low as possible.

As most of my tools have been develloped and tested using GMax output files, it seems I will have some nice challenges to fix some bugs with FSDS3 objects and make the code general enough to read any MDL object.

Project management

This time I want to talk about something different than cool new techniques or tools. I would like to discuss the way I prefer to manage my scenery projects.

I think you will all know that you can generate quite a few (source) files when creating a scenery. And when you can keep them well organized it makes your work a lot easier. This became especially important for me, when we started to work together on the same airport with different designers in the NL2000 team. We started to use a CVS system to synchronise the sources between those different designers and to work with CVS easily we came up with a common project structure we now all use.

The first step is obviously to create a folder for our new scenery project. This can either be a airport or an object library or something else. In this base folder we have three folder:

scenery
texture
source

The scenery folder is clear of course, here all the final BGL files will be placed. And in the texture folder the DXT mipmapped versions of all textures are placed. By adding this base folder to the scenery library in FS, it is also very easy to have a look at your work in progress.

The source folder contains different subfolders again, for all sort of sources that you get. A few examples are:

asm
xml
gmax
mdl
texture
sca

This are just a few common ones, but depending on the files I collect during a project there can be others of course. The ASM folder would for example contain the ASM source files that have been tweaked manually, while all normally exported objects go into the MDL folder. The XML folder contains the source files for the object library of this project and also for the XML file used to place the objects for example. The texture folder contains the sources of the textures. Usually we use the Photoshop PSD format for that, as that allows you to store layers and stuff like that. ImageTool can then process these files into DXT BMP files easily.

With the help of a few BAT files to easily convert textures and tool like Library Creator XML and ObPlacer XML, I find this a very efficient and organized way to work.

Encarta Instant Answers

Today we celebrate Queens day here in the Netherlands. Actually it is kind of confusing as it is supposed to be tomorrow, but as that is a sunday so they moved it one day ahead. And now to confuse you foreigners even more, tomorrow is not even the birthday of our current queen, it is the birthday of the previous queen. The current queen has her birthday in January, which is probably not the best season to have a public holiday.

But enough for this introduction,  I don’t know why, but I was playing with the Encarta Instant Answers a little bit and I though I would ask it who our current queen is. I must say the answer is a little surprising:

Encarta® Instant Answers: I don’t know about the Queen of the Netherlands, but I do know that the ruler of the Netherlands is German occupation.

Did I miss something? Have the Germans been ruling us all the time without us noticing it? Our royal family is German of course, if you go back long enough in time, but I think Encarta Instant Answers has been mixing up some articles about the Netherlands and the Second World War here.

The math of the gate

I have been able to create some nice mathematical formulas that describe the end position of the gate, based extension length and the different heading and pitch angles. Of course these equations are rather complex, with a lot of sine and cosine functions, so that makes them hard to solve by hand. So I think to do it with some smart computer program and that sort of works. But unfortunately this set of equations does not have a single solution, so a simple answer was not possible.

The next step I took is to implement these equations in a little tool that just tries to find the closest answer by trying a lot of different angles, etc. This worked rather well (and also rather fast), so I will be using this approximation for my gates later on.

Now the next step is to put some data for different aircraft types in the equations and see if I can create proper animations from that. I will be giving that a try over the next few days, but I think this is going to work fine.

Wireless trouble

The last few days my wireless connection seems to be a bit unrealiable. Every few minutes the connection drops and it takes a while to reconnect. So until I have figured out what causes this, expect me to be online a bit less (especially on MSN).

Some more animation tricks

To some of you it might seem that I only hang around forums and create new tools, but sometimes I also work on some actual scenery. I do that as part of the NL2000 team. For the Schiphol scenery I have been working on the animated gates the last week and this gave me a good chance to test some new animation ideas I had.

These gates will use the ActiGate module to show different animations based on the aircraft type you use. I know Nick has been working on the same for his Shannon scenery and he has made all the animations in GMax. But for Schiphol this was not really something I was looking forward to. The reason is that while Shannon has 1 type of gate, Schiphol has three different types. And to make things worse, not all positions where these types are used have the same layout. So that would mean I would have to make a load of different animations, based on parking position, gate type and aircraft type. I am just too lazy to do that.

So I came up with a new idea. If I know the distance of the aircraft door from the stoppoint of the gate, then with some “simple” mathematical formulas it is possible to determine the animation matrices, based on the layout of that specific gate. So this way I only have to collect this aircraft related data and after that enter a few parameters for each gate (like relative position of the stoppoint from the origin of the gate model). I have already tested the ASM coding need to get this working, now the only thing I have to do is to finish the math and implement it in some sort of tool (unfortunately the math you can do in BGLC itself is so limited, that it will not be enough).

While doing this, I also tested an coding idea I had for quite some time already. This is to do the condition checking at a different location in the source code. The advantage of this new location is that animations used for attachpoints can also be affected by the condition and besides that it means less code tweaking in other sections. The downside is that you are a bit more limited in the commands you can use to perform the condition check, but it seems I have it all working now (after a few crashes of FS).

So once I have finished these gates, I will hopefully have some time to make a few articles or tutorials about the new things I have found. And after that CAT deserves an update as well of course. But I don’t expect I have time for that very soon.