Spine: 2D skeletal animation

Hi Nates, don't worry I wasn't mean to say your tools is maybe bad performance wise , just a bad experience I had with similar tool, so If you end up getting to work great on unity I mean I am just going to test it of course

It is just natural question and feeling when you want use 3rd party tools

I am keeping an eye on it anyway , the company I work for do only 2d game with unity and I am just looking around for good solution for our designer .

 

https://dl.dropboxusercontent.com/u/915650/Screenshot%202013.11.14%2020.00.59%20copy.png

you make my day NateS..

 

I am looking to get Spine or smooth moves, is there anyone who has used both that can say what the difference is between the 2 packages?

 

Btw hope that there won't be a change to time.deltaTime. If so, make it purely optional per spine object.

Because time.deltaTime is the only way to slow everything in unity from invokes to unity animations, so there's that hugely breaking thing if you choose to calculate delta manually. So it has to be optional only.

No. It's the best possible thing. Any change must be optional. It has far reaching complications if it isn't.

 

@giyomu, image doesn't load. I'm curious what it is!

@pkid, Spine provides the source for the runtime, AFAIK Smooth Moves doesn't. Spine is an external tool, Smooth Moves is inside Unity. I suggest trying them both and seeing the differences firsthand.

@hippocoder, the current way the Spine runtime does it is flexible and should cover all delta time needs.

 

ah sorry , should load now
https://dl.dropboxusercontent.com/u/915650/Screenshot 2013.11.14 20.00.59 copy.png

 

took from my iphone5

 

Woohoo! That's a lot of dragons! Glad to see it running so well on the iPhone 5. Each dragon has 31 individual images and 33 bones. However, all these images don't fit on a single 1024x1024 atlas page, so the dragon example has 2 atlas pages. This means a lot of extra texture binds are happening just to render a single dragon, so you should see much better performance using a skeleton whose images come from a single texture.

The spineboy also has multiple atlas pages, this time for testing, not because they don't fit. The goblins example has a single page atlas. It has 20 images and 18 bones.

 

Are you sure you followed the steps exactly? Do you have errors in your console?

 

I can understand that. It would however be very cool to have an option to convert the playback into Unitys own format (the older Animation format) or Meccanim (the newer Animator format, even better). That would also mean that when new improved stuff comes to Meccanim it can also be used by the users of Spine. I don't know however if you can set up Meccanim from code yourself but I know you can with the old system. You basically add keyframes for the different transforms. Blending will also work when using the Animation system.

I understand that this would take time and so on. Is your export format easily readable when coming from Spine? In that case I could program that conversion myself (if I needed it).

 

Nate (and or any other SPINE owners), I own Spine, and it's a terrific, intuitive animation platform. But getting animated characters into Unity is a bit like balancing a wineglass on your nose, and a plate of meatballs on your head while spinning plates on sticks with both hands. I'd love to go with Spine Pro and upgrade through the Kickstarter...but my sole use for Spine is as an extension for Unity.

Nate, is there any thought to a more streamlined process to get Spine animated characters into Unity? I'm about to explore the new 4.3 functions for 2d in Unity. I would love to hear from fellow owners, users or Spine team members if Spine still offers significant advantage for 2D animation.

I think Spine is an amazing package. If getting characters to Unity was more straightforward this question would be mute. But currently, it isn't pretty...

 

I've not had a chance to play with Spline in Unity yet (Paypal e-cheque system...sigh), but I have been going through the new sprite stuff. The key thing to realise is that's it's just a sprite renderer with nice texture packing. There's no feature-rich animation designer, aka Mecanim/Smooth Moves/Spline, or most 3rd party sprite toolsets.

Mesh-based sprites are one of Spline's upcoming Pro features, so it would seem natural that they might support tight texture packing themselves (Nate?). Keep in mind Unity's is a Pro feature only.

As is I think the best 2D feature in Unity 4.3 isn't the sprites, yet, it's the inclusion of Box2D.

 

@johot, the current runtime uses a single gameobject with a mesh to maximize performance. We'd probably need a gameobject per image to use the Unity animation stuff. I explained about that a few posts ago.

@outtoplay, what is hard about using Spine data in Unity? You create and configure an Atlas and SkeletonData asset, then you create a SkeletonAnimation component.

Texture packing was something that the new Unity 2D stuff is supposed to improve. I haven't had a chance to look at it closely, but it would likely be nice to have your Spine images packed together with the rest of your images to save texture binds. This is why I expect we will integrate the Unity texture packing with the Spine runtime. The runtime is already very flexible, probably the attachment loader and possibly SkeletonComponent need to be modified to support that.

 

