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.

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.