Is it a gift to annoy people?

Over the last few days I found out that spammers have found a new way to annoy me. This time they are not spamming my blog or my email accounts (well, they are still spamming my email, but not more than usual). I noticed that on the Talk/Discussion pages of the FsDeveloper Wiki they have now started to post links to nonsense stuff.

Most of them don’t show up when you look at the page, but when you start to edit it you see the huge amount of links. I try to delete this stuff, but usually within 30 minutes they are back again. I’ll see how it develops in the next few days, but if the spam does not go away I guess the access to the Wiki needs to be restricted a bit. Like only allowing people who have registered to contribute. But if not needed, I would like to prevent such steps, as the Wiki should be as open to all users as possible. If we make it to hard people will not contribute that fast.
 

A nice morning GMax session

This morning I was chatting with [Nick] and it turned out that both of us had not been able to use the new FsX GMax gamepack as much as we would like to in the past weeks. So we decided to have a little session right away, while speaking to each other using Skype.

We went over some of the documentation, for example the documentation about the animated jetways and we exchanged some ideas on how we could use that on our own objects. And we also explored the new FlightSimX material type in more detail, to check all the cool options available on it.

But the most concrete result was that we also tested the platforms of the attachtool. Of course these work fine. But now the different types of platforms also work fine, while they did not in Fs2004. So if you set the type to GRAVEL you will see dust behind your aircraft, while there is none if you use the ASPHALT type. And when setting it to ICE you will certainly notice that the platform is more slippery.

In the end we both found it a very useful session, as it is a nice way to explore the new stuff and exchange ideas. Hopefully we have some time soon to do this again and I am sure we will be able to report over some interesting finds then.
 

Progress for today

As the screenshot of the new tool I posted earlier today is not that nice looking with all those weird colors, I thought it would be nice to post another one now at the end of my day to show you how far I have gotten.


 

As you can see the weird colors are gone now. This is because I have been able to figure out how to read most of the material information. So I can get the material color and texture now, just some of the more advanced material options I can’t get yet. At the moment I can’t read in the textures yet in the preview, although I can extract their names from the MDL file. That is why all textured parts show that checkerboard.

Besides that extra information can I can now read from the MDL file, I have also improved the preview picture in general, by applying the correct shading to all polygons and that short of stuff. So that all together makes it look more like a church now.

I will continue this weekend to see what other cool things I can read from the new MDL format and besides that I’ll also try to create a new page on the Wiki about this MDL format. So that other people can help with discovering it and don’t have to reinvent the same wheel again. 

Working on a new tool

The last few days I have been working on a new tool, it will be called ModelConverterX. In the end the purpose of this tool will be to allow you to convert 3D objects between different formats, for example loading old API macros and saving them again as FsX MDL objects. But I still have a long way to go before all that is ready.

