Animations made easier

I have made some progress again on the animation macros I wrote about last week. As I have never written programs in assembler code before, it is quite a nice challenge to learn how to use conditions and loops in those macros (but it is also fun of course).

I have already defined a command that generates all the tables needed to interpolate the frame number from the tick18 counter. Instead of loads of code in your ASM file, that are hard to understand, there is now simple one call to the new macro. When compiling the MDL object, the macro will take care of the creation of the proper tables. There is a similar macro that takes care of the calls to the commands that perform the actual interpolation.

Both these macros have been constructed so that they use a local variable base to store the frame number. This means the animation does no longer depend on the user variables. This is an approach I have been using in CAT for some time already and I prefer it a lot over the default MakeMDL approach. Both the macros also take a few arguments, one of them is the number of frames in the animation. If you set this value to more than 1024 frames, the changes I described on the forum some time ago will be added to your code and you should be able to make longer animations.

So with all this, I hope that tweaking animations will become easier until there is a nice tool to do it for you. It should also help more people to explore animations with over 1024 frames. At the moment I am still finishing and testing these macros myself, once they are ready you can be sure I will release them (with a little bit of documentation on how to use them).

Animation macros

Tonight I have been trying to do something new, writing some new macros for BGLC_9. I had been playing with the idea to make a few new macros for animation commands for a while already and now I gave it a try. It seems to be working better than I had expected, as it is very well possible to make a macro that creates those long interpolation tables. All you end up with in your code in the end is one simple call to that macro.

That certainly makes the ASM code easier to read in the end. And when I have finished a few more of those macros, I hope I can also perform tweaks to the animations much faster (that is the main reason I started this for). So in the end I hope to be able to make animations of a gate for different aircraft types, without having to animate them all manually in GMax. Just by giving a few parameters (distance, height, etc) and the macro should perform all the funny math for me. If this is really going to work, I still have to see, but until now it is great fun to write those macros.

An award!

Real life kept me busy the last two weeks, so that prevented me from posting more often. But yesterday I received some news that woke me up again, I have been awarded a Most Valuable Professional (MVP) Award by Microsoft. Wow…

As I am sure you can imagine, this was a very nice surpise to me. I am honoured that my contribution to the FS community gets recognised this way.

As I am still a bit overwhelmed by this news, I don’t know what else to write for the moment. I just want to share this news with you for now.

Time for a user manual

Tonight I have been working on MDL Tweaker II again. I have finished the vertex list dialog, that allows you to alter vertices of your object and also provides an option to “normalize” the normal vectors of the vertices. This last option is useful if you want to make objects that do not change color with the direction of the sun, like the autogen trees do.

Each time I finish one of the dialogs, the tool is getting closer to loosing the alpha status. The more recent versions also seem to be rather stable already. Before the first beta version will be released, I still want to implement a dialog to view the BGL command list of the object and also a statistics page. But first I am going to add the functionality to the texture list dialog, that allows you to correct the texture size. This would make my little CorrectTexScale tool obsolete, but integrating it into MDL Tweaker II would be a logical choice of course.

The more closer I am getting to a beta version, the closer I am also getting to writing the user manual for this new tool. Until now I just dropped the alpha versions on the forum and everybody played with it. But a user manual is really needed of course. It would help the novice user to learn more about the capabilities of the tool and also for the experienced user it is useful, as he can then discover all hidden features I have put in. So I really think I should start with creating the user manual in the Wiki soon.

CAT is "fixed"

The CAT headache is solved for now, as I have released a new version. As I already wrote about before, this new version does also support the ASM source files created with FSDS3. Although both GMax and FSDS3 use MakeMDL to export and create the ASM file, there was a little structure difference. I have learned CAT these differences now, so that both formats are supported.

But the other problem Nick and I found while debugging a few days ago was more difficult to solve. Actually I could not really solve it, I could only add an option that gives the user a choice between two ways of doing it. And both have there ups and downs.

The first way is to apply the animation condition on the animation trigger. This is how I had been doing it since CAT v1.01. The advantage of this method is that, when the animation condition fails, the reverse animation will nicely be shown to return to the static state. But when multiple copies of the same object (sharing the same GUID thus) were placed this did not work. After some thought, this behavior was very logical of course. When you call a library objects you are expecting the object to share the same memory space (that is one of the advantages of libraries). So that means they also share their local variables to store the animation state. If the animation condition then fails for one of the objects you placed, that means the animation state is set back to static state for all of them. So this means that you animation will never ever start, unless the animation condition is true for all copies you placed at the same time.

One alternative for this would be to create a new GUID for each object you place, but when you need to place 100 gates at an airport or so, this is no real option. It also destroys most of the advantages of using a library. The second alternative is to apply the animation condition, like I did before CAT v1.01. So in that case the animation condition works on the animation itself and not on the trigger. So the trigger can remain shared between all objects and when the animation condition fails a switch is made to the static condition right away, so if the animation condition fails before the trigger fails, this means you get a sudden jump.

In the new version of CAT you can use both methods, so depending on the condition under which you want to use your object, you can choose the best way to apply the animation condition.

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.