Feedback

[NovemberDev]

Hello,

I'm amazed by how good this technology is and I see massive potential in an area that leaves creative freedom in designing animations to the user: animation transitions.

In games, 2D animations stutter from one action to the other, where sudden stops in movement can look unnatural when there is no blending or inbetweening happening on the pixel level. Since blending can't really be done in 2D (at least what I know of), a good approach would be to let the computer calculate the inbetween frames (between finished animations, not the animations themselves) to "supplement" the sprite sheet instead of replacing what is in it, already. The final step would be to seemlessly integrate this as a datastructure into existing engines, where you don't even have to do the bookkeeping of which frames should go between what actions.

That way you don't go against the principles of animation (scale, stretch, tension, suspense) and leave the necessary control to the artist.

What do you think about this idea?

[Bauxitedev]

Thank you for your response!

If I'm reading your post correctly, you're suggesting an animation blending system, where transitions from one animation to another become smooth, is that correct? E.g. in a platformer, if you jump while running, the transition from the "running" animation to the "jumping" animation gets smoothed out?

That's indeed an interesting idea, although there are a few practical problems. E.g. would you store all inbetweens beforehand? Or calculate them on the fly?

In the former case, you would have to calculate inbetweens for a very large possible amount of combinations: e.g. every frame from the "running" animation would need to have at least one inbetween frame to the starting frame of the "jumping" animation. This may take an exponential amount of storage, especially when you add even more animations, like "idle", "shooting", "crouching", etc.

On the other hand, calculating them on the fly is probably too slow: you may have noticed that Bitmapflow sometimes takes quite a lot of time to generate all the inbetweens. This is because the optical flow algorithm is quite slow, probably too slow to use in real time.

In conclusion, I think the idea is really cool, but I'm not sure how you'd go about doing it in practice.