Strange. The examples work for me on Unity 4.1.5 and 4.2.0f4. I can update to the latest Unity and try again, but I have a lot going on at the moment. I'm not even answering posts on my own forum, I shouldn't be answering them here either!

 

Nate, it 'works' fine. Obviously The ease of integration of Spine animations for Unity users isn't (nor should it be), a top priority for you. But watching the YouTube video on 'how to' doubtfully could be considered a handy process by anyone. It's great that someone figured out and documented how to connect Spine anims into Unity, but a quick review of that process should reveal several steps that if automated between the programs would make for an immeasurably more pleasant pipeline.

 

@outtoplay, the "works for me" was directed at unknownuser's problem. The video takes about 3+ minutes to get to actually configuring things in Unity, but a slow video doesn't mean it is hard to use the runtime. AFAIK, the runtime is set up in a typical Unity way, by creating assets and linking them to a gameobject. I admit there are a number of pieces involved: material, atlas, skeleton data, and skeleton component. In a simple example maybe these seem superfluous, but they exist for good reasons. Eg, any number of skeleton components can share the same skeleton data, so it doesn't need to be loaded many times.

@unknownuser, maybe your newer Unity broke something, otherwise I guess something is misconfigured. Until I can try it, maybe show screenshots or a screencast of what doesn't work. If all I have to go on is "animation state data doesn't show up" there is little help I can provide.

 

Just grabbed the latest runtime from git, and works here with zero errors (Unity Pro 4.3, Windows), although the Spineboy scene appears to be broken - limbs aren't attached to the skeleton properly, or attached to the wrong bones(slots?) by the looks of it.

Very nice, and very impressive...great to see it running in a single draw call too, even with multiple instances and lighting.

You only need need to add the src directory from spine-csharp/, not spine-csharp itself ... I assume you've done this as you'd get Spine namespace errors, but adding other bits 'might' result in unexpected errors/results.

 

Missed these before, just a few console warnings in 4.3 (nothing fatal, though the first should definitely be addressed when you get time)

Script 'Animation' has the same name as built-in Unity component.
AddComponent and GetComponent will not work with this script.

Assets/Spine/Editor/AtlasAssetInspector.cs(51,34): warning CS0618: `UnityEditor.EditorGUIUtility.LookLikeInspector()' is obsolete: `LookLikeControls and LookLikeInspector modes are deprecated.'

 

I was also having the problem of not being able to setup Spine atlases / skeleton data in Unity - turned out Spine had added the number 2 to a couple of attachment region names - http://esotericsoftware.com/forum/viewtopic.php?f=7&t=1688&p=8239#p8239 - not sure if this is a Spine editor bug or something.

 

Sounds like they were duplicated and the originals deleted perhaps.

I've done quite a bit of animating and passing data back and forth (I do like how you can read json files back in) without any problems, so if there was a naming bug it must have since been squashed, though the installation process does feel a little shaky - suggest exporting it as an AssetPackage once you have a happy setup if you haven't already though as the second time I installed it I did something wrong and it didn't like it at all.

I suspect they'd get a lot more adoption if they packaged it up at their end.

 

I'll make a Unity package at some point, once things settle down a little bit.

 

First, thank you for the amazing work on Spine, I can't wait for the new pro features and sadly I discovered Spine after the 2nd kickstarter ended;

I have plans to develop a platformer on unity, and hope your editor and runtime will be the perfect solution when we come to production time.

I have so far a few questions about the runtime.

- I know this one has already been answered, but I would really like to see a runtime using unity's animation system and mecanim compatible.

I plan to do some research on the subject and maybe write my own solution.
I doubt using native unity's sprite is a solution cos the API is really poor and won't support FFD or mesh sprites.
However, we could write a sprite Framework supporting mesh shapes and CPU skinning, or even vertices tweening.
on top of that we could generate a unique mesh based on the skeleton and slots hierarchy, by having a bone transform hierarchy in unity(the same used for 3D models bones) with some animatable objects per bone like "image attachement" or "mesh attachement",
I know unity animation now supports object reference keyframes, so complex objects describing mesh data or image description could be timelined too, and with some hack, tweened.

- the second one : could you make it possible to define multiple skeletons in the same file?
I'll explain : my main character will be quite complex, and use different skeletons depending on its poses, switching sometimes from a back pov to side one, for exemple. It's likely I'll need multiple skeletons to achieve all its poses.
It's annoying that I need to switch the skeleton property in the skeleton renderer instead of just switching animation.

