News:

SimuTranslator
Make Simutrans speak your language.

Animated Vehicles

Started by Leartin, February 03, 2017, 03:37:34 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

Just wanted to search for the earlier proposals about animated vehicles to see why it was dismissed - and did not find any. Seems odd. Since vehicles have to be redrawn while they move anyway, shouldn't it be easier for them to be animated then other graphics, without extra computation time even?

(personally, I think everything should be able to be animated. Even old games like Settlers2 had animated trees and stuff, and there is no object type I could think of without some use for animation)

Ters

I don't remember playing Settlers 2 in anything higher than 1024x768, and whenever there were a lot a animated things on screen (typically after a storehouse went to pieces), it did slow the computer down a lot.

I think there are two issues with animating vehicles:

  • Should the animation be time-based like the others, or motion-based? If the latter, how exactly?
  • Vehicles require a lot of images already, since they have eight orientations. Are there enough artists willing to make that many images to make the programming effort worthwhile?

I guess the lower limit on total number of images also put a damper on things earlier.

Ves

I certainly would do it if I got the possibility!
I think it was discussed somewhere some time ago to let vehicles have both front images and back images, then when you make i.e. A steam engine, you only paint the engine once and let the animated parts, i.e. The coupling rods, be front images. With that, you can even use the same coupling rod animation on multiple steam engines. 

Leartin

Quote from: Ters on February 03, 2017, 04:28:31 PM
I don't remember playing Settlers 2 in anything higher than 1024x768, and whenever there were a lot a animated things on screen (typically after a storehouse went to pieces), it did slow the computer down a lot.
That would be a lot of free-running entities though. I'd assume the same thing would happen if the settlers moved without animation, but that's pure speculation and does not really advance us, seeing as we talk about slowdowns in a 20-year-old game.


Quote from: Ters on February 03, 2017, 04:28:31 PM
I think there are two issues with animating vehicles:

  • Should the animation be time-based like the others, or motion-based? If the latter, how exactly?
I'd go with motion-based. Most animations one could do in a vehicle are directly related to it's speed, be it spinning wheels, some kind of piston moving up and down, or even a waving flag. Some others might not, like orange blinking lights on long trucks or a helicopter rotor, but I think those would be more specific.

In the end, it depends on how it's programmed. If you can tie animation to actual 'redraws' of the vehicle, so the graphical movement decides animation speed, it would be perfect. But if you would have to check the calculated vehicle speed at any given time to check how quickly the next frame should be shown, I don't think it would be worth it, and a stable animation speed like for everything else would be fine as well.

Quote from: Ters on February 03, 2017, 04:28:31 PM
  • Vehicles require a lot of images already, since they have eight orientations. Are there enough artists willing to make that many images to make the programming effort worthwhile?
I mostly do buildings. But I do buildings with eight orientations and five seasons...
Depending on what it is, it might be very hard to paint. I think I wouldn't start with a 10-frame-horse-animation for each direction. But there is easier stuff. Especially with Ves frontimage-suggestion, you would not even have to paint any more images, you would just have the coupling rods on a seperate image and use it with different offsets. I'm not entirely sure, but it should be possible to define the offset via formula and only use one line per direction. Honestly, even if it's just coupling rods for all steam locos, I think it would already be paid off.

prissi

Animation uses fix time frames. I may look funny, if the tires turn not in sync with the actual speed ... so there are certainly more issues to fix here. Not too difficult, but this requires also a new format of images management for vehicles. Especially larger pak size would profit from it.

Here goes the challenge. Make a vehile with a visible animation, and I will try to implement it.

Leartin

Just as a quick proof of concept, the animation is easy, but I have to pixel the back of the truck since we had no cement truck before, and I don't think I would get away with just the pedestrian - even though these alone would be quite awesome (in pak192.comic, probably not in any other pak - and they would really need this to shine: http://forum.simutrans.com/index.php?topic=15200.msg149939#msg149939)

Vladki

Really nice. I just have the feeling that the wheels are rotating backwards. And you fantastically hit a case when part of the animation should be based on speed/movement - wheels, while other part (flashlight and mixer), should not depend on the speed of vehicle.

