Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API updates to the AnimationPlayer #9002

Merged
merged 31 commits into from
Aug 28, 2023

Conversation

DevinLeamy
Copy link
Contributor

@DevinLeamy DevinLeamy commented Jun 30, 2023

Objective

Added AnimationPlayer API UX improvements.

(Credits to @asafigan for filing #5848, creating the initial pull request, and the discussion in #5912)

Solution

  • Created RepeatAnimation enum to describe an animation repetition behavior.
  • Added is_finished(), set_repeat(), and is_playback_reversed() methods to the animation player.
  • Made the animation clip optional as per the comment from added some simple functions to AnimationPlayer #5912

My problem is that the default handle [used the initialize a PlayingAnimation] could actually refer to an actual animation if an AnimationClip is set for the default handle, which leads me to ask, "Should animation_clip should be an Option?"

  • Added an accessor for the animation clip animation_clip() to the animation player.

To determine if an animation is finished, we use the number of times the animation has completed and the repetition behavior. If the animation is playing in reverse then elapsed < 0.0 counts as a completion. Otherwise, elapsed > animation.duration counts as a completion. This is what I would expect, personally. If there's any ambiguity, perhaps we could add some AnimationCompletionBehavior, to specify that kind of completion behavior to use.

Update: Previously PlayingAnimation::elapsed was being used as the seek time into the animation clip. This was misleading because if you increased the speed of the animation it would also increase (or decrease) the elapsed time. In other words, the elapsed time was not actually the elapsed time. To solve this, we introduce PlayingAnimation::seek_time to serve as the value we manipulate the move between keyframes. Consequently, elapsed() now returns the actual elapsed time, and is not effected by the animation speed. Because set_elapsed was being used to manipulate the displayed keyframe, we introduce AnimationPlayer::seek_to and AnimationPlayer::replay to provide this functionality.

Migration Guide

  • Removed set_elapsed.
  • Removed stop_repeating in favour of AnimationPlayer::set_repeat(RepeatAnimation::Never).
  • Introduced seek_to to seek to a given timestamp inside of the animation.
  • Introduced seek_time accessor for the PlayingAnimation::seek_to.
  • Introduced AnimationPlayer::replay to reset the PlayingAnimation to a state where no time has elapsed.

@alice-i-cecile alice-i-cecile added C-Enhancement A new feature C-Usability A simple quality-of-life change that makes Bevy easier to use A-Animation Make things move and change over time labels Jun 30, 2023
@alice-i-cecile
Copy link
Member

@DevinLeamy the conflicts aren't trivial; could you resolve them so we can re-review and merge?

@DevinLeamy
Copy link
Contributor Author

@DevinLeamy the conflicts aren't trivial; could you resolve them so we can re-review and merge?

@alice-i-cecile I'm not seeing any conflicts?

@alice-i-cecile
Copy link
Member

Oops, I confused this with #5912!

@DevinLeamy
Copy link
Contributor Author

Updated to incorporate the changes from #5912.

Copy link
Contributor

@Pietrek14 Pietrek14 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@Shatur Shatur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove old repeat and stop_repeating methods or update their descriptions to point to specific RepeatAnimation.

@mockersf
Copy link
Member

I don't think the handle should be an option

@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

2 similar comments
@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

@github-actions
Copy link
Contributor

Example alien_cake_addict failed to run, please try running it locally and check the result.

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Aug 18, 2023
Co-authored-by: François <mockersf@gmail.com>
@alice-i-cecile alice-i-cecile added the C-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide label Aug 28, 2023
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Aug 28, 2023
Merged via the queue into bevyengine:main with commit db5f80b Aug 28, 2023
21 checks passed
@DevinLeamy DevinLeamy deleted the animation-api branch August 28, 2023 17:09
@cart cart mentioned this pull request Oct 13, 2023
43 tasks
github-merge-queue bot pushed a commit that referenced this pull request Nov 14, 2023
# Objective

After #9002, it seems that "single shot" animations were broken. When
completing, they would reset to their initial value. Which is generally
not what you want.

- Fixes #10480

## Solution

Avoid `%`-ing the animation after the number of completions exceeds the
specified one. Instead, we early-return. This is also true when the
player is playing in reverse.

---

## Changelog

- Avoid resetting animations after `Repeat::Never` animation completion.
cart pushed a commit that referenced this pull request Nov 30, 2023
# Objective

After #9002, it seems that "single shot" animations were broken. When
completing, they would reset to their initial value. Which is generally
not what you want.

- Fixes #10480

## Solution

Avoid `%`-ing the animation after the number of completions exceeds the
specified one. Instead, we early-return. This is also true when the
player is playing in reverse.

---

## Changelog

- Avoid resetting animations after `Repeat::Never` animation completion.
rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024
# Objective

Added `AnimationPlayer` API UX improvements. 

- Succestor to bevyengine#5912
- Fixes bevyengine#5848

_(Credits to @asafigan for filing bevyengine#5848, creating the initial pull
request, and the discussion in bevyengine#5912)_
## Solution

- Created `RepeatAnimation` enum to describe an animation repetition
behavior.
- Added `is_finished()`, `set_repeat()`, and `is_playback_reversed()`
methods to the animation player.
- ~~Made the animation clip optional as per the comment from bevyengine#5912~~
> ~~My problem is that the default handle [used the initialize a
`PlayingAnimation`] could actually refer to an actual animation if an
AnimationClip is set for the default handle, which leads me to ask,
"Should animation_clip should be an Option?"~~
- Added an accessor for the animation clip `animation_clip()` to the
animation player.

To determine if an animation is finished, we use the number of times the
animation has completed and the repetition behavior. If the animation is
playing in reverse then `elapsed < 0.0` counts as a completion.
Otherwise, `elapsed > animation.duration` counts as a completion. This
is what I would expect, personally. If there's any ambiguity, perhaps we
could add some `AnimationCompletionBehavior`, to specify that kind of
completion behavior to use.

Update: Previously `PlayingAnimation::elapsed` was being used as the
seek time into the animation clip. This was misleading because if you
increased the speed of the animation it would also increase (or
decrease) the elapsed time. In other words, the elapsed time was not
actually the elapsed time. To solve this, we introduce
`PlayingAnimation::seek_time` to serve as the value we manipulate the
move between keyframes. Consequently, `elapsed()` now returns the actual
elapsed time, and is not effected by the animation speed. Because
`set_elapsed` was being used to manipulate the displayed keyframe, we
introduce `AnimationPlayer::seek_to` and `AnimationPlayer::replay` to
provide this functionality.

## Migration Guide

- Removed `set_elapsed`.
- Removed `stop_repeating` in favour of
`AnimationPlayer::set_repeat(RepeatAnimation::Never)`.
- Introduced `seek_to` to seek to a given timestamp inside of the
animation.
- Introduced `seek_time` accessor for the `PlayingAnimation::seek_to`.
- Introduced `AnimationPlayer::replay` to reset the `PlayingAnimation`
to a state where no time has elapsed.

---------

Co-authored-by: Hennadii Chernyshchyk <genaloner@gmail.com>
Co-authored-by: François <mockersf@gmail.com>
rdrpenguin04 pushed a commit to rdrpenguin04/bevy that referenced this pull request Jan 9, 2024
# Objective

After bevyengine#9002, it seems that "single shot" animations were broken. When
completing, they would reset to their initial value. Which is generally
not what you want.

- Fixes bevyengine#10480

## Solution

Avoid `%`-ing the animation after the number of completions exceeds the
specified one. Instead, we early-return. This is also true when the
player is playing in reverse.

---

## Changelog

- Avoid resetting animations after `Repeat::Never` animation completion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Animation Make things move and change over time C-Breaking-Change A breaking change to Bevy's public API that needs to be noted in a migration guide C-Enhancement A new feature C-Usability A simple quality-of-life change that makes Bevy easier to use S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More erganomic AnimationPlayer API
6 participants