-
-
Notifications
You must be signed in to change notification settings - Fork 21.2k
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
Cyclic BlendSpaces [1D/2D] for Animation #34179
Conversation
20d4d30
to
c30eb28
Compare
Updated for current master branch |
Updated for 4.0 |
58f91b3
to
cf8de21
Compare
Probality not working with |
@SuperDIMMaX do you have a sample project I can check? |
|
@marstaik Are you ok with me taking this over? You can keep the pr open and I can modify your branch. |
Yeah, that's fine. :) |
@TokageItLab Is this still valid? |
Closing based on above comment. |
Note: Depends on #34134, as the blends are even more broken without it.
This PR aims to do some bugfixing for blendspaces as well as introduce the concept of Cyclic BlendSpaces.
There was some previous discussion of this here: #23414
Coming from other game engines, this is really a crucial and useful component for animation.
These cyclic BlendSpaces are very important for blending in animations whose timescale is supposed to match, such as movement animations, look-at animations, breathing animations, etc...
Currently they only support AnimationNodeAnimation's, since its currently the only way to reliably obtain an AnimationNodes runtime length, which is a hard requirement.
If AnimationNode's had a common interface where each node could return its computed runtime length, then any node could be used in the future, but that is a ton of work and maybe not as crucial for Cyclic BlendSpaces anyways.
Here is a Demo:
https://f.staik.net/f/2de.mp4