-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Animation Blending #5415
Animation Blending #5415
Conversation
Surprisingly straightforward. I'm not entirely sure how this fits into the broader plans in this area, but given the amount of added functionality relative to the complexity and the importance of Transform animation (which is likely going to end up special-cased) I'm inclined to merge this before the RFCs are in. |
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 now :) You can resolve all of my comments.
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.
While useful in its own right, this implementation is a bit shortsighted. This only supports a single linear transition between two clips, whereas the animation RFCs aim to support an arbitrary N-wise linear blend of multiple clips. This not only supports a transition between single clips, but also more complex blending structures like state machines, layered blends, or N-D blend trees.
Overall, I think we should prioritize reviewing and implementing the RFCs over extending the current animation player, which we've acknowledged was meant as a short term stopgap to ship with 0.7.
I totally agree. My line of thought was just to put it out there to provide an intermediary solution until the RFCs are implemented. So people like myself, that need at least some basic form of animation blending for their project, have something to work with. If you think it will somehow hinder the progress or is too much effort to review I would have no Problem with closing this PR for now. Since I am very new to bevy I trust your opinion on if this PR is worth it. |
Hi Mockersf, |
I am using Tracy: https://github.com/wolfpld/tracy. You'll need to enable Bevy feature |
I managed to get it down to a difference of about .1 ms on my machine. Would that be fine with you @mockersf ? |
This reverts commit 2a1218fefd0d3fbf142897d2c6aaf8abf0c68084.
@mockersf Just to check, is this PR still in consideration or should I just close it? |
Animation changed since this PR, and this feature should be covered by #6922 |
Objective
Solution
Extended the
AnimationPlayer
with a function:pub fn cross_fade(&mut self, handle: Handle<AnimationClip>, transition_time: f32) -> &mut AnimationTransition
This initiates a fade from the current to the provided animation.
The information about this "Transition" is stored in a the struct
AnimationTransition
and is added to theAnimationPlayer
.The
animation_player
system was adapted to handle this new data by interpolating the transforms of the targeted entities between the transforms of the keyframes of the current and target clip.Changelog
Added
AnimationTransition
: Representation of the data needed to transition from one to another animationChanged
AnimationPlayer
cross_fade()
functiontransition
fieldanimation_player
systemanimated_fox.rs
: Adapted example to be able to crossfade or normale play animations