it makes the underlying code really difficult to maintain, and same problem for asset management. And I don't talk of the extra data needed in an eventual FSM to handle that if we're unable to use mecanim.

SO, for now I really think Spine is amazing as an animation tool( with the new amazing feature, it'll reach ubiart's madness), but not really usable as a runtime solution for unity for complex projects. It's just "OK" for prototyping now.
I mean this solution isn't just intended to make small and simple characters, even if the only projects using spine so far never use the full artistic power of the tool. I mean, vanillaware's Dragons crown amazing characters were made with a tool like spine. But in order to achieve such a result we need a more comprehensive unity Framework.
mecanim is the major tool of unity. most complex things in video game are state handling and management, and should it be for AI, game states, GUI or anything else, it always end up to animation blending and trees. And small independant teams working on unity need these Tools, they choosed unity for this, moslty.

I'll be glad if I can help with the unity runtime, and as soon as my research lead me somewhere, i'll let you know.

All the best, and keep the good work!

Cheers.

 

I'm afraid I'm not familiar with mechanim. It'll be some time before I have the bandwidth to dig into it. I'd love to see what you can come up with though!

Two skeletons in the same file doesn't make a lot of sense. Each skeleton is its own object graph. Recently I was playing with skeleton attachments, which might help your scenario:
http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=1655&p=8569#p8569

I'm not sure why the Spine Unity runtime would only be useable for prototyping as it is now?

 

hey NateS, thanks for replying so quickly!

