Managing animation(s)

[zachernuk]

Many model formats have the ability to contain multiple animation tracks, with the expectation that assets will undergo "animation blending" Example in three.js

I would like to see shipping implementations initially support a single animation track played in an MVP only. But, I also believe that we should aim to support multiple animations in the future. The single-track conceptual model is supported by a top-level API for duration, play()/pause(), etc - that's not going to be adequate to manage a multi-track system.

Do we have an analog in other feature development to follow here?

[zachernuk]

/tpac

[zachernuk]

I believe the outcome of the discussion was that the root model element attributes and methods relate to a "root/master" timeline for a model, and if/when we get to the ability to present multiple animations, this leaves us room to create additional API capability to account for them without having to remove the root object's relationship to the concept of animation.

Does that sound accurate? @cabanier @LaszloGombos ? If so we can work out how to get this into the explainer or spec or both!

[mkeblx]

I think this would be highly useful, alongside the current animation API that would continue to exist.

Something like the below, string or index methods?

model.playAnimation('move'); // by name
model.pauseAnimation(1); // by index
model.stopAnimation('nan');
model.getAnimationDuration('move');
model.loopAnimation('move', true);
model.setAnimationRate('move', 1.5);

That could be a little verbose, and instead we could have an animations array.

dictionary Animation {
  DOMString name;
  double duration;
  double playbackRate;
  double currentTime;
  boolean loop;
};

interface ModelElement : HTMLElement {
  readonly attribute sequence<Animation> animations;
};

const move = model.animations.find(a=>a.name==='move');
move.pause();
move.currentTime = move.duration / 2;
move.loop = true;

btn.onclick =() => { move.paused ? move.play() : move.pause() };

@zachernuk

[AdaRoseCannon]

/agenda this would be a good thing to talk about next week

[zachernuk]

This is exciting! Would you propose that only one animation plays at a time, or would you expect to immediately pursue an animation mixer / blending system?

e.g. having "walk" play at 25% weight at 50% speed while simultaneously playing "run" at 75% and 30% speed. I see that as more ambitious but could be managed further in the future, if we can find a way to make earlier work compatible with the more elaborate capabilities further off.

[mkeblx]

While even one at a time would be useful enough in a lot of useful scenarios, I think we'd want multiple to be able to played at a time.

Separate but related from that is user controllable weighting. Separate, as you could have the last played animation 'win'.

But we could support mixing via a weight prop to Animation.

[AdaRoseCannon]

I was thinking about what the difference capabilities we would gain between using Web Animations vs timeline based approach but in breaking it down it feels like a more useful exercise seems to list features which we would want and see what they deliver.

Features I think we would want for a system to control the pre-baked animations:

• Retrieve a list of animation names without needing to know in advance
• Pick a default animation
• Declarative connection of animations to specific animation timelines
• Sync Audio Tracks or Audio Elements to Animation
• Sync Video to Model Animation????
• Sync animation to the scroll-timeline
• Animation mixing with weights
• Query current time of a particular animation
• Individual control of looping for animations
• Customizable Playback Rate
• Negative playback rate
• Apply an easing function to time timeline???? <- (Could both be useful but also can see why some would not like it)

I don't think either Web Animations or Animation Tracks would solve all of these and some of these wouldn't be immediately possible with either.

In addition depending on what someone is doing then each model makes more sense than the other.