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.

OGR

The last few days I have been using the OGR library at work. As the website says, it is a Simple Feature Library. It allows you to rather easy read, manipulate and write vector features in different file formats (for example DXF or SHP).

This can be very useful, as you do not have to create your own file format parser, as I did for my DXF2SCA tool. And the manipulation of the vector data is really nice. At work we for example use the union function to make one  big polygon out of different taxiway segments. And the buffer function is used to calculate a grass area around all features of an airport. This way we can rather easy make some generic airports for our visual databases.

I think I will also give this library a try for my next (updated) version of DXF2SCA. That could certainly save me some coding and allows me to focus on the scenery output for FS, instead of reading a certain file format.

Object libraries, again

A few weeks ago I made a post about the problems that arose with not so experienced EZ-Scenery users trying to change/alter object libraries. In the past few days I come across a few more discussions that relate to this and what I read there worried me a lot. So therefore this new post about the subject.

What worries me the most is that some people think about (or maybe even put into practice) the idea of decompiling libraries, to then put the objects back into new libraries that are organized according to their preference. So for example all hangars together.

Having a way to organise your objects is not bad of course, that is a very useful feature. But you should NEVER alter existing libraries during that process. There are quick a few good reasons for this.

  • When you create your new library, all objects will get a different identification number (GUID).  This is certainly not prefered. Think of the chaos that would appear when we end up with one object having dozens of different GUIDs in the end, because a lot of users made their own personalized library. You would never know from which library you are reading that object at the moment.
    It is also just against the reason of libraries in the first place. There are meant to be as a collection of objects, that can then easily be used in different sceneries.
  • In the end if would cost you a lot of disk space as well (and thus more downloading for the users of the scenery as well). Would you be happy if you had to download the same objects again and again? Of course not, it is much easier to download one library containing them all once and after that any scenery can make use of them.
  • By changing the GUID that the origional author has assigned you also break his backwards compatibility. Imagine that he uploads an improved version of his library. Any user that uses his origional one wouldn’t have to change anything, their placements refer to the GUIDs of the author and they can thus automatically use his new objects. But if you have assigned a new GUID to the object, you loose this.
  • When compiling the work of somebody else, you are usually breaking his copyright/user license. So you could get in trouble if you distribute this new library.

I am not saying that those EZ-Scenery users that come up with these ideas are to blame here. They probably just miss a bit of “education” about what an object library is and how you can use it. So maybe it would be worthwhile to put some effort into that. Maybe it should even be part of the documentation of object placement tools, especially if they aim at a broad public that does not only contain hardcode scenery designers.

I also want to give some attention to another issue that came up in recent discussions. EZ-Scenery does scan your entire scenery library for object libraries. And they are then all added to the list you can choose from. But what happens if you have an addon scenery installed that also makes use of an object library? It will also appear in the list of course. If that library has been designed for one specific airport that is not something that you want and if the library is part of a commercial scenery you don’t want it either. In both cases you could never distribute your scenery if it uses objects from such libraries. Simply because you can not distribute the libraries with it.

So I think it is better if object placement tools would only show objects from generic libraries that are part of FS and object libraries that have been designed and distributed with the purpose of being used as a general object library. For example all those libraries that have been created for use with Rwy12.

For the moment we should trust the user of EZ-Scenery and hope he has enough knowledge to make the shift between those generic libraries he can use and the specific or commercial libraries he can’t use. But as they all appear in his list, I am afraid this will go wrong some day.

That brings me to a last point. There is absolutely no difference between an object library designed for Rwy12, EZ-Scenery or ObPlacer XML. The only difference is how those tools read their information about the library. So wouldn’t it be nice if we could get some sort of collaboration between users of all those tools. I would hate to see more Rwy12 libraries or EZ-Scenery libraries appear at the big download sites. We should see object libraries for Fs2004. And it should not matter which tool you use in the end to place the objects.

SCASM is bad and GMax is good, or is it?

Ever since GMax was included with Fs2002 discussion like SCASM is bad and GMax is good have appeared now and then. Now that FsX has been announced I have noticed that I appeared again. I saw questions of people wondering if SCASM BGL files would still work.

But people that ask such questions don’t seem to understand what SCASM is. It is just a compiler that creates a BGL file from a source code with a list of commands that you provide to it. The file that is produced is not something special that only SCASM could make, any other compiler like FreeSC or BGLC can make exactly the same BGL file. So to ask if a SCASM BGL file would still work is nonsense, as there is no way to tell which compiler created the BGL file.

Most people that this question are worried about the support of older scenery commands that they still use. And this is a valid question, but it should not be linked to the compiler used. If the old Fs5/Fs98/Fs2000 commands will still work in the future is something that is a good point of discussion. The introduction of the floating point commands in Fs2002 for example, makes the integer point commands used before almost useless. So it is logical to assume that support for them will be dropped somewhere in the future.

To return to the SCASM question, it is very well possible to make a BGL file that is identical to a BGL file created with the Fs2002 gamepack for GMax. So in that case SCASM is just as good as GMax. For Fs2004 this is no longer valid, as SCASM has not fully been updated to the Fs2004 format. SCASM is able to create mesh elements (VTP/LWM polygons for example) and do object placement (like we can do with BGLComp as well), but it is not able to create the MDL scenery object files. This is because the structure of these files would require quite a big change in the internal workings of SCASM and it is rather unlikely that this change will be made. So in the future we might see that SCASM is no longer equal to the other compilers we can use and maybe then we can start asking if SCASM is “bad”. But not because it is SCASM, because it does not support the latest formats.