Make AnimationPlayer a relationship

[janhohenheim]

What problem does this solve or what need does it fill?

Dealing with animation in practice is very verbose. Usually, people spawn glTF scenes that they want to animate. However, the animation player is buried somewhere in the hierarchy! This means that lots of users set up boilerplate observers that add some kind of manual AnimationPlayerLink(Entity) to the scene root

What solution would you like?

Make a scene's animation players a 1:n relationship

What alternative(s) have you considered?

• keep the manual boilerplate
• introduce a new system parameter that fetches the right animation players
• Move the animation players up the hierarchy into a vector at the scene root
• Rethink how the animation player API / hierarchy works in general
• Add a convenience API to scenes with only a single animation player

[beholdnec]

I recall there was another issue submitted previously that said playing an animation is too complicated, leading to some discussion. I can't find the issue anymore.

I wish we could simply write model.play("animation name") , and leave the AnimationGraph stuff for more advanced scenarios.

[joscha-alisch]

I'm starting to look into this and think that we can't directly make AnimationPlayer a relationship, as it is required to be mutable for playing animations - and relationships are required to be immutable.

Instead, I think there should be a new relationship that can then be used to query the AnimationPlayer itself?

So something like this:

#[derive(Component)]
#[relationship(relationship_target = AnimatedBy)]
struct Animates(Entity);

#[derive(Component)]
#[relationship_target(relationship = Animates)]
struct AnimatedBy(Vec<Entity>);

// taken from the animated fox example
fn play_animation_when_ready(
    trigger: Trigger<SceneInstanceReady>,
    root: Query<(&AnimationToPlay, &AnimatedBy)>,
    mut player_query: Query<&mut AnimationPlayer>,
) {
    if let Ok((animation, animated_by)) = root.get(trigger.target()) {
        for animates in animated_by.0.iter() {
            if let Ok(mut player) = player_query.get_mut(*animates) {
                // play the animation
            }
        }
    }
}

This is my first time looking into contributing to bevy ecs, so I might be completely off track :)

[joscha-alisch]

For the record: Had some conversation around naming on discord and @janhohenheim pointed me to AnimationPlayers(Vec<Entity>) and AnimationPlayerOf(Entity) being a better naming scheme than the one I put above (mirroring Children and ChildOf).

[joscha-alisch]

I've done some investigation on actual implementation now and would like some thoughts on where the spawning of this relationship should happen. I see a couple of options at the moment.

1. Add the relationship spawn during gltf loading, which seems to be the most straightforward solution. When we spawn an animation player, we also spawn this relationship. There are however two problems with this approach:
   • The relationship would only exist if a scene (and animation player) is loaded through gltf and not when it's for example manually added or loaded through a different asset loader. Not sure if this is something that would happen often in reality though.
   • As far as I can see, the gltf loader only knows about the entities below the scene root, not the scene root itself. Adding AnimationPlayerOf(world_root_id) in loader/mod.rs#915 adds the relationship between the AnimationPlayer entity and the child of the SceneRoot entity. So this means that in user systems, they would again need to first query the child of the scene root and only then get to the animation player query. So not a lot that we gain here.
2. A new system in either bevy_animation or bevy_scene crate. We could listen for Added<AnimationPlayer> and go up the hierarchy until we find a SceneRoot. Problem here is that bevy_animation would be coupled with bevy_scene, or the other way around. Neither of those dependencies exist at the moment.

Thoughts on this @janhohenheim @alice-i-cecile ? Another option I've missed?

[janhohenheim]

It seems logical to me that animation and scene would be coupled, personally. So I would have gone for number 2.
But I have no stake in the underlying architecture, so take this with a huge grain of salt :)