I may have been a bit rough I apologize as it was not my intention. What I mean is that a lot of indie developers have joined the unity community for some reason : unity is not just a Framework, but an extendable set of Tools and Editors. Mecanim is by far the most appealing feature in unity, and the 4.3 release has made a lot of improvements to make it usable in every part of the game.
Your tool, Spine, and all its power, cost a bit of money (which is normal, and i'll pay for it as soon as I have a clear idea of how to integrate it into my development process) and i think it"s a reasonable question, for a unity user, to ask how much time and effort (means money, again) it will take to integrate your file format and tool into the unity system in a seamless way : That is, use all its power without cutting into unity's power.

For the time being, the runtime you have seems great and have interesting performances. But it completely changes the workflow that we unity people are using - or are looking for.
It's a bit of a problem, to buy a quite expensive tool that will not fit into your current workflow, without having any idea of how it will evolve.
for exemple, realtime IK or animation blending, with skeleton masks, are certainly the most interesting possibilities offered by skeletal animations.
we know we can use it with directly if we had a runtime that takes advantage of native animation system, as for animations events, and so on.
using your solution, we have no idea if you'll have time to make it and how in parallel of extending Spine, and taking care of numerous other runtimes.
with unity system, we know as soon the unity guys make any improvement, we can befenit of it directly on our spine characters.

That's all these thought that made me say spine runtime is not ready to enter in a production pipeline. That's not true for anybody, but for me at least.
But i would have the same reaction with any tool offerring a runtime which override unity's natural and native systems instead of making use of them.
(it's different to provide a tool with functionnalities unity doesn't have at all)

BUT I agree with your point anyway, that unity aPIs are black boxes integrate seamlessly with such black boxes won't be a pleasure.

I'll definitely make some prototypes to see how I can modify your runtime to use all of unity's power.

Cheers, and good luck for your work on Spine. My reaction, i'd like to say, is the one of someone who love what you've done, and is really impressed by how fast you made all these amazing things a reality for any developer. I just want to use it but I think it lacks some rock solid implementation relying on existing and powerfull technologies we already have.

Cheers,
Pierre.

 

and thanks for the skeleton attachment thing, it looks like what i'm looking for, but i tried the trial version of spine to do something like this, and am not sure how to hide entire skeletons (do i really need to hide each slot manually ?) and how to keyframe such visibility tweaking. And not sure too of the performance in realtime ? have you tried this in real situation?

 

I'm hoping for some clarification on what you can do with the essential and professional versions of spine.

Can you deform the meshes of idividual sprites? By this I mean bending arms and such. If you CAN do this with the essential version then what is the difference between this and "free-form deformation" and "meshes"

Also, can you replace certain textures at runtime? For example equiping different weapons and armor?

 

Thanks for the explanation. No need for apologies, I'm not so easily offended on the internet, just trying to understand your point of view.

Being unfamiliar with mechanim, it isn't clear to me how closely its functionality matches what Spine needs. Anywhere there is a mismatch, my fear is the Unity black box doesn't offer a way to achieve what is needed. I haven't actually dug into it, so I'm just expressing my worries. If mechanim can be used to render Spine animations and that has a benefit for the Unity workflow and intergration, I'm definitely all for it.

I haven't made complete games with Unity, so it isn't clear how the existing runtime might be hard to integrate or, as you mentioned, how it is different from the workflow Unity users are used to. It seems to me a gameobject that you can tell to run an animation should fit pretty ok into the rest of Unity.

The skeleton attachment stuff in the thread I linked was just a proof of concept. It took very little code to create an attachment that renders another skeleton instead of an atlas region (can show it if you like). There needs to be a bit more work done before it gets included in the editor though, and meshes are higher priority.

You can hide an entire skeleton in the editor using the visibility dot next to the skeleton. This isn't keyable though. If using a "scene" skeleton as described in the thread linked above, you would hide a skeleton by hiding the attachment that is that skeleton.

Performance of attaching skeletons isn't much different than just drawing each skeleton separately, except there may be an additional texture bind to switch to the attached skeleton atlas, if the skeletons use different textures.

@TheValar, meshes are a polygon within your image. You can also have vertices and edges within the polygon. FFD is moving mesh vertices to deform the image. Essential won't have meshes or FFD, it will have what it has now.

Here is a video on how to switch images:
http://esotericsoftware.com/spine-videos/#in-depth.3A-image-switching

 

Yeah, you got a point with the simple gameobject playing animations

I may have to review my point of view, especially after I spent some time looking at your code :
your runtime sure is fine and really useful. Especially the C# core.
But, I think we can optimize the way skeletons are drawn and animated in unity, so we can use it's full power : modularity between systems and tools.
cos it really look like the runtime is thought for general purpose without unity in the line of sight. it's less time consuming to use native transforms, and animation system, than to implement your own.
But I understand the logic. you translated a generic runtime, intended to work on frameworks which have no builtin animation solutions,
and unity object keyframes (you animate objects properties, not just floats) is quite new and somewhat hidden - undocumented.

I have so far a working implementation spawning transforms into a game object hierarchy (instead of your proprietary bones) and saving your rotation/scale/position timelines into unity animationClip curves. (does not support spine curves at the moment, but no problem i can see for the future)
I next need to check how to store regions and future extra data for meshes into serialized objects and generate object reference keyframes in order to animate image attachments and so on.

Once I have my bone structure moving and my objects references tweaking, all driven by unity's animation system, and compatible with mecanim,
I'll just have to use a renderer like yours to read bones positions and transform vertices coords in worldspace.

so the only remaining things in the runtime are JSON parsing, a translator to save animations to unity's format, and a renderer.
put playback and transform maths are done by unity, and we have something really close to the way 3D skinnedmeshs work in unity, and full mecanim compatibility.

this way, you can use unity powerfull animation system, mecanim, and even attach anything to any transform, link custom animation events to your custom scripts, etc.

I'll stop wasting your time when I have all basic features working on unity's animation system, i'll show you what it looks like.

cheers!

 

Sounds exciting!

 

as you can see, rotation and scale timelines are applied to a simple transform hierarchy with unity animation system.
I need now to add slot component to some bones with a keyed object data describing what is framed (region, mesh, anything)
then in my renderer, I keep list of bones transform and slots and decide what to render and how.

I keep you updated on further progress, and may work on a "plugin" for your runtime, so people will be able to choose what they want.

 

It could also be exciting to work on a spine editor directly into unity :

-create hierarchy,
-create slots, put what you want in it (sprites, meshes)
-animate via unity and handlers on bones.

simple seems so anyway.

cheers.

Pierre.

 

Hi,

We plan on moving to Spine for our Unity game. Previously we have been using Smooth Moves but had a few frustrations and our animator saw Spine's editor UI and the upcoming mesh deformation features and so it was decided His biggest frustration up to this point (with Smooth Moves) has been attempting to prevent gaps from forming between bones.

A few little concerns and questions:

- We're using the new Unity 2D Sprite Renderer system, including atlasing and tight meshes. Is integration between Spine and these features forthcoming?
- Is it difficult to integrate with Unity's new Box2D physics implementation?
- Read a thread on Reddit where a long-time Spine user complained it was very difficult in the Unity runtime to do some basic tasks. I will quote the most concerning claims to us here. Of particular concern are the claims that blended multiple animations isn't supported (what?! we do a ton of this and it's a very basic/key feature...) and the bounds issue (seems like a killer). Comments please?

The original thread can be found here: http://www.reddit.com/r/Unity2D/comments/1sikn4/is_spine_animation_viable_for_unity_or_would_i_be/

 

Sorry I didn't see your post right away.

Unity doesn't expose much, so integration with their sprite stuff isn't possible. A Spine animation is just a GameObject though, so you can still use it together with their sprite stuff.

