More robust animation system

[jeaye]

Right now, MD5 animations can be loaded and will loop forever on an actor. This needs to be made more robust, stable, and flexible (and more performant when more actors are visible).

• Use an Animation_Cache to load the animations, which become read-only
  • Only reference them with Animation instances
• Support animation blending
  • Three animations: Current, Blending, and Next
    • Adding a new animation when there is a Next replaces Next
• Support separate animation groupings
  • Torso and legs are primary
  • Multiple groupings can affect any animation, and each can have a bias/weight
  • An actor will have multiple Animation controllers, one for each grouping
• State machine
  • Instead of game code being riddled with animation logic, messages should just be sent to an animation state machine (one per actor)
  • If Crouch is sent as a message, for example, some animations might be interested in obeying it, while others will just ignore it as unapplicable

[evincarofautumn]

• Support animation blending
  • Three animations: Current, Blending, and Next

Is this not simply a weighted average (t × Current + (1 − t ) × Next)?

[jeaye]

Is this not simply a weighted average (t × Current + (1 − t ) × Next)?

This is more a note to myself, so it might be a bit misleading to others. What I'm saying here is that there should be three animations (maximum) per Animation instance. There's the base animation, Current, and what is being blended to, Blending. Since I only want to support two active animations at a time, there will be a queue (limited to len == 1) for the Next animation to start blending after Blending has become Current.

I further note that any attempts to add a new animation while Current and Blending are still doing their thing will go into Next, as per usual. If Next is already set, it is replaced; this will avoid too long of an animation queue and should also prevent any visual popping/snapping, since this data is only being set in the background.