Another LiveMeeting

After the success of the first SceneryDesign.org LiveMeeting, we have now scheduled a second one. Where the first LiveMeeting was a short of online-video-tutorial-demonstration of the MDL Tweaker II tool, this second meeting will go a little more deeply into the techniques of scenery design. The subject will be how you can use XML for your 3D object design. So we will discuss things like how to place a MDL object using XML code or how to make an object library with the XML code. But the meeting will not only consist of boring source code and XML files (although I think it is important that you understand the basics of the underlaying XML format), we will also demonstrate some tools that can make your life easier and create the XML files for you. So if you want to know more about this, check the announcement on the forums!

ObPlacer XML and Rwy12 object libraries

After the release of EZ-Scenery, I have made a few posts on this blog about the object library mania that occured back then. As people tried to convert Rwy12 library into EZ-Scenery libraries, while they are actually almost the same (only the way the information about the library is read into the tool is different). In principle any object library made with the Fs2004 XML scenery format, should work fine with any of the object placement tools made for this XML format.

So, how about ObPlacer XML you might be thinking. That tool uses a different way to read the information about the library. While EZ-Scenery reads the information directly from the binary BGL file, Rwy12 uses its own XML format to store the information about names, GUIDs, etc. And ObPlacer XML reads the BGLComp XML files that you can also use to compile the library BGL. All those different formats can become rather confusing to the new users.

But I have now added a new feature to ObPlacer XML to make the life of the designer a little easier. ObPlacer XML can now also read the Rwy12 XML format, so that means you can now add libraries that have been released for Rwy12 easier to ObPlacer XML as well. So you know have the choice to either load a BGLComp XML file or a Rwy12 XML file to let ObPlacer XML now about the object library.

There are a few things I still need to finish, but I will try to release this new version within the coming days. And yes, I have also fixed the bug about the mixed up texture coordinates in the generic building preview.

A slow MDL Tweaker

About a week ago I received a message on the forum that MDL Tweaker crashed on a certain object. After the designer of the object send me his MDL file, I soon figured out why it crashed. This was simply the most complex object I had ever tried to load into MDL Tweaker and a few integers had an overflow because the object had more than 32768 vertices. This was not that hard to fix of course, I just had to make sure that these big integers were read correctly.

But after I had fixed the errors, MDL Tweaker did not behave as before. It was now possible to load the object, but it took a very long time to do so. I thought I had tried to load quite complex objects before, but this one was of a different order (the MDL file is over 1 MB in size). After I while I found out that the internal way I store the MDL object (using collections to store lists of vertices, BGL commands, etc) is not very efficient when these lists grow very long.

This weekend I was visiting my parents. Being away from the internet, that also meant that I could work quitely on an improved version of MDL Tweaker (the train journey also proved to be a good place to work). So I have now tried to make the preview as fast as possible and to prevent people from thinking the tool is no longer responding, I also added a screen that shows the loading progress while you open a MDL file. For a complex object, like the one I described above, the loading can still take a few minutes. But I don’t know if I can find an easy solution for that problem.

I have tried to put most code that takes a lot of time together when you first load the object. So that once it is loaded, the tool works as fast as possible. But unfortunately this is not possible everywhere. Some forms need to collect some information about the object when they are loaded and iterating through the object in memory takes some time on big objects. So in those cases you will have to be patient and don’t think the tool has crashed.

I have now almost finished a new version of MDL Tweaker, so it will be released in a few days. Besides fixing the crash I mentioned and improving the loading of the object, there are some other small improvements. For example you can now select vertices in the vertex list based on the texture applied to them. So this makes it easier to select all vertices that belong to your trees for example (so that you can unify there normals).

Running a forum

I have been running the SceneryDesign.org forums for about 3 years now and I must say that a lot has changed over these years. When I started the site, I was looking for a place to store the tips and tricks I had on my personal homepage. And I added the forum to see if a place to discuss scenery design related topics would be useful as well. By now I think we can say that the forum has been found useful by the visitors. There is a base of regular visitors and a lot of designers know to find the forum with their design problems.

But unfortunately this popularity of the site also seems to have a downside. Lately I am getting a lot of fake registrations from people (or I guess it are actually bots, as they all select the first country in the list when registering, with happens to be Afganistan) using emails addresses that do not exist. Luckily this only generate some emails with errors for me and now and then I do clean those accounts that never get activated.

But the last few days it seems some of them actually take the effort to activate their account properly and start posting spam on the forums. These spam posts only happened in the News forum until now and that forum us moderated, so that prevents them from being visible right away. Hopefully the spam with not spread into the other subforums.

I guess the future will learn if this problems keeps increasing or dies again. Until now it is manageable or else I might have to look for some extra moderators to help in cleaning the forums.

Of course trouble like this never take away the fun of running the forums. All the interesting discussions going on are a good source of inspiration for new ideas and techniques. And of course helping a new scenery designer to find his way into this great hobby is also a nice thing to do.

Back home

I am back home and had a great vacation on Corsica. It is a really nice island to cycle around (although we only saw the northern part of it), with a lot of nice hills and mountains to climb. And every time a fantastic view on the landscape and the sea.

So now that I am back I am trying to catch up with everything I missed. An interesting FsX demo seems to be one of those things.

Ready to go…

It is summer again, so that means it is also time for a vacation. The next three weeks I am free from work and tomorrow my two week vacation to Corsica starts. I have booked a group travel and we’ll be cycling around the northern part of the island. Luckily I will not have to carry all my stuff (like a tent, sleeping bag, etc) on the bicycle as well, the group leader will carry that for us with a van.

I am really looking forward to this vacation. It is very nice to be totally away from work and computers for two weeks. I find it very relaxing to cycle around, enjoy the landscape, the food, the weather, etc. Of course cycling in a country that is not as flat as the Netherlands will be more tiring, but that is part of the fun. At least you have a nice view when you have climbed a hill or mountain.

I am sure I’ll meet some nice people again in the group and I will have a good time. So see you again in two weeks time and in the mean time I won’t see a computer, so I will not post anything or read any emails.

The image below is from last year, when I cycled in Navara (Spain).

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.