Mitch

I just pushed a new class, SkeletonAnimator, up to the git repo and updated the unitypackage. 8)

Mecanim is now fully supported by the new SkeletonAnimator (derived from SkeletonRenderer). SkeletonAnimation is still around, but you now have the option of clicking the Generate Mecanim Controller button to create a controller with dummy-animation clips which will keep itself updated with the SkeletonDataAsset when changes are detected.

There's a new context menu if you right click a SkeletonDataAsset in project view under Spine> called Instantiate (Mecanim) - this will handle all of the setup process automagically.

SkeletonUtility and all of its friends are fully compatible with SkeletonAnimator as well.

Events have the same limitation of the native Unity baking process in that they only support 1 data type at a time in the order of preference String, Float (or int), No Arguments.

Also took a pass at Unity 5 compatibility which should be all cleaned up now.

Test the crap out of this please :notme:
User avatar
Mitch

Mitch
Posts: 959

Pharan

Never! I'll NEVER use Mecanim!

But I will use Unity 5, because according to the Release Notes:
AudioClip now supports multi selection and editing, so you no longer have to change the same property on all clips one by one, just select all the clips you want to change and get it over with all at once.
Official Esoteric Assorted Furniture Cleaner and Teahouse | Check out the Spine Users Tumblr Blog: spine-users.tumblr.com
pharan.deviantart.com | pharantriestoanimatestuff.tumblr.com - - - Windows 10 - Spine-Unity.
User avatar
Pharan

Pharan
Posts: 4119

foriero

Thanks Mitch for your great work. :-) This is going to be fun creative life with spine and your runtime :-)
foriero
Posts: 154

davidsvson

