Adding new tweens to existing ones

[musjj]

Let's say I have an entity that is set up with a tween targeting the entity's transform.rotation. The tween loops infinitely throughout the game.

But I also want to have a system that can insert a new tween that targets said entity's transform.scale, depending on the state of the game. The tween loops only once. I also want to be able to replay that tween, depending on the game state.

The problem is that this requires you to put more than one Animator<Transform> component on the entity, which is currently not possible in Bevy. Is there a good solution for this use-case?

[meepleek]

You could use tracks, but you'd have to recreate the looping tween which would be tedious.
A simple-ish approach would be to add a wrapper that can have it's own animator which can do the rotation.

[guyguy2001]

A similar need I have (I'm not sure if this should go here or in a new issue) is to tell a tween to run after the current tween.
So for example, when my player is hit, I want them to flash red, and afterwards start animating their alpha to indicate an invulnerability state.
(This might not be the correct way to approach the problem, I'm not sure yet).

To do this I need one of the following:

• A .then(self, &tween) method on the Tweenable trait, and a way of owning animator.tweenable() in order to be able to call it (since Sequence::then only accepts an owned self, not a reference)
• A .then method on the animator itself (which will probably use the .then I suggested)
• A way of passing animator.tweenable() into Sequence::from_single (or ::new or the likes).

I also need a way to know when the current animation will end - but I think I can get that via the existing total_duration, which seems great

The second option is probably the best one, but I'm too new to writing APIs in rust to have a clear idea.
Also, I could see a world in which it is just a bad idea to allow enqueuing more animations from the outside.

[djeedai]

@musjj sorry I completely missed this issue.

The problem is that this requires you to put more than one Animator component on the entity, which is currently not possible in Bevy. Is there a good solution for this use-case?

Yes indeed. So you're stuck with a single animator, unless you can reparent your scaled object to an invisible rotating one? If not, then the way I'd approach it in this case given the two animations are widely different is to put the logic into a custom Lens, where you always apply the rotation, and conditionally apply the scaling when needed. You will need to use some form of Arc to share the lens (or some of it's fields) with the animator. And it's a bit awkward if the scaling doesn't start in sync with the rotation nor has the same duration, but you can figure some delayed t value inside the lens from the first time the scaling is activated I think. Definitely more complex than it should, but I don't see a good solution at least until we have dynamic queries in Bevy ECS.

[djeedai]

@guyguy2001

So for example, when my player is hit, I want them to flash red, and afterwards start animating their alpha to indicate an invulnerability state.

I'm not sure I understand. It seems that you want to animate first the color and then the alpha of the same material or sprite? If so, you can just use Tracks and enqueue two Tweens one after the other.

If, on the other hand, you're trying to execute a tweenable on one Animator and synchronize it with another tween on a different Animator, then yes there's no good built-in solution for this. One workaround I can think of is if you know the duration of each individual tweenable, you can insert delays to indirectly synchronize them based on time.

[musjj]

I think a simple solution would be to allow Animator to target an entity other than itself. For example:

Animator::new(tween).with_entity(entity)

This way you can just spawn multiple animator entities targeting the entity you want. This is similar to the approach used by bevy_tween, except that it traverses up the parent hierarchy until it finds a target marker.

[jim-ec]

I have run into the same issue.

I am controlling the rotation and zoom of a camera with four keyboard keys - two for adjusting the yaw angle and two for adjusting the zoom level. Both parameters are discrete, but I want to tween between steps.

In my camera update system, I listen for keystrokes and generate tweens accordingly. I have also implemented two lenses: one for rotation and one for zoom.

The problem, as stated above, is that I can only have a single animator per component, which in turn can only have a single tweenable. Of course, I could wrap both the rotation and zoom tweens in a tracks tweenable, but I only generate these tweens on keystrokes. Tracks are really designed for situations where you have all your tweens available at the time of constructing the tracks. I could simply overwrite the tweenable, but that would interrupt any previous tween, which is noticeable if it hasn’t completed yet. I could try to wrap the existing tween with the new one in a track, but that would mean the camera object would get larger and larger at runtime. Also, this approach feels a bit awkward.

In my opinion, the best approach would be to make the animator a bit more stateful; for example, by adding something like a push_tweenable() method that starts a new tweenable. However, that would require reimplementing some of the logic of tracks.

[djeedai]

@jim-ec the problem you describe is somewhat different from the original one. The limitation of one animation per component type is real, and will be lifted soon. However, this won't solve your issue. What you want is a tween animation that starts not from a defined point but from the current Transform state. This is not too difficult to make with a custom lens, or even with a built-in one, if you re-insert a new Tween with the lens start point recalculated from the current Transform, which you should have access to via a system. It's admittedly a bit verbose but it works, I've done it and seen others doing it too.

I'm not sure what you're asking with push_tweenable(). It sounds like you want to enqueue a new animation after the current one completed. In your case where the animations are triggered by keystrokes, this is a recipe for disaster, because as soon as the user starts pressing keys faster than the animations last, you start a spiral of death enqueuing animations faster than they're completed. In addition, from a UX perspective, zooming once and then zooming a second time while the first zoom is animating should not result in 2 animations back-to-back, because that means if I zoom 4 times it takes 4x more time for the camera to reach the zoom level. Instead the better way in my opinion is to recalculate a new tween from the current zoom to the target one, which always animates in roughly (or even exactly) the same amount of time. Users like to see animations, but will very quickly get annoyed if they're too slow. If I didn't understand what you meant or there's another use case please feel free to describe it, there might be a good use for that push_tweenable(), but for now I don't see one.