Wonser

I have a small team of animators that need a new software to create great looking puppet animation. I have a few questions and have found conflicting answers around the interwebs.

Primarily most of the characters and animations we've used in the past use Unity's Animator Controllers... Upon importing Spine animation into Unity, what is the current workflow to getting those animations to work with those controllers? I couldn't find a clear updated youtube video that demonstrates what the latest experience is, when exporting Spine into Unity. It seemed like it is quite a hassle.

Our animators are the ones that create our state machines with the animator and try to visually control every moment of their transitions between states. Is it still true that imported Spine animations are not converted Unity.anims? Does that mean that they cannot be used with the animator.controller?

If the animations imported from Spine are not .anim, does this mean that we cannot adjust curves of the animations in Unity? Each change would require a re-export? Is replacing an animation already in the project a fairly straightforward process?

Ultimately, does using Spine mean that we have to create a custom animation controller within Unity?



I'm sorry if these have been answered before, I searched through the forums here and elsewhere.

---

Additionally, when setting up IK controls within Spine, Do they have a toggle to allow stretching of the sprite, scaling along the bone/joint as the control is pulled beyond it's normal bound?
Wonser
Posts: 1

Nate

Wonser wrote:Additionally, when setting up IK controls within Spine, Do they have a toggle to allow stretching of the sprite, scaling along the bone/joint as the control is pulled beyond it's normal bound?
It's currently not a checkbox, but it can be done by binding a path to both the IK bones and target. You can see the stretchyman example project or play with the demo here:
Spine: Demos: Path constraints
This is definitely not the only way to use paths, nor the only way to rig limbs. However, it does provide scaling of the limb when the IK target is out of range. There are other benefits too, such as being able to manipulate the path to get a smoother or sharper bend than a single knee/elbow joint allows.

Making it as easy as a checkbox on the IK constraint is not actually terribly difficult, so we've added that in 3.7.20-beta. :party:



Pharan will be along shortly to address your Unity concerns and questions!
User avatar
Nate

Nate
Posts: 8028

Pharan

Each of your options have their own pros and cons.

DATA
For the best coverage of Spine features, Spine skeletons and animations are not converted into Unity assets. (Skeletons and bones are not converted to prefabs and GameObjects. Animations are not converted to anim files.)

Spine has some features and systems that either Unity's Animation system lacks or does drastically differently. By default, Spine data is loaded straight from your export (.json or .skel.bytes for binary data).

This can mean a number of things, including that animations are solely edited in Spine and come from the Spine export. Animations don't have incongruencies when you export from Spine and import into Unity, they behave identically as they did in Spine.

CONTROLLERS
Spine has its C# Spine.AnimationState API, which is far more low-level than what Unity gives you out of the box with its Mecanim state machine. You can write your own controller to make calls to it. You can also write Mecanim StateMachineBehaviours to make calls to it. (We're working on an example scene and assets for this. It should be included in the next version.) Any of the special features that Mecanim supports would have to be handled as needed.

The paradigm here is primarily that you would use Mecanim as a logical state machine with Spine commands tied to it, rather than use Mecanim as an ANIMATION state machine.

The alternate option is to use "SkeletonMecanim" (previously called "SkeletonAnimator" in 3.6 and below). This generates a Mecanim controller and dummy Unity AnimationClips, and uses a Mecanim state machine to drive the skeleton animations. The AnimationClips are mostly empty except for events and the duration of the animation. They are only used to keep track of time and which animation is being applied. This option is more along the lines of using Mecanim as an animation state machine and things like blend trees are supported out of the box.

If you are used to working with Mecanim but don't want to have to code some extra things, it's likely the most comfortable route available at the moment.

To use SkeletonAnimator/SkeletonMecanim, you just need to instantiate the skeleton into the scene as the right type. If your controller and dummy animations don't exist, they will be automatically generated for you.



Many users have used these different options with success. Which way you choose to do things really depends on your needs. But if you run into any problems, feel free to post and ask questions here on the forums. Spine and Spine-Unity are still continually being developed as new features are added and as Unity has also changed over time.
User avatar
Pharan

Pharan
Posts: 5009


Return to Unity