Support playing from current elapsed/seek_time

[PraxTube]

I need to play a different animation but from the same current frame (seek_time internally, also probably the same elapsed). If I just use the current play then I will get the following behaviour.

incorrect.mp4

So the simplest solution I can think of is to just add function that will play a different animation but from the same current frame. I added it in a rough way here.

Though I am curious, what do you think of this? Maybe I am running into an X-Y-Problem here. You think this would be a useful feature or is that just me overcomplicating it again?

This is how I want it to behave.

correct.mp4

It doesn't look much better, but that is a different problem. It does fix the "clippiness" of the animation. Of course you would want to actually check if the seek_time even makes sense, i.e. if the duration is the same or greater than that of the previous animation and then handle the case for when it isn't (I guess an error and a fallback to 0.0 seek_time would be alright?).

[KirmesBude]

It is definitely a viable use case. It can't be the default way and the problem I see is what will calling it look like on your side? Because you need to know the current animation as well - I assume you don't want to keep the frame/seek_time going from a punch to walking.

I wonder if we may be able to look at this from a different point: In your example it looks like what you want to do is switch between "directions". I have been toying with doom style 3d sprites and the plan there was to handle it in parallel to animations.
So I have a single animation for walking - not one for each direction. Do you mind elaborating on how you handle this currently and what assets this relates to in your project?

[PraxTube]

Yeah it definitely shouldn't be the default, and you are right that I am saving the previous animation (I needed this for other reasons too, so it was already in place).

if animation_state == enemy.state_machine.animation_state() {
    animator.play_continue(animation).repeat();
} else {
    animator.play(animation).repeat();
}

the actual code, with the animation state

#[derive(Default, Clone, Copy, PartialEq)]
pub enum EnemyAnimations {
    #[default]
    Idle,
    Run,
    ...
}

it really isn't pretty, but I couldn't think of a more elegant solution. I am really curious what you mean with 3d sprites, from what I understand the model is in 3d and gets rendered into sprites with pre-defined angles? Because that is exactly what I am using, I don't quite understand how you can have a single animation for multiple directions (at least in a 2D setting with spritesheets).

It's a lot easier to show my pipeline in a video though, so I recorded a short one: https://rancic.org/pipeline-showcase.mp4

[KirmesBude]

I am happy to merge your proposal if you open a PR :). Seems useful either way and there is no reason to rework everything if it already works for you.

I am actually doing the complete opposite of what you are doing. My whole scene is 3d, I just have some elements that are flat planes always facing the camera and changing the image based on entity and camera orientation. I suppose the images could be rendered from a 3d model, but I was thinking hand drawn.
Didn't expect a little presentation video, but it is greatly appreciated :D.

So the way I was thinking about doing the direction in parallel to animations:

• The assets/spritesheets are grouped by direction instead of by animation - one for each direction.
• Each direction spritesheet has the same layout.
• You just change the Handle based on direction. The animation is still valid because the indices/seek_time map to the same frame of the same animation.

It is a bit more complicated for me, because I want to support multiple cameras, so I would have to use texture array and handle it in the shader. But for a 2d scene, you should be able to get away with straight up changing the handle in your application code.

[PraxTube]

I am happy to merge your proposal if you open a PR :). Seems useful either way and there is no reason to rework everything if it already works for you.

Alright cool, will work on that tomorrow then. There are still some things like how to handle errors with mismatching durations, but I will just do what I feel like is right and then you can review and we can discuss that in the PR.

My whole scene is 3d, I just have some elements that are flat planes always facing the camera and changing the image based on entity and camera orientation.

Ah, yeah I really wanted to avoid 3d at all costs and pre-rendering the assets kinda gets me the best of both worlds while still being fairly manable to implement.

The assets/spritesheets are grouped by direction instead of by animation - one for each direction.

Oh dang that is really good yo. It would even allow me to further optimize the images for size! I am already changing the image handles (though based on animation not direction), so that would be pretty easy to implement. Thanks man, that is really helpful :D OH and it would even make all the animation data in the trickfilm file redundant, so I would only need a single one per animation, that's really elegant!

It is a bit more complicated for me, because I want to support multiple cameras, so I would have to use texture array and handle it in the shader.

That sounds quite a bit more complicated. Why do you need multiple cameras? For something like multiplayer or different reasons?

[KirmesBude]

It is a bit more complicated for me, because I want to support multiple cameras, so I would have to use texture array and handle it in the shader.

That sounds quite a bit more complicated. Why do you need multiple cameras? For something like multiplayer or different reasons?

I like to over engineer stuff :D But also gives me a reason to learn more about how shaders work.

[PraxTube]

Haha yeah I get that. I tried to get into shaders a couple of times now but it never really works out. I also dislike how poor the sprite implementation for wgsl is, even adding an outline to a sprite is a pain in the ass. Maybe it's just a skill issue though ¯\_(ツ)_/¯