Animation Composition #51

james7132 · 2022-02-22T17:00:14Z

This RFC is an extension of #49, detailing the low level details on how to compose the base primitives for more complex animations together via blending. This RFC stops short of the final step of applying the sampled values to the target animated properties, as that is separate and can be handled regardless of how the values are composed or sampled.

~~This will remain a draft until #49, or some variant of it that covers the same subject matter, gets merged.~~ This looks like it might be easier to implement than the actual storage solution.

aunyks · 2022-05-08T20:03:13Z

I’d love to have this feature so that I can blend multiple glTF animations.

ValorZard · 2022-05-29T04:11:10Z

Since Bevy doesn't currently have an editor, or any official debug UI for that matter, how would a user manipulate the animation state tree? In Unity and Godot, there is a fancy visual scripting editor that lets you build a animation graph quite easily, but I could see that becoming quite unwieldy in code. This wouldn't be a problem once we have an actual editor, but for the time being, managing an animation state machine could become quite troublesome.

james7132 · 2022-11-22T04:17:59Z

Since Bevy doesn't currently have an editor, or any official debug UI for that matter, how would a user manipulate the animation state tree? In Unity and Godot, there is a fancy visual scripting editor that lets you build a animation graph quite easily, but I could see that becoming quite unwieldy in code. This wouldn't be a problem once we have an actual editor, but for the time being, managing an animation state machine could become quite troublesome.

I agree here. While we're missing the editor tools for this, I would like to add some tooling that is similar to the current AnimationPlayer to make it easy to just use it as is, but ultimately this graph is supposed to be a low level primitive, not a high level interface. We'll need to rip off that band-aid eventually.

cart

I think this is the right general direction!

rfcs/51-animation-composition.md

cart · 2022-12-12T21:55:22Z

rfcs/51-animation-composition.md

+
+Every node has it's own time value. For clip nodes, this is the time at which the
+underlying clip is sampled at. For blend nodes, this value doesn't do anything.
+However, an optional setting will allow a blend node to propagate the time value


What scenarios does this enable? Does this pattern exist in prior art? To my knowledge, Godot doesn't allow blend nodes to override time, and given that each animation will be playing at its own cadence, does the propagated value even have any meaning in this context?

Also is this "delta time" or "absolute time". Maybe worth clarifying in the language?

The first common use case that I can think of is "any-time-after" transitions. Where a transition from a source animation is triggered automatically after a fixed time point has passed. That source animation will continue from the same time it had before, but the new animation it's transitioning to will start at zero. Both will advance at their own respective time scales while the transition blends smoothly from the source to the destination. While this is notably very low level, this can be used to build smooth transitions for a state machine like flow at a higher level.

For the propagation, this is largely just a QoL feature for letting you advance an entire subgraph at once.. Micromanaging every clip remotely can get rather crazy, so this is mainly offered as a way to avoid needing to set the tme manually across an entire subgraph. We could remove this given that the intent of this is to provide low level animation blending support, not a high level control.

It should be absolute time for the underlying clip. The delta in how each clip is advanced is scaled based on the global, graph level, and clip level time scales. I'll add this into the actual document itself.

For the propagation, this is largely just a QoL feature for letting you advance an entire subgraph at once..