Leartin

Well, the animation of the wheels IS backwards. That is because they are moving forward so fast it appears backwards - https://en.wikipedia.org/wiki/Stroboscopic_effect

Ves

Wow amazing looking! The rotation of the cement container could even be tied to wether the truck is loaded or not, using cargo image.
And the man is brilliant!

If both animation types are implemented, I think the benefits from having both front image and back image  is essential to separate the animations. Maybe even a front-front image (so picture is three layers)?

prissi

Well, I would need eight view. And pedestrians are probably a bad idea (performancewise) to be animated, at least on bigger ganes

Yona-TYT

#10
Quote from: prissi on February 04, 2017, 01:25:52 PM
Well, I would need eight view. And pedestrians are probably a bad idea (performancewise) to be animated, at least on bigger ganes
Leartin may be thinking of an future for Hardware accelerated, or more powerful in computers.
Also the option to deactivate the animations when the equipment is very slow.  ;)



No doubt, animated vehicles / pedestrians will look very nice at pak192.comic.  8)

prissi

As long as there are not vehicles, I am kind of reluctant to put much work in for eyecandy. Especially the pedestrian is a good example of animations making the appearance worse, if they are not synchronised with the movement.

Leartin

Quote from: prissi on February 04, 2017, 01:25:52 PM
Well, I would need eight view.

Despite being Austrian, I don't hold some pixel slaves in my basement, so I can't present result instantly :) I thought the first view would be enough to show it is possible, and to test implementation I would rather use something where the difference is even more appearant, eg. animating through different cargos of an existing vehicle. But here it goes:


A complete animated vehicle, using 6 frames.

Quote from: prissi on February 05, 2017, 02:22:25 AM
As long as there are not vehicles, I am kind of reluctant to put much work in for eyecandy.
That cat bites it's own tail.
If a feature does not exist, people won't put work into creating graphics for it, since there is no guarantee they would ever be usable. Except as a proof of concept of what they even want to do.
Once you promise to do it if people (or at least someone) will use it, you should not need to wait for them to exist either. Unless you don't trust the artists to deliver, but if so, why would the artist trust you to deliver the code?
It's the features of the game that define what graphics will be created, not the other way around. (And if it actually was the other way around, where are liveries in Standard? Graphics certainly exist...)

Quote from: prissi on February 05, 2017, 02:22:25 AMEspecially the pedestrian is a good example of animations making the appearance worse, if they are not synchronised with the movement.

I disagree. I did not even synchronize the movement when I created it, I just made the frames and spaced them out. I attached 4 different speeds for them, and I think all of them look better than hovering ghosts. But since all pedestrians walk at the same speed, and changing game speed changes animation speed, they would fit anyway.
As for the performance issues - isn't that why we have settings for how many of them are on the streets?

Vladki

I think speed 2 looks best.

Dwachs

I do not see, why animated images for pedestrians could have an large impact on performance: if animation is based on speed, then the image only changes on movement. But then a new images has to be drawn anyway.

And non-animated pedestrians are not nice in close view in pak192.

Leartin, could you provide a png file containing these animation frames? Best would be to have animation frames for a complete walk across a tile. Then the image of the animation can be determined by the position of the pedestrian on the tile.
Parsley, sage, rosemary, and maggikraut.

Ters

Animated moving objects will in theory only be slowed down by the extra logic required for calculating the frame and the extra cache misses caused by the fact that there will be even more different images. That will likely not be noticeable.

Animating buildings or, even worse, trees would have a greater impact, but it should be comparable to panning the map. Maybe animations could be turned off when zooming out, because that tends to be when drawing gets too slow today.

Leartin

Quote from: Dwachs on February 05, 2017, 05:40:10 PM
I do not see, why animated images for pedestrians could have an large impact on performance: if animation is based on speed, then the image only changes on movement. But then a new images has to be drawn anyway.
Exactly what I was thinking.

Quote from: Dwachs on February 05, 2017, 05:40:10 PM
Leartin, could you provide a png file containing these animation frames? Best would be to have animation frames for a complete walk across a tile. Then the image of the animation can be determined by the position of the pedestrian on the tile.

