rfcs
rfcs copied to clipboard
bevyengine
Animation Composition
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.
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.
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 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
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.