Optimize it!

A while ago I made a post about the differences when creating MDL files with GMax or FSDS3. But when I looked again at this problem recently, it seemed to be a little different than I wrote back then.

It’s not the X file that FSDS3 creates that causes the different MDL file, it turned out that FSDS3 uses MakeMDL without the optimize option turned on. As soon as you compile the X file manually with that option turned on, the code of the generated MDL file looks a lot better already. As the name already suggests, the optimize option optimizes your code. This for example means that transformations are only used when needed and all polygons with the some material and texture are put together.

This not only has a positive effect on the performance (although it might be small for simple objects), it also means that you can better tweak the MDL file afterwards. The non-optimized code, for example can not be tweaked afterwards to let the object rotate to the user. This is because of the extra transformation matrices put in, that are not affected by the rotation command.

I do not understand yet why the optimize flag is not used by FSDS3. It is on by default in MakeMDL. But even when I force it on with the makemdl.cfg file in the same folder as my MakeMDL copy, FSDS3 does not seem to use that option. Maybe it is putting its own setting in somewhere, but I could not figure that out yet. Maybe a “heavy” FSDS3 user can help us here. Until then, it seems best to save the X file from FSDS3 and compile it manually with MakeMDL. This also explains why the problem with moved parts on FSDS3 MDL files is solved when you compile the X file manually. That is due to the optimize option as well.

LiveMeeting – part 3

Tonight was the night. We had our first LiveMeeting about scenery design for FS. As a subject for this first meeting we had chosen the MDL Tweaker II tool. Mainly because it is a new and interested tool that we wanted to show more about. And also because it was an easy enough subject for a first meeting.

I think about about 5 people had turned up for this meeting, not a very huge amount, but enough for a first trial. And as things went rather well, we will announce the next meetings more widely so that other designers can join as well. As I said, it went quite well and hopefully the participants have also learned a little more about the MDL Tweaker tool and what it can do for them.

Of course there are always a few things that do not go as planned. The first being that I returned home a little late and had to rush into the meeting. Which of course gave trouble when I had to dial in on the phone for the voice. After that I also discovered a few new bugs while giving a demo of the tool. Not really what you hope for during a demo, but at least it is now clear that the tool is still in a beta phase. And it also had the positive effect that I have already solved a few of these bugs by now.

Based on the feedback of the participants we will be planning a new meeting. Things we have to look at are mainly the communication. I am not sure if the question manager was enough to get really interactive, maybe all participants need to have voice. But in that case you have the risk of them all talking through each other. Well that will be something to think about.

For me it was fun to do this LiveMeeting and show what the tool can do. Hopefully the participants also enjoyed it and I am sure we will be back with more meetings on interesting scenery design subjects. Stay tuned…

AGNIS/PAPA docking system

Today (or actually I should say last night I think), I finally found the time to finish the AGNIS/PAPA docking system I was working on. For those not familair with this system, it contains of two unit. One is the azimuth display that shows if the pilot is lined up with the leadin line correctly. If he is two green lights show and when he gets to far of the center the light on that side will turn red. So all the pilot has to do is keep two green lights. To determine the stop distance there is a stop sign besides the azimuth display. On this sign lines are drawn for different aircraft types and there is a bar in front of this sign. When the bar shows exactly in front of the line for your aircraft type, you have reached your stopping point.

The azimuth sign was not really hard to design for FS. As it only needs to respond to your position compared to the leadin line, it is not very complex. But creating the stop sign was a little more tricky. I already made my life a little easier by only using one stop point for all aircraft types (all docking systems I have made use this assumption, making the stopping distance dependant on the aircraft type as well, would almost mean that I need to make one model for each gate stand, as they are all slightly different). But how to get the bar show correctly in front of the line on the texture? In the end I have made the position of the bar variable, so that I can set it from the VGDS Tweaker tool. You enter the stop distance and the lateral offset from the leadin line in the tool and it then calculates the correct position of the bar for you. Below you find a screenshot of the system as using in the Schiphol scenery I am working on.

The system shown on the screenshot is mounted on the terminal wall, but there are also systems at Schiphol that are placed on the apron and are thus mounted on a pole. I am going to make this variant as well. And once that one is done as well and everything has been tested properly, you can expect a new release of VGDS Tweaker, containing the AGNIS/PAPA system as well.

