Let AnimationPlayer play clips without a graph

[greeble-dev]

Objective

Simplify playing animations when the full power of an AnimationGraph is not required - allow the user to skip creating a graph and instead pass AnimationClip assets directly to AnimationPlayer.

Why A Draft?

I think this PR is a failure. I'm submitting it anyway in case that leads to discussion, or someone wants to try adapting the design.

Background

In Bevy 0.13, users played animations by passing a Handle<AnimationClip> to various play functions in AnimationPlayer. Bevy 0.14 added AnimationGraph - now users create a graph with clip nodes that reference a Handle<AnimationClip>, and pass an AnimationNodeIndex to AnimationPlayer.

This change gave users more power, but also made some simple cases more complex - often users just want to play a single animation, or play a simple blend into a transition then loop.

Solution

The PR changes various AnimationPlayer functions to take an AnimationRef enum, which is either an AnimationNodeIndex or a Handle<AnimationClip>.

- pub fn play(&mut self, animation: AnimationNodeIndex) -> &mut ActiveAnimation {
+ pub fn play(&mut self, animation: impl Into<AnimationRef>) -> &mut ActiveAnimation {

The interface is backwards compatible. If the user creates an AnimationGraph and plays an AnimationNodeIndex then everything works as before. But if they create a graph and then play a Handle<AnimationClip> then it's silently ignored.

If the user skips creating a graph, they can play a Handle<AnimationClip> directly. Currently only a single clip is supported, so there's no blending or transitions - play just replaces the current clip. If the user plays a AnimationNodeIndex and there's no graph then it's silently ignored.

Why Is This A Failure?

The PR succeeds at simplifying some cases. But in practice I expect users will find it fragile and confusing - if they're using a graph and play an AnimationClip then it will be silently ignored, and vice versa.

The implementation is messy as it has to support both things at once, even though in practice only one will be used. And adding support for blends between multiple clips will be awkward - does that mean AnimationTransitions now needs a whole parallel implementation as well?

TLDR: Jamming two different approaches into one AnimationPlayer doesn't feel like a sustainable path.

Are There Alternatives?

What if AnimationPlayer is left unchanged and a separate AnimationClipPlayer component is added for playing clips directly? That's a bit awkward for users and has some open questions - e.g. which component does bevy_gltf create? And it leaves bevy_animation with two competing implementations.

Another solution is to keep bevy_animation unchanged, and instead have bevy_gltf automatically create a default AnimationGraph with all the animations in the file. The user can then leave that graph unchanged if it's sufficient, or replace it with their own. The problem is that the user still needs to work out which of their clips corresponds to which AnimationNodeIndex.