Animation-mixer support for multiple animation clips

[diarmidmackenzie]

Animation mixer can blend multiple animation clips together.

However the way clips are specified on the schema means there's very limited flexibility here.

The schema allows:

• 1 explictly specified animation clip name
  or
• 1 wildcard expression.

If you have animations called "walk" and "run" there is no way to specify both of these at the same time (other than by specfying "*" which results in all clips playing at once).

The code that handles this is here. It explicitly escapes all special characters other than *, so if we try to do e.g. walk|run, that will only match an animation literally named walk|run (a good thing as it turns out, as it seems common to have | as a character in animation clip names.).

Likewise, walk,run and walk run would only match animations with those literal names.

Some possible solutions:

1. use * as a separator, so that walkrun gets parsed to walk.|run*. That's a simple change, but not 100% back compatible - e.g. if you had animations called walkthenrun and walkandrun and wanted to pick out both using walk*run.

2. move "clip" to an array of strings. There is a back-compatibility issue here too: in the HTM interface, a singleton value gets interpreted as an array of length 1. But that's not the case when properties are specified via JS objects: you need to do { clip: [walk] }, and {clip: walk} won't be considered to match the schema for an array. (I've made this mistake before - e.g. here - it would be nice - and probably quite easy - to make A-Frame more flexible here...?)

3. introduce some new syntax for clip that allows multiple strings to be supplied. Could e.g. use , or <space> as a separator. The issue would be that these might appear in existing animation names, so it's not possible to be 100% back compatible.

4. add a flag to the schema indicating that the clip property should be read as a regExp. This would be fully back compatible (flag set to false by default), but allow users to specify e.g. walk|run if they wanted to, or even richer expressions like walk[0-3].

Of all these, I am leaning towards #421, because:

• it gives full back-compatibility
• it delivers the full power of regular expressions on the interface.