What turned me away from SmoothMoves is that it uses skinned mesh renderers, which cannot be batched. See section 8.2 in the SmoothMoves manual: http://echo17.com/support/smoothmoves_user_manual.pdf

Each bone animation will cost at least one draw call. If you have 100 of the same character in a scene it will cost at least 100 draw calls. (Unless that was changed within the last month or so, haven't been following updates)

Spine does not use skinned mesh renderers. You can have 100 of the same character in a scene and it will cost 1 draw call.

Thanks pxlweaver.

First I would say being integrated into Unity could actually be a disadvantage if the integrated tools are less powerful. I don't know if this is the case with Smooth Moves, which I know nothing about. When comparing Spine to other tools, I think the best thing you can do is build an animation in both. Be sure to refine your animation as you would on a real project. Good animation requires a lot of tweaking to get the movement and details necessary. This is where many tools start to fall apart. You want a tool that not only can animate your images, but provides a good workflow. Without actually using both tools, it will be hard for you to really get an idea of how you will integrate them into your workflow.

I'm not familiar with Smooth Moves, but I'll take a quick look at some YouTube videos and ramble off some thoughts. Keep in mind I can't possibly help but be totally biased and these notes are the result of a few minutes of research without actually using Smooth Moves, so I could quite easily be wrong.

Setup is a bit different. Spine has a setup pose (aka bind pose) which all animations are relative to. This enables some easy procedural animation. Eg, leaning the bind pose forward while running up hill will cause the run animation (and other animations) to lean forward. Smooth Moves doesn't do this, each animation defines the absolute pose (you make a pose and copy it as the basis for each new animation).

There are some other setup differences. In Spine images are placed on bones. In Smooth Moves each image has an implicit bone which originates where you set the pivot point. Setting the draw order in Smooth Moves is assigning a number to each image. Spine uses slots to control both draw order and the images that can be attached.

Spine has skins, which let you reuse animations for characters that use the same skeleton but look different. Spine skins are not just a different set of attached images, they handle the problem where animations have image changes. Eg, your character blinks so the animation changes the eyes. If you change the skin, in Smooth Moves (and similar programs) the animation will change to the wrong eyes. In Spine it works (see the goblins example and the skins video).

Smooth Moves suggests changing the material to another with exactly the same layout, which is very limiting. You will very, very often want images in different skins to be different sizes. To have a different skin for the same skeleton in Smooth Moves you'd have to swap each individual image. This would not solve the problem of animations that have image change keys, so for each skin you would need a duplicate animation for those that have image keys.

I didn't see advanced tools like inverse kinematics (the Pose tool in Spine) and bone/image compensation.

Spine has a nice runtime API for loading data, keeping stateless data separate from stateful data, applying animations, mixing animations, manipulating bones for procedural animation (examnple), etc. From a quick look at Smooth Moves' API, procedural animation may be difficult. I see you can get a bone's transform, but it isn't clear how manipulating it will interact with animations that are applied.

From my quick look, the Smooth Moves tools don't look as easy to work with. It seems the Smooth Moves can indeed animate your skeletons, but the workflow is quite different. You'll be spending a lot of time building animations and integrating them with your game, so the entire workflow from start to finish is very important.

Anyone else can feel free to jump in with additional comparisons.

You can see some videos about things I mentioned in Spine here:
http://esotericsoftware.com/spine-videos/

SmoothMoves has mixing/blending options for playing multiple animations right in its interface + little bit of code.

I think this capability is also implicit in Spine-Unity for now, since there's some extra, relatively low-level coding to be done(?). (vs SmoothMoves API)
Not 100% sure on this though. It's just that the main object you'll be handling, a SkeletonComponent instance (which I think is kind of the manager of the manager of the mixing logic and keeping state data), doesn't seem to have any pickup-and-go methods like SmoothMoves does for multiple animations for now. Or I could be wrong. Documentation's still on the way anyway. (Sorry, Nate, if I misunderstood your code. T___T Honestly, I think Spine is awesome. The API and asset management are super clean and the runtime is efficient and stuff. I'm just really a n00b.)

Anyway, on the other hand, I think this also means the Spine-Unity runtime is very extendable as long as you have the knowhow to code it.

Regardless of what you use though, if you're gunning for different animation clips for different body parts, you'll need to manage your animations and structure the clips/keyframes in specific ways so your blended animations don't go nuts.

Don't be shy about the comparison. No need to apologize for anything, I'll be sure to point out if you get anything wrong!

Smooth Moves has an API to play, queue, and "crossfade" animations. Spine also has this. Smooth Moves' API manages state for you at its lowest level, which is why I mentioned it isn't clear how procedural animation would work. At the lowest level in Spine runtimes, there is a skeleton which has animations (among other things, eg skins, attachments, etc). At this low level it doesn't manage state for you, you can do procedural animation, apply animations, etc on top of this. The next level up is AnimationState, which manages animation time, queuing animations for later playback, and mixing (crossfading) animations. For some runtimes (eg cocos2d-iphone and cocos2d-x) there is another level above this that makes it easy to apply multiple animations on top of each other (eg to animate the legs separately from the arms). For runtimes without this, it's just a matter of writing code to apply two animations (2 lines of code).

Here is a diagram of the core runtime classes, applicable to all official Spine runtimes. Note how the "instance data" box is the only data with state, all the skeleton data and animations don't have state and can be reused for any number of skeleton instances.

Spine's runtimes are designed to be flexible so they can be used in many ways. A lot of effort went into the design because I knew I would be porting them to dozens of languages.

Note that Spine's runtimes are open source. Anyone can grab them from github, review them before purchasing Spine, use them, find bugs, fix bugs, contribute new features, etc. AFAIK, Smooth Move's runtime source is only provided once you purchase (I'm assuming the source is provided, I doubt they would only provide binaries, but I don't actually know).

Both tools do roughly the same job. Choosing one or the other will come down to the small number of features unique to each one and (IMO, more importantly) the workflow used to create animations and integrate them into your game.

Edit: just updated the diagram so it is current.

Speaking as a developer, the fact that spine comes with source where smooth moves only comes with .dlls is huge.

I also did not like the fact that you have run their updater program when you change an animation. This program touches the scene and other files that are not effected and I have had it corrupt my scene in more that one occasion.

-Pat

Oh, Smooth Moves only has DLLs? Interesting. Other plugins such as 2D Toolkit provide the source. I see the Smooth Moves author is quite active and seems to respond to requests in the community. Still, I think the runtime is a fundamental piece of a game. You should be able to fix problems yourself or bend the runtime to your will if that is needed.

Yes and I have asked him about providing source and his reply was that he did not have time to support it.

Since the editor is stable and our animator liked it I thought about writing my own run time but getting to the run-time data let alone understanding it led us to Spine.

Considering the time we had invested in Smooth Moves the switch was costly, but I am very happy that we made the switch.

Well, glad to have you here! :* Spine's export data format is documented and if you can get your Smooth Moves data into this format, you can import it into Spine.

Came across this article, relevant to this thread:
http://blog.deepworldgame.com/post/4978 ... 3-we-spine

I saw the response over there. The Smooth Moves guy seems respectable, I'm glad we can all talk about competitors without anything turning ugly. It is a sensitive thing as we both have put in a TON of time into our projects and we are both of course biased to our own projects.

He's right that Spine doesn't have colliders. You can get a bone position and do hit detection or I imagine place a collider (though I'm not too familiar with Unity colliders). Spine will have bounding boxes (a Kickstarter goal) which lets you create areas for hit detection. It would make sense for bounding boxes to be colliders in the Unity runtime.

One thing I saw is Smooth Moves can't generate or manipulate animations at runtime because some sort of preparation is done beforehand. The Spine runtime APIs allow you to create animations or modify existing animations. This can make it easier to do something procedural. Eg, an animation where a character reaches out and opens a door. At runtime you could adjust the animation so the character reaches the correct amount based on where they are standing. I saw he said in Smooth Moves you can get a bone and manipulate it procedurally, that is good for things like making a bone rotate toward the mouse, but if you wanted the bone to rotate toward the mouse you'd have to implement that animation yourself from scratch.

Here's a guy that talks about how he generates animations with Spine. Has a video link too.

Spine will have event callbacks, but doesn't right now. However, you can extend SkeletonComponent and do anything you like. Eg:
https://github.com/EsotericSoftware/spi ... ion.cs#L58
This just applies an animation. You could also check the animation state time and turn colliders on/off at various times in the animation. You can also get the bones, manipulate them, modify animations, etc. Each Spine bone is not a Unity transform, but you can get the bone's world position, rotation, and scale and position a collider with that. I think the 2D Toolkit runtime for Spine has colliders.