I'm not sure on the Box2D integration, but it shouldn't be too hard.

I hadn't seen that reddit post. The user missed events, so I'm not sure how hard they really looked at Spine. Animations that show/hide attachments should work, same for mixing animations. There was a recent thread about the mesh bounds and culling, I think a RecalculateBounds() method needs to be called, but I haven't had a chance to look at it. Using Spine for cutscenes is possible, but doesn't yet have all the features needed. See the skeleton attachment stuff linked a few posts back:
http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=1655&p=8569#p8569

 

Hey man. Looks like we're doing the same things =).
Today I've implemented sprite shift animation.


I host my code here https://github.com/nicloay/unity-spine-importer/releases if you wish we can cooperate to doing what you want.
I'm totaly agree with you, that unity features is good, and

 

I've made first beta version of spine exporter.
It's not a run time, and just build unity objects (animator, animation, spritesheet + skin controller script)
It's not support all spine features.
Currently it doesn't support following things:

• regionsequence
• color animation
• mesh animation
• smooth animation (unity bezier points is very different with spine http://answers.unity3d.com/questions/623318/how-to-convert-cubic-bezier-curve-into-animationcu.html)
• events (not an issue)
• draworder (not an issue)
• Export several json files with shared atlas (spine project with several sceleton

it's available here https://github.com/nicloay/unity-spine-importer/releases

 

Great!

 

This is just AMAZING! We will finally be able to use Spine animations in Unity without getting mad!
Question: will it be possible to create legacy animation instead of mecanim animations?

 

Sorry, currently I'm not very experienced at unity animation workflow.
But if you are asking about to use this animation http://docs.unity3d.com/Documentation/Components/class-Animation.html controller instead of mecanim animator and state machine - yes, you can use generated animation files at this controller as well.

 

Thank you for your answer! That's just perfect!

 

Hi Nicloay!
great job. Can you implement multiple atlas resolution?

When I tried to import dragon sample from Spine and create prefab, I got this error message:

-----
KeyNotFoundException: The given key was not present in the dictionary.
System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (.TKey key) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:150)
UnitySpineImporter.SpineUtil.updateImporters (UnitySpineImporter.SpineMultiatlas multiatlas, System.String directory, Int32 pixelsPerUnit, .SpritesByName spriteByName) (at Assets/UnitySpineImporter/Scripts/Editor/Util/SpineUtil.cs:78)
UnitySpineImporter.SpineImporterWizard.OnWizardCreate () (at Assets/UnitySpineImporter/Scripts/Editor/SpineImporterWizard.cs:52)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
UnityEditor.ScriptableWizard.OnGUI ()
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.

 

I will try, currently you need to manually set maximum size from 1024 to 2048.

 

You mean, this error message is because of the atlas size?

 

I think so, problem is that script does not set sprites correctly because of size. E.g. sprites coordinates come with rect [1500,800,200,200] and default size is 1024x1024, this rect does not fit in the size and unity ignore this sprite. (i faced this problem as well while i developed this package).
Try to change atlas size to 2048 and i think it will work.
This is an issue number 1 https://github.com/nicloay/unity-spine-importer/issues/1 =) and i think i'll fix that on the next release.

 

Just curious if anyone can explain why they prefer this workflow over using the Spine runtimes?
Excellent work and thanks very much for sharing it, by the way. I know that represents a lot of hours.

 

I think native spine runtime works faster, but main reason why i did that is to use result animation with unity mecanim, and also you can easy integrate generated model with native 2d tools (colliders joints and so on)

 

i've updated my package and included following things:

Features:
Avatar mask for mecanim animatotr
Automatically recognize atlas size (#1)
Import settings switch between mecanim and legacy animation (#2)

Bugfix
Skincontroller setDirty() on skin update (#3)

take it here

 

Great, works perfectly!

 

Going to have to check this out - it's really interesting. I'm a big fan of Spine and have a Pro license, but I've got to agree with others that the Unity workflow could be so much easier. (No offense, Nate) This looks very promising! affreuxgeorges, interested to see where yours goes as well.

In the meantime, I recently came across Unity Sprites and Bones, which is open source and free. The in-Unity editor probably isn't up the standard set by Spine, but hey, it works and it is pretty cool. Being open source, maybe there's something you guys can use there in your Unity integrations. (however the licensing works for that sort of thing, I'm not too sure.)

 

The MIT license certainly allows that. But I would prefer, if you take something, that you contribute something back.

 

I was wondering is there a way to blend two animations in Spine through code? The spineboy example scene doesn't seem to cover that?