Since Spine-Unity's spine-csharp core is mostly engine agnostic, Spine's core data objects like Skeleton data and Animations are loaded at runtime directly from the exported Spine skeleton json (.json) or binary (.skel.bytes). They are pure C# objects and aren't assets in Unity, which limits their user-interface visibility in Unity Editor.
This means that we've historically had to resort to storing strings in our MonoBehaviours and ScriptableObjects to serialize the animations we choose. Then use those strings directly for SetAnimation calls, or use strings to find the Animation objects using Skeleton.Data.FindAnimation.
These are still good options depending on the situation.
However, coming very soon:
AnimationReferenceAsset
This is a new Spine-Unity asset type that keeps an animation name and a reference to a SkeletonDataAsset where the animation comes from.
You can use them in inspectors.
At runtime, the Spine.Animation reference is loaded and cached into the ScriptableObject, so it can act as one-away from a reference to an Animation without having to deal with loading.
In code, you can use them directly in AnimationState calls, because of its implicit Spine.Animation cast/type conversion.
using UnityEngine;
using Spine.Unity;
public class SampleAnimationReferenceScript : MonoBehaviour
{
public AnimationReferenceAsset run;
void Start()
{
var skeletonAnimation = GetComponent<SkeletonAnimation>();
skeletonAnimation.AnimationState.SetAnimation(0, run, true); //optionally: //skeletonAnimation.AnimationState.SetAnimation(0, run.Animation, true);
Debug.Log("This animation is " + run.Animation.Duration + " seconds long.");
}
}
You can also use its .Animation property.
How do I create them?
A complete set of reference assets can be generated from your skeleton data with the press of a button in your SkeletonDataAsset's inspector.
You can also create them one by one by going to Assets>Create>Spine>Animation Reference Asset, or duplicating existing ones and changing the values in their fields.
Just to clarify
This does not replace or affect the existing ways you can store and use animations and animation names.
If the system you created in your scripts makes more sense, by all means continue to use them.
This is just an additional inspector-friendly and code-friendly option that now comes with the runtime.
This is also not to be confused with dummy UnityEngine.AnimationClips.
Spine-Unity's Mecanim integration creates a controller and dummy AnimationClips (which are required by Mecanim uses for its state machine states).
What about other stuff? Bones? Slots? IK Constraints?
It became apparent that things like bones and slots could not be given the same implementation since they belong to skeleton instances, whereas objects like Animations belong to the shared SkeletonData.
Is it impossible? That remains to be seen. But it's not obvious to us at least.
We will continue to look into improving this aspect of Spine-Unity.
For now this also fulfills an important need that our Spine-Unity Timeline/Playable feature has had for a while.
The new asset's source code is also a total of about 20 lines of code so if you're curious, we encourage you to open it up when it's released.
If you have any ideas, suggestions, questions, words of caution, or haikus, let us know!