At the moment I am mainly working on understanding the new FsX MDL format (and learning C# as a new programming language for my tools as well). The FsX MDL format has changed completely compared to the Fs2004 one, so that means a little work is needed again to understand it and be able to read and write it.

At the moment I can already read the shape of simple objects, but I still need to put some more work in reading the material section for example. Below you find a first screenshot of what will become the tool in the end. Hopefully you will be able to recognise a church in this picture. But I guess it is clear that I still have some work to do.

 

Happy Christmas!

I would like to wish all the readers of my blog a happy Christmas. And if you are lucky enough to have a few days free from work as well, I hope you have the chance to enjoy some FS as well during the coming period.

Personally I’ll be away the coming days, as I am with my family during Christmas. But from next tuesday I will be back home and I am looking forward to be able to spend some more time on FsX and tools during these days. So hopefully you can expect some tool updates as well during that period.

Randomize it!

I have added a little new feature to ObPlacer XML. While finishing some general aviation airports for the [NL2000] scenery I was planting trees with ObPlacer XML and I noticed that the resulting scenery was a bit boring with all trees having the same size. So I decided to add a little option that allows you to randomize the scale of certain objects.

Let me explain a little further how this work. First you just place all the trees like you normally do, so without taking care of the scale. After you are done you use the newly added “Scale Randomizer” tool. This will show you a list of all objects used in your XML file. So from this list you select your tree MDL file(s). You also enter between which two values the scale should be randomized. After that it is just one click to make the scale of all instances of the selected object type random.
This really makes the scenery look better in the end, as all trees look a little different now.

Another option I have added to ObPlacer XML is that you can also place Trigger objects of the type REFUEL_REPAIR. So this allows you to easily add a refueling area to your scenery.

I will use the Christmas break to finish the coding and release the new versions of the tools I have blogged about recently. So keep an eye on the site for news about the release. And of course I will also use that break to test the FsX changes some more and if possible add options to support FsX better with my tools.

 

Early christmas present

Most of you have probably already seen this, but MS has released an update to the FsX SDK. You can get it from the FsInsider download
page. Probably the most important component of this update is the GMax
gamepack for FsX, this allows us to make models from GMax in the new
MDL format.

One warning, as I have seen some discussion about
this on the forums already. You need to have FsX Deluxe to use this SDK
update (and to use the GMax gamepack as well thus). The update requires
that you have the origional SDK installed and that only came with the
Deluxe version. So take note of that.

I have not tried all new
features of the FsX gamepack, but already from some first tests I can
say that it is a big improvement over the past. There are some features
that we had to tweak for in the past, that can now be set directly from
GMax. For example to kill the shadow generated by an object or to unify
the shading of all polygons (often used on trees to match the autogen
trees).

Of course there are also some other features that we
still miss and at the moment I can’t say yet if we can tweak these in
again. That is because the MDL format has changed and I am still
studying the new format, to see all consequences of that. Once I
figured out some more, you will certainly hear more about it.

I
think this SDK update is a nice (early) Christmas present, that should
keep us busy exploring the new gamepack during the coming Christmas
holidays…
 

Lazy LOD

As I already mentioned in my previous post I have been working hard on a scenery of Schiphol airport recently. As this is quite a big airport and we tried to make it detailed as well, we ended up with a lot of objects. Unfortunately this did not improve the performance a lot. In the past you could easily limit the visibility distance of an object with the v1 value of the reference point. But in the Fs2004 XML format this is not possible.

I know you are know thinking that we should just have added LODs to our MDL files and I guess you are right on that. But for most objects we did not do that. Partly because the performance was not too bad until now and probably also because it takes quite some time to make good LOD models for complex buildings. And a third reason is probably just that we are a bit lazy sometimes.

But to increase the performance a bit, we still had to limit the visibility of the objects, as the default range the scenery engine uses is a bit too big in general. So I extended MDL Tweaker a little bit, so that it can now also create conditions using the IFSIZEV and IFSIZEH commands. These are also used by the LODs generated by MakeMDL to determine which LOD to show. This command checks the amount of pixels that is used by a certain length at the position of the object. If this amount of pixels is below the threshold specified, the lower LOD will be shown (and in our case I used an empty LOD for that). The advantage of this command over a simple distance check, is that it also depends on the screen resolution you are using. So if you run at a higher resolution the objects will show earlier, as they should to get the same image quality. If you use a fixed distance the object seem to pop-up later if you run at a higher resolution.

So based on the radius of the bounding box of the model, I added such a condition to all MDL files used in the scenery project (with a new batch functionality I added to MDL Tweaker as well). After some tweaking to get the correct threshold value for the resolution, this resulted in a nice increase of the performance of the scenery.

I will probably release the updated version of MDL Tweaker soon as well. I just want to check some other bugs and features that are on my todo list at the moment. But I think support of the IFSIZEV and IFSIZEH functions are welcome to other designers as well.
 

I can’t see more gates anymore

Finally I have the time again to make a more serious blog post here. You might be wondering what I have been up to lately? It has been mainly the [NL2000] scenery project that kept me busy. We are currently finishing the beta version of our next release and for the scenery of Schiphol airport I had promised to make nicely animated gates.

A while ago I already made some posts on mathematical calculations I was trying to make to calculate how a gate should animate to dock to a certain type of aircraft. I have now finished this tool as well and it is working very well I think. Let me say first that I will probably not release the tool as it is now, as some choices are hardcoded, which means that it only works with the gates as I designed them in GMax.

 So what does this tool do? So tell it some basic things about your gate, for example the length of the different arms, the default angles of the arms, etc. Besides that you also tell it where the stoppoint of this specific gate is (seen from the reference point of the object). With this information and like maths it is possible to calculate with rotations (and extension of the gate arm) are needed to make sure the head of the gate ends up at the stoppoint. But of course the aircraft door is not at the stoppoint, it usally has an offset depending on the type of aircraft used. So I also gave the tool this kind of offset information for about 30 aircraft types. With that additional information I could the desired position of the head for each type of aircraft.

Of course to get a perfect match with the aircraft model used, the designer of the aircraft should have put the door on the correct location, but as most aircraft designers try to make their models as perfect as they can I think that should not be a very big issue.

As you would probably have guessed already, the gates make use of the ActiGate module I made. So the animation is triggered by setting the parking brake and depending on the type of aircraft you use (as identified by the module) you get a different animations. Which makes sure that the head of the gate should end up at your door. Once I had figured that out, all I had to do was make a the different gates used at the airport. Unfortunately they have a lot of variants, for each of which I had to adjust my models a little bit. As we also have quite detailed markings in the scenery, the gates needed to match the real ones as closely as possible. And when you know that Schiphol has about 90 gates in total, I think you can image that it took some time to finish this all. 

Now you will probably wonder why I spend so much time on this, as FsX has a nice auto docking feature that should make things a lot easier. Well, I can only see that that is true. But (unfortunately) I had already promised to make these gates for this Fs2004 project (before FsX was there), so I had to finish them. And on the positive side I also learned some more tricks about tweaking animations. For example these gates have been tweaked with extending the SCEN section as CAT does. So that means that with this technique I could also condition the animation of attached effects. Maybe this new technique will make it into CAT as well, but for the moment I first want to study the new FsX techniques more to see which path is the best to go ahead on. I have seen enough gates for a the moment I guess, so the coming time I want to spend on exploring the new SDKs and looking at the new MDL format (and updating my tools where needed of course).