Currently I only have this one direction.
But just to be sure: Currently, pedestrians have some variable that indicates their advance on a tile, and their position within the tile is based on that variable. Your suggestion is that instead of iterating through positions based on that variable, you iterate through the frames of the animation?
At speed two, that would mean 48 frames for a straight walk. Which are the same 6 frames every time, just with an offset. Would you like the complete 48 images, or just the 6 different ones, which would then be repeated in the dat-file with offset?
Image[E][0-47]=pedestrian.0.<$0%6>,<$0*2>,<$0>
(if done like this, each image would have the pedestrian in the same position, but the offset in the definition moves him)
How about diagonals? Just the same teleporting stuff for now, with 48 frames as well?

Dwachs

There is an internal variable to count steps of a vehicle on a tile: walking straight n/s or e/w is 256 steps, walking diagonal takes 181 steps (no matter how the vehicle is positioned to the imagined middle line of the way/track).

The easiest approach would we to couple this internal steps to the animations: if N animation frames are provided, then every 256/N steps the image changes. Or the other way round: after N steps the animation repeats (with offset).

The movement is then done by the program, the provided images are always placed at the same point in the graphics.
Parsley, sage, rosemary, and maggikraut.

Ves

I would like to add another example of animation to show how 128 pixel size steam engines would come more to live with animation. Save for I dont know how to exactly to calibrate the speed to look right, 6 frames are used for the animation in this example.

DrSuperGood

Ideally an actor system would only calculate animation timing and such for actors near the current camera view. This would mean that all the animations have no logic overhead for stuff not near the view.

However Simutrans does not have an actor model, with instead graphics being rendered at a much lower level, often as part of the object state tick (eg power station transformers).

Animating moving vehicles would probably need a normalized speed. Eg 1 tile per second of animation, where animation is defined in frames per second and the specified animation frames loop. As the convoy increases in speed the animation would also increase in speed.

Leartin

Quote from: DrSuperGood on February 06, 2017, 01:51:50 AM
Animating moving vehicles would probably need a normalized speed. Eg 1 tile per second of animation, where animation is defined in frames per second and the specified animation frames loop. As the convoy increases in speed the animation would also increase in speed.

That's what happens with Dwachs suggestion. The animation across the tile stays the same, no matter how quick the vehicle moves. So if the vehicle moves quicker, the animation speeds up.

prissi

The distance on a diagonal is shorter, so it will be a little more tricky than that. But indeed, that was the idea.

Leartin

I might have some time in the evening today.

Are pedestrian frames in all 8 directions, positioned on the stylesheet as usual, all that you people need for testing right now? Or is there something else required? (Not that I think you would do it right away - new release and all that ;) )

Dwachs

This would be the ideal image to start.  The pedestrian should 'walk' at the same position all the time. Then the movement of the pedestrian can be done with the existing code, 'only' the animation has to be implemented. You do not need to animate  all 8 directions yet.
Parsley, sage, rosemary, and maggikraut.

Leartin

Oh. I attached the file - only South and East are animated, the others are still static.

Image[W]=pedestrian.0.2
Image[N]=pedestrian.0.1
Image[E]=pedestrian.0.0
Image[S]=pedestrian.0.3
Image[SE]=pedestrian.0.4
Image[NE]=pedestrian.0.5
Image[NW]=pedestrian.0.6
Image[SW]=pedestrian.0.7

Dwachs

Can you say how many pixels the person moves in x and y direction after one loop of the animation frames?
Parsley, sage, rosemary, and maggikraut.

Dwachs

Here is a proof of concept for animated pedestrians:

https://www.((Site not allowed - serves viruses))/download-12334686/animated_ped.zip.html

zip archive contains simutrans and makeobj windows executable, patch, and pedestrian dat  + pak.
Parsley, sage, rosemary, and maggikraut.

An_dz

Amazing, super nice. But the graphics have white artifacts in some frames, Leartin forgot to set the background colour as #7FFFFF. :P

I decided to follow some pedestrians and they seems to be able to teleport now. One was walking E->W in the north part of the tile, when the guy reached the NW part of the crossing he simply teleported to the NE part and walked N->S. The same happened with another walking N->S at the west side of the tile and then decided to go east at the crossing, just teleported from N to S.

