CAT headache

Version 1.02 of CAT is get closer to release again. This evening I had a good debugging session with Nick on a bug he had since CAT 1.01. I finally was able to reproduce his animation condition problem. Basically the problem means that the local variables used to store the animation state are shared between all copies of the object you place. So now that the animation condition works on the animation trigger (to make sure you get a nice reverse animation when the condition is no longer true), this means that multiple placements of the same object will block each others trigger, unless the animation condition is true for all of them at the same time. This is really a nasty feature, or should I call it a bug?

One easy option is to change the way the animation condition works back to the status of CAT 1.00, but that means that the animation will suddenly jump back to the static condition when the animation condition is no longer valid. This isn’t really nice either. So I think I will go for the second option, think a bit harder on a way to combine both ways of doing it. It just must be possible, must be…

The CAT has grown a bit

Until now CAT was only a tool for users of GMax, but now that FSDS3 is also using MakeMDL it is time to change that. In theory the ASM sources file created by MakeMDL when exporting from FSDS3 should work right away with CAT. But of course the reality is that there are a few minor differences in the structure of the source code. I have now figured out what these differences are and I am patching CAT to understand both “formats” of the ASM file.

So expect an updated version of CAT soon, that will also allow FSDS3 user to use the conditional animations. And besides the changes needed for FSDS3, I also want to implement the IFMSK condition, as this one has been on the to-do list for quite some time already. With the IFMSK condition it will be easier to use CAT together with the ActiGate module.

Seasons

I had a very productive weekend, as I was visiting my parents and could therefore not be disturbed by forum questions or people chatting with me. I had brought my laptop, so I made some nice progress on MDL Tweaker II.

I finished implementing the code that allows you to add seasonal conditions to your textures (and it should also be able to read that information back from the MDL file the next time you open it). You can find the latest alpha version of MDL Tweaker II on the forum. You will have noticed that I wrote alpha version, so be aware of the bugs that might be hanging around in the code.

In the end it proved to be quick a challenge to make a user interface that was both rather easy to use and flexible enough to allow all kind of conditions on the textures. For example some people might only want a HW and a SU version, others want all seasons or maybe only a night variant. In the end I hope the GUI can suit everybodies wishes.

There is only one thing I am still wondering about. Why can’t we just assign the seasonal textures as a subtexture type, like we can do with the night textures? That would save us a lot of condition code to switch the textures correctly. The fact that the season variable does not match the season of the mesh scenery makes things even more complex. We now have to use the day of the year variable to get the correct textures that match the mesh scenery transitions as well. I really hope that MS will make seasonal textures easier in FsX or else at least provide us with a season variable that is in sync with the mesh scenery.

Time

I am sure you all have this problem, where to find the time to realize all the scenery ideas you have. I always seem to have a huge list of ideas for sceneries or tools that I want to test, try, design, etc. This means that I am usually doing many things at the same time, causing none of them to progress as fast as I would like.

I am for example a member of the NL2000 scenery design team. As part of this project that covers a scenery of the entire country, I am mainly developing airport sceneries. Last weekend we had a workshop, where we built some scenery together and shared tips and tricks with each other. This was great fun and gave me some motivation again to work a bit harder on these sceneries.

Another project running at this moment is the MDL Tweaker II tool. I am currently working on implementing the seasonal tweaker part and once that is done I will release a new version. Currently most of the GUI has been implemented, but it is not fully working yet. I hope to be able to finish this part in the coming weeks as well.

The next tool that is on the todo list is ObPlacer XML. There are a few bugfixes and small feature request that I hope to implement in the next version. And as a more long term project there is a new version I would like to make with more functionality. But this might also take a different form as the current ObPlacer, I am still thinking about that.

Other small things I have on my todo list for the coming time are, writing a tutorial about the animation knowledge I gathered last week and to update/write the manuals for the tools discussed above. This writing of manuals costs more time than you would like to spend on them, but on the other hand you need them to tell the users RTFM. When starting the SceneryDesign.org Wiki I had hoped that more users would contribute to the manuals and the tutorials, but until now that has not really happened.

Sometimes I am wondering if I do not have too many ideas for one person to complete. I think I could fill a full-time job with it, but I do not have that much a spare time of course. At least you now know a bit more about all the different projects I am trying to do at the same time. And I hope you can also understand that some new versions of tools get a bit delayed by all this. Oh, and if you feel the need to help with any of this, don’t hesitate to let me know…

The last piece of the animation puzzle

As I wrote two days ago, I was testing a method based on the CAT tweaks to make animation possible that use more than 1024 frames. While finding a trigger to get that animation running correctly (which I got working in the end), I made an even bigger discovery.

I finally understood the last part of the animation puzzle, the interpolation table that is in between the integer frame number and the actual interpolation of the animation itself. This did some sort of magic conversion that I never really understood, until today. It writes a part of a floating number (the other part of that float is written in a different piece of the code) and that float actually drives the actual interpolation of the animation.

So what I tried is to extend that table a bit, so that it could also convert frame numbers above 1024 into a proper float. I made an animation that has 3072 frames and gave it a try. And YES, it worked. I had made an animation for FS that uses more than 1024 frames and no special tweaks like CAT are needed. Only by using the normal animation techniques.

