-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Conversation
@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? |
Oops, I confused this with #5912! |
Updated to incorporate the changes from #5912. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this 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
.
I don't think the handle should be an option |
Example |
2 similar comments
Example |
Example |
Co-authored-by: François <mockersf@gmail.com>
# 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.
# 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.
# 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>
# 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.
Objective
Added
AnimationPlayer
API UX improvements.AnimationPlayer
API #5848(Credits to @asafigan for filing #5848, creating the initial pull request, and the discussion in #5912)
Solution
RepeatAnimation
enum to describe an animation repetition behavior.is_finished()
,set_repeat()
, andis_playback_reversed()
methods to the animation player.Made the animation clip optional as per the comment from added some simple functions to AnimationPlayer #5912animation_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 someAnimationCompletionBehavior
, 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 introducePlayingAnimation::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. Becauseset_elapsed
was being used to manipulate the displayed keyframe, we introduceAnimationPlayer::seek_to
andAnimationPlayer::replay
to provide this functionality.Migration Guide
set_elapsed
.stop_repeating
in favour ofAnimationPlayer::set_repeat(RepeatAnimation::Never)
.seek_to
to seek to a given timestamp inside of the animation.seek_time
accessor for thePlayingAnimation::seek_to
.AnimationPlayer::replay
to reset thePlayingAnimation
to a state where no time has elapsed.