Building animation

Topic: Building animation (Read 8533 times) previous topic - next topic

Building animation

July 30, 2009, 03:51:57 pm

How many people produce animated buildings for Simutrans, and how many of these already exist in the game?

I've been looking recently at the possibility of creating an automated process for optimising the creation of animated buildings, essentially this would be a form of compression specific to the way animated buildings are implemented in Simutrans. You could then (using for example a 3D modelling application) run off a series of frames and have them automatically optimised into a pak file using the least possible amount of disk space. The sheer size of un-optimized animated pak files is one of the major problems with using them at present.

I've had a few ideas about good way to do this but I want to gauge how useful this feature would be to people before I do it (since it'll be reasonably complex). I'd put the functionality into TileCutter to make it easy to produce animated buildings in one application.

So yeah, any thoughts? Are animated buildings something we want to see more of, and would having a tool like this make you more likely to develop them?

Re: Building animation

Reply #1 – July 30, 2009, 04:30:47 pm

If it was optional, then +1 to that idea. Couldn't we possibly use that when having *construction* done?

E.G:

1)Construction
2)1/4 or 1/2 image
3)1/2 or full image?

3frames.. , only takes 1 frame, and then edits it a bit..

Re: Building animation

Reply #2 – July 30, 2009, 10:08:41 pm

It would be nice if we had one. Only if someone care to make it...

My recent remark is that simple light on/off animation with long interval requires
all images but not only two images. All instance needs image is what I want to say.
So, the pak file gets substantially bigger inspite that it has simple animation.

Re: Building animation

Reply #3 – July 31, 2009, 08:54:40 am

AFAIK, in pak96.comic there is an animated antenna.

Re: Building animation

Reply #4 – July 31, 2009, 09:02:28 am

Quote from: colonyan – on July 30, 2009, 10:08:41 pm

....
So, the pak file gets substantially bigger inspite that it has simple animation.

this is not correct

Quote

history-pak128-svn.txt
13.07.2008
   - optimizing graphics and animation factory Moebelhaus (a0-homemarket-128.png, factories-wood-128.dat); pak file size 3 MB -> 410 kB (FrankP)
   - ...
   - fix and optimizing grafics and animation factory Materialswholesale (a0-materialswholesale-128.png, factories-material-128.dat); pak file size 777 kB -> 81 kB (FrankP)
   - optimizing grafics and animation factory Sandquarry (a0-Sandquarry-128.png, factories-material-128.dat); pak file size 393 kB -> 145 kB (FrankP)

Automatics make the files bigger.

Any animation needs a separate solution. Therefore, handmade animations remain.

Re: Building animation

Reply #5 – July 31, 2009, 09:54:47 am

I'd be interested to hear how you optimised those files Frank, I'm sure the process could be automated. Essentially my idea was to keep the BackImage static while auto-generating the changes necessary to show the animation in the FrontImage (e.g. pixels changed from the base). It would then calculate the % of the total pixels changed and, when this number exceeds the amount of pixels which would be changed by modifying the BackImage, produce a per-tile "keyframe" before continuing with the system as before. It could also compute this based on the compression routine used to save the pak file, such that it optimises in the format used by Simutrans.

Granted all this could be done by hand, I was just thinking that if we had such an automatic tool it would make animated buildings much more accessible to "amateur" painters and overall increase the number of animated buildings available.

Re: Building animation

Reply #6 – July 31, 2009, 11:08:00 am

Here is Frank's answer translated:

Timothy just ask VS for the sources of paks.

The length and width of all graphics must stay the same through all animation phases. Otherwise, there would be jumps when zooming.

And only on level 0, the animation graphic can have transparent background images. On higher levels, there must be background graphics behind the animations, otherwise there will be graphical glitches.

Re: Building animation

Reply #7 – July 31, 2009, 11:09:13 am

That's the logical way to paint it, and also to implement it, Timothy. Every time is carry out an animation, I think which elements do not change and will go in the Backimage, and which ones change and will go in the FrontImage. If you can automatize this proccess, just detecting the differences between the frames the user has provided, that would be great. However, I see a posible problem. In order to generate only one Backimage and several Frontimage frames, you can't compare consecutive frames, but all frames with the first one, so you can detect and extract the pixels that have changed from the original Backimage.

Re: Building animation

Reply #8 – September 05, 2009, 11:29:51 am

It sounds to me like you are talking about something like i-frames, p-frames and b-frames. The MPEG standard considers these problems and may be a good source of inspiration.

Re: Building animation

Reply #9 – September 05, 2009, 12:41:06 pm

I missed this... not fair!

MPEG is indeed interesting, but it won't help here any. Unfortunately in this case the operations are required to be lossless and within an existing system which gives at best two independently animated layers with bit transparency. The case considered here is further simplified by having the background layer static.

The recipe:

topmost loop over tiles in space,
then over all pixels in a tile,
order colours by # of occurrences in all frames,
take most common as background,
add to background picture
go over all frames
if same colour as background,
make foreground in that pixel in that frame transparent

You make me want to code it

And yes, it would definitely be useful. Animations are a pain to do properly.

Re: Building animation

Reply #10 – September 05, 2009, 12:51:09 pm

I-frame, p-frame and b-frame concepts could be used without the lossy compression - just the concept of partial and whole (inter) frames. Clearly we do not need the bidirectional frames.

You know, another way to go about it would be to have buildings constructed with multiple anima - this is the way sim city does it. It means that common elements can be shared between buildings - but makes rendering each building more complicated. Some animation could then be simply moving anima - ie the carriages on pak128 steel works moving up and down the track periodically, or a lift on the side of a tall building. We can move and articulate trains already - so that may work.