LiveMeeting – part 2

About a week of two ago, Nick and I played a little bit with Microsoft Office LiveMeeting. Back then we saw a potential to use this technique for some online, interactive tutorials as well. So tonight we did another test and this time Thorsten joined in as well to see how well everything worked from the perspective of a normal user.

In the beginning we had some trouble to get all the audio working correctly. For example when using the webclient, it seemed not possible to listen to the broadcasted audio. So it took us some time before we could all three hear each other and see the desktop being shared for the tutorial. But once that was working, we tried different kind of tutorials to see how looked to the other attendees. Like showing doing animations in GMax or using the CAT tool.

In the end it was a really useful session (and also a lot of fun I must say) and we learned some useful things we can use for the real LiveMeeting tutorial as well. One thing we learned is that the GMax screen might be too complex to use for a first LiveMeeting tutorial, so we decided that the first meeting will be about the MDL Tweaker II tool and it is scheduled for Thursday 27th July at 21:00 CET now. So we hope to see you there then.

Back in my computer room

A few weeks ago I wrote my shower leaking a little water and that my
room where I have my computers was in danger of getting a little wet.
So since then my house has been a sort of a mess, with books piled up
all over my living room and bedroom and with the computer standing on
the dinning table.

In the mean time I let the computer room dry up and replaced the
sealant of the shower. But the carpet and the wallpaper did not look
very nice anymore after drying up, so with some help from my father we
replaced these two today.

This means that I can finally move all my stuff back into the room and
have my usual desk again for all my computer/scenery design work. At
the moment I am still putting all my books back, etc. But in a day or
so I should be fully running again (and the dinning table will be
available again to eat from).

Log it!

There is a new feature in the latest MDL Tweaker II release that I did not yet point out. This new feature is the event log screen. When there is a warning or an error this will be the place to look for the message.

The image above shows three warnings for missing textures. So whenever your preview seems to miss some textures, have a look at the Event log first to see if there were problems loading them. You can find the Event log in the Window menu.

To be honest, at the moment the warnings for missing textures are the only ones written to the event log, but in the future other messages will be placed here as well. For example about tweaks you have applied or problems that happened when applying them. I do plan to make the event log appear automatically when an error occurs, while you should open it manually for warnings. But that is something for the future, for now if you miss textures, check the log.

Complex conditions

Last weekend I released a new version of MDL Tweaker II and in this blog post I want to point out a few of the improvements of this version. The feature that has been improved most is the condition manager. Not only has the user interface changed, hopefully it is even easier to use now, but also the types of conditions you can apply has been extended. In the previous version multiple conditions on the same object always meant that all these conditions had to be true, for the object to display. But this new version does also allow other combinations of multiple conditions. For example one of the conditions must be true, none of the conditions must be true, or one of the conditions must not be true.

This can for example be useful if you want to display an object between minute 45 and 15 of the hour. As this passes the 60 minute border, this condition would become either the minute is between 45 and 60 OR it is between 0 and 15. With the new condition manager that is now possible.

Another nice improvement is the preview window. Instead of using buttons to zoom, there is now a slider where you can set the amount of zoom. This should be a lot easier to use (in the end I would prefer to use the mousewheel for the zoom, but at the moment trying to get that to work makes the tool just to unstable). And another improvement of the preview is the overal speed of drawing it. In the previous version this was often CPU limited, while I have now optimized the OpenGL code more. So it should no longer eat all your CPU and rotations of complex objects go more smooth.

With all those improvements done, I hope to be able to put some effort in reading transformations and animations now, as that is an important area that MDL Tweaker can not yet read. Once I have some progress on that, you’ll certainly read it here again.

Awesome

I would like to point your attention to cool OpenSource project this time, OSSIM. At work we make use of this tool to mosaic different aerial images for example. But it can do a lot other image manipulating related tasks as well, like color matches between different images or reprojecting images to a different projection. So have a look at this awesome tool.

While reading the manual of OSSIM, I noticed that it should also be able to do image tiling. This could be a useful feature when trying to make the tiles for a high resolution ground layout. But I haven’t been able to get that feature working completely, I’ll make a new post about this once I got it fully working.