I have never used mecanim, is it any idea to switch? Any advanteges? (I see @Pharan doesn't seem to think so ;) )
davidsvson
Posts: 51

Mitch

davidsvson wrote:I have never used mecanim, is it any idea to switch? Any advanteges? (I see @Pharan doesn't seem to think so ;) )
Blend trees, advanced state machines, triggers, blahblahblah.
User avatar
Mitch

Mitch
Posts: 959

Pharan

@davidsvson.
There are a lot advantages. Mostly ease of setup, without having to code animation controllers yourself, especially for fun things like blend trees.
I like to roll my own though 'cause sometimes it's hard to get Mecanim to do what you want. Mecanim was really made with 3D animation in mind, whereas I personally like to handle my Spine animations like PlayStation-era 2D sprites.

If Mecanim is what you're used to, it's definitely a good thing to have.
If you've never used Mecanim before, expect to spend some time watching videos and searching how-tos to learn how to use it, as with any part of Unity.
Official Esoteric Assorted Furniture Cleaner and Teahouse | Check out the Spine Users Tumblr Blog: spine-users.tumblr.com
pharan.deviantart.com | pharantriestoanimatestuff.tumblr.com - - - Windows 10 - Spine-Unity.
User avatar
Pharan

Pharan
Posts: 4119

wrongtarget

Mitch, you're the man, and you know it.

@davidsvson I concur with Pharan. For instance, I'm currently working on a 2D point and click adventure using Spine. Mecanim is not as suited for this since in our case things as speed or velocity to determine animation states are not fundamental.
Mitch showed it tome using one of his platformer examples though, and you'll find it's perfect for those cases.
User avatar
wrongtarget
Posts: 26

davidsvson

Thanks @mitch @pharan and @wrongtarget!

I'll not convert to mecanim in my current project but will try it out for the next one.
davidsvson
Posts: 51

Rouven

Great news! I'm seeing a lot of glitches though with Unity 5.

For testing purposes, I moved a character to a Mecanim state machine (previously setting/mixing clips in code).

- I have a non-interruptible transition to a state (player turns from right to left), which then transitions (non-interruptible) to "idle" at normalized Exit Time 1.0 (no other conditions). This animation is not played entirely, it often ends up with frames half-way in the turning movement, as if leaving too early

- Flipping the skeleton is erratic as well. I can use either
transform.rotation = Quaternion.AngleAxis(facing < 0 ? 180 : 0, Vector3.up);
or
GetComponent<SkeletonAnimator>().skeleton.FlipX = facing < 0;
to flip the skeleton for all left-facing states. It was working before moving to Mecanim, but now it's erratic. Almost seems as if the state machine is messing with the FlipX state of the skeleton (or is it the root bone transform / both?)

Thanks
Rouven
Rouven
Posts: 6

Mitch

There is a parameter called Mix Mode on the skeleton animator that controls how mixing is applied per mecanim layer. Try setting it to SpineStyle and see if that resolves your issue.
User avatar
Mitch

Mitch
Posts: 959

Majicpanda

You have no idea how much this helped our workflow when trying to figure out how to sync animations in Bolt networking. Bolt has mecanim support which automagically sync's everything so adding this basically made our day x 500.

Lifesaver.
Majicpanda
Posts: 184

reuno

I'm pretty new to Spine, and I'm having trouble figuring things out. I've tried the Generate Mecanim Controller thing, but I'm not sure how to use it.
So far I was using the "bake all skins" button, which worked fine, I then created a new animator that used the animations from the ones from the bake. It was fine, except that I had to bake stuff again everytime I changed something.
I've tried "Generating Mecanim Controller", and assigning that generated controller to my baked prefab, but it doesn't seem to work. What am I missing ?
reuno
Posts: 6

Rouven

@Mitch That didn't change anything, unfortunately. I have disabled and even removed my second (upper body) layer in the Animator, but the issues persist within the Base Layer.

I just noticed the keys that are dropped are only those that attach an image to a slot. All Scale/Rotate/Translate keyframes are applied just fine.
Rouven
Posts: 6

Mitch

Baking and Generate Mecanim Controller are unrelated. The SkeletonAnimator class acts an interface between mecanim and SkeletonRenderer so it is fundamentally different than baking.

---

Rouven wrote:@Mitch That didn't change anything, unfortunately. I have disabled and even removed my second (upper body) layer in the Animator, but the issues persist within the Base Layer.

I just noticed the keys that are dropped are only those that attach an image to a slot. All Scale/Rotate/Translate keyframes are applied just fine.
Would you be willing to send me your exported files w a controller that exhibits this issue? Would love to poke at it heh
User avatar
Mitch

Mitch
Posts: 959

Rouven

Sure, just PM me your email address!
Rouven
Posts: 6

Gisle

This looks amazing! Will these features be included in the tk2d runtime aswell?
Gisle
Posts: 7

Mitch

I don't think there's any difference between them in regard to mecanim. Try bringing the animator scripts over.
User avatar
Mitch

Mitch
Posts: 959

Gisle

It worked, thanks :D

Would love to see this in the official runtime tho, no pressure ;)
Gisle
Posts: 7

Mitch

Gisle wrote:It worked, thanks :D

Would love to see this in the official runtime tho, no pressure ;)
Yea; I owe the TK2D runtimes some updates heh. I never use TK2D though :( not like I get paid for this :wonder:
User avatar
Mitch

Mitch
Posts: 959

soy_yuma

Hey! First post here :-)

Thanks Mitch for creating the SkeletonAnimator. I just started using Spine (it's been in my todo list forever) with Unity 5. Against all advice, I'm using mecanim since I'm familiar with the kind of state machines you can create with that (and I can't be arsed to create my own State Machine solution from scratch right now). Your SkeletonAnimator is working like a charm! I can "navigate" the state machine and see the animation change to what I created on Spine. Yay!

My next step is to use events. You said they have the same limitation as when you baked the animation using the previous system (SkeletonAnimation?). That makes me happy, because it seems to imply that I can use Spine events with mecanim in Unity 5. The problem is that I don't see where to hook my delegate to listen for events. I've been searching the C# and Unity runtimes but it only seems to exist hooks in AnimationState (old system). The docs also point to AnimationState. Can we listen to Spine events when using mecanim?
User avatar
soy_yuma
Posts: 3

