Spine: 2D skeletal animation

Hey guys, I'm Nate, co-author of libgdx and a number of OSS projects. I just wanted to drop in to spread the good word about a game development tool I've been writing with my good friend, Søren. I'm the programmer and he's the artist. The tool is called Spine and is used to build 2D skeletal animations specifically for games.

We are doing a Kickstarter and passed our intial goal in just 3.5 days! Two of our initial goals were for Unity: support for both Futile and 2DToolkit. So we'll do both of those, for sure. We now have ~13 days left and we've just posted stretch goals, which include a bunch of cool features.

You can see the Kickstarter here, and also a download link to try it now:
http://www.kickstarter.com/projects/esotericsoftware/spine

Hopefully you like our tool and can take advantage of the ~50% off you get by obtaining a license before the Kickstarter is over.



The dragon project was provided by ODI EntertaintmenT.

 

This looks awesome. Think I have to get it, because, well, I just don't want to not have that. =)

Edit: Pledged. Best of luck with this Nate, have looked for something like this a few times in the past but never found anything I wanted, until now. Can't wait to try it out.

 

That looks pretty sweet, and I think the pricing is great.

What about people making 2D games without a pre-made framework, though? I'm super interested in this, but so far haven't used a 3rd party 2D framework and don't plan on it. Having such dependencies would be a pretty big negative for me, personally.

Great work, though, and congrats on the successful Kickstart!

 

Cameron., thanks for the pledge, it is appreciated!

angrypenguin, with the generic runtimes, implementing a Spine runtime for your own framework shouldn't be hard.

 

Really like the look of this and glad to see you guys have been funded.

Can't pledge just now but set a reminder. Hoping I can pony up on the last few days.

 

Just spent half an hour or so playing around with this...

Absolutely in love with it. What sort of timeframe are we looking at for unity compatibility?

 