I don’t know yet where the limit of this is, the current table I have will handle up to 4096 frames for an animation, but I could try to extend it to 8192 or 16384. 16384 frames is already an animation of 15 minutes (at 18 Hz) so I guess that should be long enough for most of our wishes.

Now that I have the technique working, I know the next question is going to be, when will there be a tool so that we can use it easily? Actually I have received that question already. But I still need to think of a way to put this into a tool that would be easy to use. Remember you can’t use GMax to make this longer animation at once, as MakeMDL will not export more than 1024 frames. So you would either have to split your animation in parts or import the path in a different way. Any ideas are welcome.

I think I will try to make a nice article about the animation technique, now that I understand it all. By the time I have finshed that, I am sure there will be a good idea for a tool as well.

1021, 1022, 1023, … crash?

Today I have tried to break a limit of FS again. This time the 1024 frames per animation limit was the thing I tried to come around. Of course I can not really increase this limit, as it simply is there, but I have tried to play different animations after each other (each maximum 1024 frames long). That way we can make an animation that requires more than 55 seconds to play, I want to use it for animated traffic at an airport for example.

Those who have followed my forum a bit longer, know that I have been working on this before as well. I have started to create a tool called AniLinker, based on CAT, that does the same. But due to lack of time (or should I see to much things to do?) I haven’t finished that tool yet. But recently I found a way to let an animated windmill rotate with the wind direction, by tweaking the animation code a bit different from the CAT tweaks. And with this new knowledge I had a look at the animation length problem again.

The good news is that it basically works. I could switch between the different animations, each having a length of 1024 frames. I still need to think of a smart trigger to automatically do the switching between them (I now used the NAV2 frequency just to test it). Another problem with this technique might be that all animation must have the same length. But if a tool does all this math work for you, it shouldn’t be a real problem either.

So for the coming days I need to work on a cool trigger and then I can let my test object drive around the airport. Should be fun…

GDAL

About a week ago I wrote about OGR, but actually that library is part of a bigger one. That is the Geospatial Data Abstraction Library (GDAL). And this library offers some very nice features as well.

Let me give an example. It comes with a few tools for example and at work I used one of these to convert a scanned airport chart into a GeoTIFF image. I just told the program the latitude and longitude of a few pixel locations (threshold, airport reference point, etc). With this information the tools were able to convert my image into WGS84 projection and after that the image lined up with our runway data perfectly!

These are powerful features that can also be of use for FS scenery designers. The more I think about it, the more I think I should try to use features like this in a future tool…

FsX

A few weeks ago FsX has been announced and now and then new screenshots appear. And until now I haven’t even mentioned this great news on my blog. But I do not want to discuss the released screenshots here, there is enough discussion going on about that on general FS forums. And I think most people will agree that they look great.

Since the announcement of FsX I have already seen a few discussion about the backwards compatibility of scenery. And on that subject I would like to give my opinion. The question is always will my old addons still work? Of course it is a good thing that we have some backwards compatibility, because we don’t want to redesign everything for each new version of FS. But I think now is a good time to clean up some of the compatibility for really old code.

Almost each addon scenery designed since Fs5 does still work in Fs2004. It is really surprising to see that most of these old commands still work, although not all. If all those commands worked fine together, this would not be a problem of course. But in reality that is not the case. Quite often you see people that have created an apron in a tool like FSSC or Airport for Windows and they are looking for a way to get it below their AFCAD created runway. Unfortunately for them the answer is that that is not possible. This is just one example where the Fs2004 scenery code and the pre-Fs2004 code does not really work together that well.

For a new scenery designer this is also very confusing. He finds a load of tools he can use, but he has no idea if and how they work together. Quite often this results in new people making the wrong choices (for example EOD, Airport for Windows, etc). I am sure this is a big frustration for a lot of them and makes them give up scenery design, while it should be fun to do.

So although it might mean some extra work for us, I really hope that MS is going to clean up the supported commands. Please stop supporting all those Fs5, Fs98 or Fs2000 commands, as in general trying to use them together with Fs2004 gives more trouble than it solves. This would also reduce the jungle of scenery design tools we can use automatically.

There is one exception I want to make here. If we only want to use the Fs2004 techniques for airports (so the XML commands) they need to become a bit more flexible. At the moment these commands are too restricted to make a realistic looking airport. You can’t make markings in different colors than yellow, you can’t use custom apron textures and you can’t control the mapping of these textures. So MS please make the XML format a bit more flexible for users who want to create an airport that does not look like the default scenery and then I am sure nobody will miss those antique Fs5, Fs98, Fs2000 commands.

Texture and material blend

At work we have recently updated our image generation software and the models that I had converted from GMax models suddenly looked a lot darker in the visual. To dark actually. So after a bit of searching we found out that the new version of the IG blends the material and texture, while the old on did not. So because the ambient color of the material was not white, but gray, it resulted in a darkening of the texture. With this extra knowledge that was easy to fix of course.

Because I was interested to see how FS behaves here, I did a few tests with blending of material and texture there as well. I posted about the results on my forum, but the main conclusion is that FS only blends the emissive color. All other colors do not have an effect on the display of the texture. Only the combination of a specular color and the power parameter seems to have some effect, but I can not create a useful visual effect with them. It only seems to distort the image.