Yeah I think the propagation part might be too "high level" and opinionated at this stage in the game. Useful for some scenarios and not others, "invalid" in some cases (scrubbing results in going "outside" the duration bounds of one animation but not the other, animations are configured to progress at different rates / times, etc). And the behavior (when needed) can be implemented reasonably easily using existing features (ex: for_each_child_node(parent_node, |child| child.set_time(time))

(or for_each_descendant_node)

When reading the preceding paragraph, I had this question: "This seems to try to enable composition, but why a graph system would improve on a simple weight-based approach?"

And this sentence comes in. It gives a feature that is impossible to accomplish without graphs: namely: putting a bunch of animations together and having the capacity to control them exactly like if they were only a single animation.

In this context, I think having time control on blend nodes is really useful.

rfcs/51-animation-composition.md

# Objective - Fixes #6338 This PR allows for smooth transitions between different animations. ## Solution - This PR uses very simple linear blending of animations. - When starting a new animation, you can give it a duration, and throughout that duration, the previous and the new animation are being linearly blended, until only the new animation is running. - I'm aware of bevyengine/rfcs#49 and bevyengine/rfcs#51, which are more complete solutions to this problem, but they seem still far from being implemented. Until they're ready, this PR allows for the most basic use case of blending, i.e. smoothly transitioning between different animations. ## Migration Guide - no bc breaking changes

# Objective - Fixes bevyengine#6338 This PR allows for smooth transitions between different animations. ## Solution - This PR uses very simple linear blending of animations. - When starting a new animation, you can give it a duration, and throughout that duration, the previous and the new animation are being linearly blended, until only the new animation is running. - I'm aware of bevyengine/rfcs#49 and bevyengine/rfcs#51, which are more complete solutions to this problem, but they seem still far from being implemented. Until they're ready, this PR allows for the most basic use case of blending, i.e. smoothly transitioning between different animations. ## Migration Guide - no bc breaking changes

nicopap

This looks good to me. I don't have any particular concerns.

Just a bit of confusion on why sampling is necessarily exclusive.

rfcs/51-animation-composition.md

nicopap · 2023-04-19T07:23:43Z

rfcs/51-animation-composition.md

+}
+```
+
+The individual curves stored within are indexed by `ClipId`, and each pointer to


I was wondering earlier why we needed ClipId. This explains it.

rfcs/51-animation-composition.md

nicopap · 2023-04-19T08:02:57Z

rfcs/51-animation-composition.md

+assigned a auto-imcrementing `ClipId` much like `NodeId`. However, instead of
+storing a `Vec<AnimationClip`, a map of property paths to `Track` is stored.


I would suggest adding a "this is explained in the 'Bindings' section". I didn't understand what "map of property paths to Track" meant until I read it (ie: the GraphBindings struct)

nicopap · 2023-04-19T08:03:39Z

rfcs/51-animation-composition.md

+
+### Graph Storage
+Two main stores are needed internally for the graph: node storage and clip
+storage. Nodes are stored in a flat `Vec<Node>`, and a newtyped `NodeId` is used


I don't understand what properties a Node stores. A list of dependencies and weights?

a node is either a blend node or a clip node. they would have dependencies, time setting, a clip

nicopap · 2023-04-19T08:05:14Z

rfcs/51-animation-composition.md

+clip C is 0.125. If multiple paths to a end clip are present, the final weight
+for the clip is the sum of all path's weights.
+
+After traversing the graph, the weights of all active inputs are clamped and


what does "active inputs" mean in this context? Are those the weight field of Influences?

nicopap · 2023-04-19T08:07:16Z

rfcs/51-animation-composition.md

+}
+
+struct GraphInfluences {
+    influence: Vec<Influence> // Indexed by BoneId


Indexed by BoneId

Is this true? The paragraph that directly follows say

This is effectively a Vec<f32> indexed on ClipId mapping clips and their respective cumulative weights.

nicopap · 2023-04-19T08:09:41Z

rfcs/51-animation-composition.md

+ - maintaining the binding components is going to be a nightmare if there are
+   any hierarchy or name changes underneath an `AnimationGraph`.


The current system has a path cache right? Why would that be impossible to establish in the graph-based system? How is maintaining the cache less of a nightmare? It should have the same limitations.

The path cache is just a cache. It's not treated as a source of truth, just a opportunistic way to reduce expensive searching. The binding mentioned here is more akin to relations and would have to be treated as a source of truth to get the full benefits, and that has the same mire of edge cases are still being worked out for the hierarchy.

Co-authored-by: Nicola Papale <[email protected]>

mockersf · 2023-05-13T20:04:59Z

rfcs/51-animation-composition.md

+clip C is 0.125. If multiple paths to a end clip are present, the final weight
+for the clip is the sum of all path's weights.


the final weight for the clip is the sum of all path's weights.

Shouldn't it be the average? Is there a risk of a weight greater than 1?

I think it's not well mentioned here, but the final results are after normalizing the entire weight vector so that the sum of all weights is 1.0, even if a final weight is over 1.0, it's influence will still be proportional to the rest of the clips that are in the graph.

mockersf · 2023-05-13T20:16:19Z

is bevyengine/bevy#7130 usable for this graph?

mockersf · 2023-07-17T22:57:35Z

@cart are you OK to move forward with this RFC? In my opinion there are a few minor questions, but they should be answered when going for the implementation

cart

I'm happy with where this is at. I think this is a solid first step for animation composition!

james7132 · 2023-07-18T01:11:31Z

I know this is already merged, but I wanted to close out a few last loose ends.

is bevyengine/bevy#7130 usable for this graph?

I haven't fully reviewed that PR yet, but my impression is no. The construction I had in mind does not involve many HashMap lookups of any kind and the traversal really only needed jumping around a few items in a Vec<Node>, which should be exceptionally fast to evaluate multiple times per game tick. Though I don't think this would preclude us from including this variant of a graph in bevy_graph though.

# Objective Allow animation of types other than translation, scale, and rotation on `Transforms`. ## Solution Add a base trait for all values that can be animated by the animation system. This provides the basic operations for sampling and blending animation values for more than just translation, rotation, and scale. This implements part of bevyengine/rfcs#51, but is missing the implementations for `Range<T>` and `Color`. This also does not fully integrate with the existing `AnimationPlayer` yet, just setting up the trait. --------- Co-authored-by: Kirillov Kirill <[email protected]> Co-authored-by: François <[email protected]> Co-authored-by: irate <[email protected]> Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: Alice Cecile <[email protected]>

Start bevyengine#51: Animation Composition

3f3ed51

james7132 changed the title ~~Start #51: Animation Composition~~ Animation Composition Feb 22, 2022

james7132 mentioned this pull request Feb 23, 2022

Tracking Issue: MVP Animation bevyengine/bevy#4026

Open

14 tasks

alice-i-cecile mentioned this pull request Apr 13, 2022

[Merged by Bors] - news: release 0.7.0 bevyengine/bevy-website#334

Closed

mockersf mentioned this pull request Sep 14, 2022

Add NameLookup Type to make looking up entities by name easier bevyengine/bevy#5976

Closed

james7132 mentioned this pull request Nov 12, 2022

Multiple Animations on the same Mesh/Skeleton which can run Simultaneously. bevyengine/bevy#6562

Closed

Update with more pseudo-code

5a0d211

james7132 marked this pull request as ready for review November 22, 2022 04:11

james7132 added 11 commits November 21, 2022 20:32

Further document alternatives

8a2cf58

Link potential optimizations

db0977c

Make note about caching ComponentIds

d6c1475

Mention Fyrox's animation implementation

9dfc3fe

Mention the fastpath for Transform animation

bdbc006

Update goals

d6f4690

Add example visual of a graph

7ee44a2

Fix visual

cbb816a

Add missing link

d774886

Reverse graph flow to better show input/output relationship

cf46cfc

Add missing link

6e70b67

This was referenced Nov 28, 2022

[Merged by Bors] - Parallelize forward kinematics animation systems bevyengine/bevy#6785

Closed

RFC: Improve performance of AnimationPlayer. bevyengine/bevy#6821

Closed

smessmer mentioned this pull request Dec 12, 2022

[Merged by Bors] - Smooth Transition between Animations bevyengine/bevy#6922

Closed

cart reviewed Dec 13, 2022

View reviewed changes

james7132 added 5 commits April 18, 2023 11:21

Copy over the Animatable trait from the primitives RFC

d497153

Switch to transform only target

d06e58a

Typo

29138a5

More typo

f7a6c12

Add section about masked blending

672aef4

nicopap reviewed Apr 19, 2023

View reviewed changes

james7132 and others added 2 commits April 19, 2023 09:47

Remove mention of exclusive systems

a39e098

Apply suggestions from code review

00180aa

Co-authored-by: Nicola Papale <[email protected]>

james7132 requested a review from mockersf May 7, 2023 02:04

mockersf reviewed May 13, 2023

View reviewed changes

cart approved these changes Jul 18, 2023

View reviewed changes

cart merged commit 658472f into bevyengine:main Jul 18, 2023

james7132 mentioned this pull request Sep 30, 2023

Animatable trait for interpolation and blending bevyengine/bevy#4482

Merged

pcwalton mentioned this pull request Feb 3, 2024

Implement minimal animation graphs in order to support animation blending. bevyengine/bevy#11670

Closed

james7132 mentioned this pull request Feb 7, 2024

Rework animation to be done in two phases. bevyengine/bevy#11707

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Animation Composition #51

Animation Composition #51

james7132 commented Feb 22, 2022 •

edited

Loading

aunyks commented May 8, 2022

ValorZard commented May 29, 2022

james7132 commented Nov 22, 2022 •

edited

Loading

cart left a comment

cart Dec 12, 2022

james7132 Dec 14, 2022 •

edited

Loading

cart Dec 15, 2022

cart Dec 15, 2022

nicopap Apr 19, 2023

nicopap left a comment

nicopap Apr 19, 2023

nicopap Apr 19, 2023

nicopap Apr 19, 2023

mockersf May 13, 2023

nicopap Apr 19, 2023

nicopap Apr 19, 2023

nicopap Apr 19, 2023

james7132 Apr 19, 2023

mockersf May 13, 2023 •

edited

Loading

james7132 Jul 18, 2023

mockersf commented May 13, 2023

mockersf commented Jul 17, 2023

cart left a comment

james7132 commented Jul 18, 2023

		assigned a auto-imcrementing `ClipId` much like `NodeId`. However, instead of
		storing a `Vec<AnimationClip`, a map of property paths to `Track` is stored.

		- maintaining the binding components is going to be a nightmare if there are
		any hierarchy or name changes underneath an `AnimationGraph`.

		clip C is 0.125. If multiple paths to a end clip are present, the final weight
		for the clip is the sum of all path's weights.

Animation Composition #51

Animation Composition #51

Conversation

james7132 commented Feb 22, 2022 • edited Loading

aunyks commented May 8, 2022

ValorZard commented May 29, 2022

james7132 commented Nov 22, 2022 • edited Loading

cart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

james7132 Dec 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicopap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mockersf May 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mockersf commented May 13, 2023

mockersf commented Jul 17, 2023

cart left a comment

Choose a reason for hiding this comment

james7132 commented Jul 18, 2023

james7132 commented Feb 22, 2022 •

edited

Loading

james7132 commented Nov 22, 2022 •

edited

Loading

james7132 Dec 14, 2022 •

edited

Loading

mockersf May 13, 2023 •

edited

Loading