Pharan

soy_yuma wrote: You said they have the same limitation as when you baked the animation using the previous system (SkeletonAnimation?).
He means it's using Unity's Animation events, not Spine-C#'s events.
SkeletonAnimator (and Mecanim) don't touch Spine.AnimationState (where the Spine event delegates live).
SkeletonAnimator also doesn't interface with Spine.EventTimeline.

I'm actually not sure where the events are defined for SkeletonAnimator. I guess in the "dummy" animation clips?
Official Esoteric Assorted Furniture Cleaner and Teahouse | Check out the Spine Users Tumblr Blog: spine-users.tumblr.com
pharan.deviantart.com | pharantriestoanimatestuff.tumblr.com - - - Windows 10 - Spine-Unity.
User avatar
Pharan

Pharan
Posts: 4119

clandestine

Yeah, they're in the clips (you can inspect them with the Animation window) - and since they're Unity events, they're actually SendMessage-style and calling the function with the same name as the event: http://docs.unity3d.com/Manual/animedit ... vents.html
User avatar
clandestine
Posts: 48

soy_yuma

That is awesome!

I'm still a newbie on Spine+Unity (in case it wasn't evident before), so I didn't know there were Unity events. I'll have a look. Thanks a bunch!
User avatar
soy_yuma
Posts: 3

jeremyb

Hi Mitch,

I'm brand new to Spine, so please forgive any stupidity in this post. It looks like I've picked up your latest with the unity package runtime, so I can use the create animation controller action you outlined above. But I'm not really understanding how to configure it, or even the intention here --

When I instantiate the controller via Spine->InstantiateMecanim, it looks like it generates a mecanim anim controller that flattens all animations to interface with a single GO: "Game Object.Dummy". How is this configured? I see that the SkeletonData seems to retain linkage to the animator once this is done, which I assume is to aid in iteration. But when I generate a new SkeletonAnimation via Spine->InstantiateSkeletonAnim, it doesn't include the new Animation Controller. When I connect the Spine generated animation controller, it complains that it can't find the Dummy object. Am I missing something fundamental here?

Also, just so I'm clear, this is intended as a "lighter" approach to allowing mecanims to control animation state without incurring (most of) the functionality hits of baking it completely into Unity. Am I completely mistaken here? I hope not, because it seems like exactly what I want.

Thanks!
--Jeremy
jeremyb
Posts: 8

Mitch

There are 3 ways to go from Spine --> making things move in Unity at the moment.

1) Instantiate -> SkeletonAnimation
This is the "Spine" way. All features supported.

2) Instantiate -> Mecanim (or SkeletonAnimator)
This creates a scene graph object and a dummy RuntimeAnimationController with proxy AnimationClips that match the name and length of the SkeletonData associated with your Spine JSON or Binary file. The Dummy property is there simply so Mecanim thinks the animations are the correct length. The SkeletonAnimator component applies animations using the Spine API's Animation Mix and Apply functions. This allows use of Mecanim graphs with the Spine API directly which is a standard Unity animation workflow. It might have a few side effects in terms of attachment keyframes... somewhat hard to track down. This method keeps everything up to date with the SkeletonData.

I think what you might be missing is that it is also generating an object in your Scene Graph in addition to generating the Controller (if it didn't already exist). SkeletonAnimation and SkeletonAnimator are generally interchangeable and both support things like SkeletonUtility.

3) Baking
This removes all dependence on the Spine API. Mesh, Skinned Mesh, and Prefab assets are generated for each Skin, AnimationClips are generated, and a RuntimeAnimationController is generated. This doesn't support all of the features present in the native Spine API however, so it has limits, but it does remove all dependence on the Spine codebase which is necessary for pushing say... an animated character into the Asset Store as the Spine runtime is not distributable to people who don't own Spine. It is also useful to simply use Spine as a rigging tool for simple things without the overhead of the full runtime.
User avatar
Mitch

Mitch
Posts: 959


Return to Runtimes