Thanks Seven. The Corona runtime is already done. We've been working on the cocos2d runtime, which will be available next. If forced to give a date I'd say that'll happen within a week or two, if not sooner. After that will be Unity Futile, which I expect won't be too hard. I've already spoke a bunch with Matt Rix, the Futile author. After that will be Unity 2DToolkit, which honestly I don't yet have a firm grasp on how much work that will take. These 4 toolkits I just mentioned are the original goals of the Kickstarter and will be done first, before any stretch goals (except for a few small features we've already finished). TLDR; we working hard and Unity will be done ASAP, Futile first then 2DToolkit.

 

This seems awesome, it's the exact kind of workflow my programmer centric mind is looking for. I'm really excited for the unity integration!

 

Pledged! After being disappointed about the lack of Unity support for Spriter (among other little things) I'm really looking forward to Spine. It's great that you guys have chosen to support the game toolkits yourself instead of relying on the community for those. I have been playing around with Spine and everything works awesome. Great job!

Now, if only more people would pledge, we can get some of those oh so juicy stretch goals. Bounding boxes, integrated texture packer and free-form deformation? Yes please! Come on people, only 6 more days to go! Spread the word!

 

Thanks guys! Only 7 hours left then the Kickstarter is over. Last chance to get a license at a big discount! Remember, you get all future updates for free.

 

Just grabbed a copy. The product looks awesome! Im very interested in the 2d toolkit support.

 

Wanted to drop a quick note to let you guys know the Unity support is ready for use:
https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-unity/Assets

 

Awesome! Great work on the speedy implementation. Going to test it out today.

 

This looks pretty wonderful. Looking forward to checking it out.

 

Update: It is indeed wonderful



The best part as far as I can tell: No Garbage Collection!

 

Oh, cool, didn't know Unity had pretty charts like that. Glad to hear I didn't have any allocations! Unity requires the mesh's arrays to be exactly the size needed. This means if you hide or show an attachment it will allocate to draw a different number of quads. I was thinking that we could zero the values for unused quads, possibly up to some threshold.

Nice purple slug thing!

 

Looks good, do you have a workflow from Spine to Unity please?

 

Bah, looked interesting so thought I might try backing it, only to discover it finished months ago

It does look good though and I'm pleased it doesn't depend on any other Unity plugin's. Though integrated support with other 2D plugins might be nice, it make sense that it can work standalone too.

Going to download the demo and check it out.

 

@derkoi, sorry there is not currently proper documentation, but you can check out the example project. This is enough for you to playback and blend different animations. For more advanced usage you can use the C# API, eg:
GetComponent<SkeletonComponent>().skeleton.SetAttachment("slot name", "attachment name");

 

Spine is really fantastic stuff, I absolutely love it. We bought it this week.

Unfortunately, It's currently fairly slow for mobile in any serious project due to the unoptimised playback routines in unity. I'm not sure if it generates garbage or not since Unity seems to be all over the place tonight.

I am interested in rewriting this and sharing my findings, but before I am pushed to that last resort I'd like to know if anyone else here has plans to do so? If so, perhaps we could work together on it. Or perhaps the author will find the time to do so.

Generally the C# back end for spine is great, it's just the unity part that could use improvement

 

Thanks for that Hippo. I almost bought it for a mobile project but decided to go with Smooth Moves.

 

Hrmm is the tk2d playback for spine any better?

 

Hi guys! We've discussed some of the performance with the Spine runtime for Unity here:
http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=795
I've made a few changes as a result. I think it is currently quite efficient, but I'd be glad to have your eyes on it and here any suggestions you might have.

If you would like to take a look, the Unity code is here:
https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-unity/Assets/Plugins/Spine
The C# code that uses is here (though I expect the Unity specific rendering code has the largest impact on performance):
https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-csharp/src

One feature it is lacking is using multiple materials with the same mesh. I'm not sure how that works at all.

 

I'm surprised people are having performance problems. I've been happy with the performance on a 4th gen iPod. Here's a scene that runs very smoothly on the iPod that I just tested (video is of the same scene on my pc):

https://vine.co/v/blJiaKA7V2x

There is a little bit of allocations, about 100 bytes per spline object. I actually switched to Spline because SmoothMoves was using quite a bit more and causing gc related lag.

 

Cool screenshot! I'd be interested where that allocation happens.

 

Great improvements. Just need to nail that final bit of garbage and it'll do fine for any project I suspect 100 bytes is hardly cause for alarm, but I believe I located it in the mix function somewhere - a dictionary thing, it happens when you SetAnimation, so it won't be very frequent and I doubt it would add up enough to get collected in a typical level.

 

Thanks Nate and thanks for looking into it Hippo. As you say 100 bytes isn't much, but if its possible to reduce it even more that would be great.

 

Hi, may i know what does slot name and attachment name refer to?

 

Slot name is the name of the slot in the editor. Attachment name is the name of the attachment in the editor (this is the path and file name relative to the images directory for the skeleton).

 

First of all, we've been using Spine and so far it's great!

Using multiple materials on one mesh is super simple. The vertices and uv data on a mesh that you create are the same. the only thing that changes is that you basically create submeshes with the triangles. On the MeshRenderer, instead of setting (material or sharedMaterial) you have multiple. So you set the meshRenderer materials / sharedMaterials instead, then for each material you set all associated triangles with mesh.SetTriangles. Something like:

Code (csharp):

1.  
2. mesh.vertices = ...;
3. mesh.uv = ...;
4.  
5. meshRenderer.sharedMaterials = allMaterials;
6.  
7. for( int i = 0; i < allMaterials.Length; ++i )
8. {
9. int[] triangles = /* ALL TRIANGLES ASSOCIATED WITH MATERIAL i -- point to vertex indices, like regular mesh generation */;
10. mesh.SetTriangles( triangles, i ); // this creates all triangles that use sharedMaterials[i]
11. }
12.  
13. mesh.RecalculateBounds();
14. mesh.RecalculateNormals();
15.  

 

Thanks. I manged to work it out a while ago, so the Spine runtime for Unity has support for multiple materials. I tried to be as efficient as possible, though that makes the code a bit tricky. You can see it here:
https://github.com/EsotericSoftware...-unity/Assets/Spine/SkeletonComponent.cs#L101

 

Cool!

So currently when we use too many skeletal objects, the Unity profiler shows that recalculating the normals is taking up lots of processing. Is there any reason that it should be constantly recalculating the normals if they'll always be either (0, 0, 1) or (0, 0, -1) -- is there a situation where the vertices for triangles generated wouldn't be all on a single plane? Is there a way of caching that using the FlipX and FlipY data?

Also, in that code (https://github.com/EsotericSoftware...-unity/Assets/Spine/SkeletonComponent.cs#L199) wouldn't you only want to fill in the tangents array when it's being recreated?

So instead of (199-201):

Code (csharp):

1.  
2. if (tangents.Length != count) this.tangents = tangents = new Vector4[count];
3. for (int i = 0; i < count; i++)
4.     tangents[i] = new Vector4(1, 0, 0, 1);
5.  

Wouldn't it be safe to write:

Code (csharp):

1.  
2. if (tangents.Length != count)
3. {
4.     this.tangents = tangents = new Vector4[count];
5.     for (int i = 0; i < count; i++)
6.         tangents[i] = new Vector4(1, 0, 0, 1);
7. }
8.  

Thanks!

 

Of course you are right, good catch! Fixed. It isn't clear, do we need to call RecalculateNormals each frame? If not, when do we?

 

So my initial thought was that you could just cache all normals and set elements independently based on what vertices are associated with a given bone and how it is flipped.

The problem I'm realizing is that it just seems like setting the normals on the mesh is what causes it to slow down. Writing "mesh.normals = normals;" seems to be just as slow as calling mesh.RecalculateNormals(). Unity must have to rebuild the mesh if you replace the normals? Maybe I'm missing something... If that is the case, though, I'm not sure there's much that can be optimized other than only setting normals if at least one triangle has changed direction.

 

It's a big black box to me. I guess you need the normals since you went out of your way to enable them.

 

I'll keep looking into it and tell you if i find a general solution. If not we can definitely find a work around specifically for our project.

Thanks!

 

I have been banging my head against the wall, Can somebody tell me how to download that unity runtime without importing the while repository, and can the developer tell us if we can use this plugin without any 3rd party plugins, it would help if we can get some Unity-specific workflows to make simple animation in Spine and then how export it and reimported in Uniy and then play/stop it from code.
Is it too much asked? I think one page even without illustration can do it, you can't make a solution that works with 20-something environment and expect us to use it over built-in solution, I for one didn't know you could export 2d animations like this, it's almost magic but needs a little bit more docs and a simple way to doanload the runtimes.

 

You can download the runtimes from github:
https://github.com/EsotericSoftware/spine-runtimes
Click "Download ZIP" if you don't want to use git, or click this link:
https://github.com/EsotericSoftware/spine-runtimes/archive/master.zip
You get all the runtimes in the zip, just ignore everything except spine-csharp and spine-unity.

spine-unity is for Unity without any 3rd party plugins. spine-tk2d is for Unity using 2D Toolkit.

This page has instructions on how to open the example scenes and a tutorial video on how to set up new scene from scratch:
https://github.com/EsotericSoftware/spine-runtimes/tree/master/spine-unity

 

Thank you nate, so spine-csharp and spine-unity, but is it safe to delete the example and meta files? can you please tell us what is the bare minimum files to include right before building our games, a Unity-specific doc page would be awesome, after I played with the example I think I'm gonna upgrade from trial even with Unity 4.3 comig out, I doubt their animation editor and their dopesheet would match yours but full integration with SpriteRenderer would be best of both worlds, I wish you were dedicated more to Unity but a big thanks anyways.

 

Did a bunch of Unity stuff today (shadows, lighting, performance):
http://www.esotericsoftware.com/forum/viewtopic.php?f=7&t=1403&p=6731
Unity isn't a second class citizen, I'm afraid Spine is just light in runtime specific documentation. We have reasonably good docs for the stuff that is common to all runtimes:
http://esotericsoftware.com/spine-using-runtimes/

Yes, you can delete the example and meta files. You can just copy the Spine folder to your project and delete the meta files if you don't want them.

 

Runtime docs are fine, but workflow not so, there seems to be an Asset subfolder confusion and some missing references, I think a simple dll would be better, even better is making the whole editor an extension of unity, that would make a seamless integration with Unity2D and use its awesome mesh-based sprites and Texture Packer goodness, Box2D, etc, in 4.3. That way, only one Packed Atlas is needed (the one unity creates) and all performance issues are instantly fixed because no runtime is needed, man I would pay such a premium for such an extension, no pressure take all your time.
For the meantime I think I'm gonna buy Spine and try to export a json thing to see how all this works, thanks for your efforts Nate.

 

I wanted to bring to your attention the fact that Spine does its Skeletal Update based off of Unity's Time.deltatime, which is a bad thing when making games in Unity. Sometimes people want an animation to run even if Time.timeScale is set to 0, aka the game is paused. I have a separate timer I use in my game that sets time based off of Time.realtimeSinceStartup, for cases in which I want to animate or do things while the Time.timeScale is 0. Also, it's nice to give people the option to use Time.deltaTime or Time.realtimeSinceStartup based off of a bool setting, so that way they can pause the animation if they want it to.

I modified your code to use my timer, but perhaps you'd like to implement that in the Runtimes for the Spine Unity and Spine Unity 2D Toolkits on the Spine website.

Here's an example code for doing the Time.realtimeSinceStartup timer:

Code (csharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class TimeManager : MonoBehaviour
6. {
7.     protected float lastFrameTimeInterval = 0.0f;
8.     protected float timeElapsedSinceLastFrame = 0.0f;
9.    
10.     public static float TimeSinceLastFrame
11.     {
12.         get
13.         {
14.             return Instance.timeElapsedSinceLastFrame;
15.         }
16.     }
17.    
18.     // Use this for initialization
19.     void Start ()
20.     {
21.         lastFrameTimeInterval = 0.0f;
22.         timeElapsedSinceLastFrame = 0.0f;
23.     }
24.    
25.     // Update is called once per frame
26.     void Update ()
27.     {
28.         timeElapsedSinceLastFrame = Time.realtimeSinceStartup - lastFrameTimeInterval;
29.         lastFrameTimeInterval = Time.realtimeSinceStartup;
30.     }
31. }
32.  
33. // In your SkeletonAnimation.cs file:
34. override public void UpdateSkeleton () {
35.  
36.         if(isTimeScaleIndependent)
37.         {
38.             state.Update(TimeManager.TimeSinceLastFrame);
39.         }
40.         else
41.         {
42.             state.Update(Time.deltaTime * timeScale);
43.         }
44.  
45.         // Apply the animation.
46.         state.Apply(skeleton);
47.  
48.         // Call overridden method to call skeleton Update and UpdateWorldTransform.
49.         base.UpdateSkeleton();
50.     }
51.  
52.  

 

Hmm, I see, thanks for the input! I've adjusted UpdateSkeleton to take a "float deltaTime". SkeletonComponent passes Time.deltaTime, but if you want to use something else you can override UpdateSkeleton and call the super class method with a different value. This way you don't have to muck with the internals but it is still easy to use a different delta time.

 

Hi Nate, this looks great but I have some questions. I see that you guys have written your own code for updating the animation of the exports done from Spine (or am I wrong?). One time I worked on my own animation system but I never finished it, what I did then was that I generated animations using Unity's built in Animation and AnimationState classes. You seem to have written your own playback code? Have you thought about generating animations using the built in Animation classes from Unity? That might give you even better performance and compatibility with Unity. It would be even greater if it could use the Animator for Meccanim. I think that would be the best way to go rather than doing your own animation playback system.

 

This looks great!

 

@johot, I'm not familiar with Unity's animation system. The Spine runtime for Unity handles skeletal animation in exactly the way needed to support all of Spine's features. It is unlikely Unity's system will be a perfect match. Also, Unity's APIs are a black box, which limits how much customization can be done.

 

I was wondering if you guys were adding anything to Spine to work with Unity's new 4.3 2D animation system, or are you keeping it separate for now?

 

For sure, we will take advantage of their texture atlas stuff and everything else we can. Right now though I'm focused on free form deformation and other new features, so it'll be a little while. The runtime as is still works with Unity of course.

 

Look like a nice tools, I am just worried about performance in mobile , we get rid of tool like sprite studio because of it horribly performance heavy regarding how animation get updated.

Hopefully you take advantage of Unity way of slicing sprite and why not try to actually create Animation clip from your animation data, which would let us use native animation stuff from unity, instead of having routine on top doing that ..

anyway keep it up , it look promising !

 

Not sure why you are worried about performance with the Spine runtime for Unity. I put lots of effort into making it efficient. I don't think you will find it to be a performance problem on mobile. It writes values to a mesh directly, uses a number of optimizations (such as a double buffered mesh), and does everything it can to avoid GC. It also supports submeshes so an atlas can have multiple pages.