Yona-TYT

Quote from: An_dz on February 24, 2017, 07:23:02 PM

I decided to follow some pedestrians and they seems to be able to teleport now. One was walking E->W in the north part of the tile, when the guy reached the NW part of the crossing he simply teleported to the NE part and walked N->S. The same happened with another walking N->S at the west side of the tile and then decided to go east at the crossing, just teleported from N to S.

I think this error (teleport) has been around for a long time.

Ters

Quote from: Yona-TYT on February 24, 2017, 08:07:46 PM
I think this error (teleport) has been around for a long time.
Yes, and although they are not this kind of pedestrians, the sheep in pak64 are probably the worst offender of all, at least when cornered.

prissi

The problem is also that the corners are ways are shorter and longer at the sides of the road compared to cars or trains, which are more central. So pedestrians are bound to have artefacts at crossings, at least when using the same steps at coners.

Leartin

I saw it on Facebook. Amazing! At least as long as they walk straight.

An_dz

Quote from: prissi on February 25, 2017, 11:02:15 AM
The problem is also that the corners are ways are shorter and longer at the sides of the road compared to cars or trains, which are more central. So pedestrians are bound to have artefacts at crossings, at least when using the same steps at coners.
I understand why, but now that the graphic is always fixed at the bottom this can be fixed. I guess that's why Dwachs asked them to be at the bottom.

Dwachs

This would be another patch: make the length of diagonals a parameter for paks.

If the animated graphics is fixed at the same position as the non-animated then the graphics movement is the same for non-animated and animated.

For animation, which parameters do we need? I imagine some scaling parameter to scale animation speed with movement speed.
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on February 26, 2017, 10:49:51 AM
This would be another patch: make the length of diagonals a parameter for paks.
May I redirect to the proper extension request, just to keep this thread cleaner:
http://forum.simutrans.com/index.php?topic=15200.msg149917#msg149917

Quote from: Dwachs on February 26, 2017, 10:49:51 AM
For animation, which parameters do we need? I imagine some scaling parameter to scale animation speed with movement speed.
Depends. Is the first position on each tile always the first frame of the animation, or can the animation cross tiles?
If the animation can't cross border, it means the animation needs to complete within the tile. So I think it would be best if you can decide how often the loop should repeat within one tile.
If it can cross tiles, I'd say define the animation speed by how many 'steps' use the same frame, based on a straight tile. So if it's a 6-frame animation and you want to see it looped 6 times per tile, you'd define animation speed as 7 steps. Does not quite add up, but since it does not interupt the animation at tile borders, it does not matter. Same goes for defining the number of steps per loop, but I think steps per frame makes more sense, since it's similar to the animation speed we already know.

I think that's it for this feature, as a content creator, I don't see what else I would like to set myself.

Dwachs

Here is an update:

https://www.((Site not allowed - serves viruses))/download-12381876/animated_ped.zip.html

contains exe for simutrans/makeobj, and one pak/dat for an animated pedestrian by Leartin. I implemented now a parameter 'steps_per_frame', which controls the animation speed: for straight movement there are 256 steps per tile. Also animation will cross tile boundaries, as you can test by modifying steps_per_frame in the dat file.
Parsley, sage, rosemary, and maggikraut.

資源回收筒

Wow animated stuff in simutrans finally come out finally:D

Flemmbrav

#37
Heyo,

sorry for digging through the archives...

I tried to make this happen with a rail vehicle, but it doesn't seem to work.
Is there a way we could have this for rail vehicles as well?
I am aware of the train skipping frames being fast, I still would love to have this feature regardless.


----

Edit: adding to this: for the purposes I intend to use this, I'm expecting a very smooth animation more being limited with how detailed I'll draw it, rather than it being limited by the implementation in Simutrans.
I did some quick math with traveling time and wheel diameter on my recent steam loco, and it seems that there's plenty room to play with here.
Besides steam engines, this would add a lot to horses as well, which don't travel faster than our pedestrians anyways.



Yona-TYT

This is an old topic, but also very interesting 🙂 ;)