Spine: 2D skeletal animation
by Nate · in Torque 2D Beginner · 02/14/2013 (5:58 am) · 19 replies
Hey guys, just wanted to drop in to spread the good word about a game development tool I've been writing with my good friend, Soeren. 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! We now have ~8 days left and we've just posted stretch goals, which include our plan for how to get Spine runtime support for almost all game toolkits. We just reached our goal for a generic C++ runtime, so support for Torque2D shouldn't be hard at all.
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.
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.
#2
Being my main focus in gaming has been as a programmer, my other main interest lies within Animation. I'm particularly fond of 2d, and I believe that either Spine or Spriter would be a huge boom to T2D.
I have worked on developing Spriter integration, but if Spine is going to be officially backed, I can switch gears.
Looking forward to either or both, but most importantly.. the future of 2d animation!
02/14/2013 (9:07 am)
I've been looking at this product as well as Spriter, and Spriter has a big head start. I guess it's all a mater of how the integration works between the programs, whether one is easier than the other.Being my main focus in gaming has been as a programmer, my other main interest lies within Animation. I'm particularly fond of 2d, and I believe that either Spine or Spriter would be a huge boom to T2D.
I have worked on developing Spriter integration, but if Spine is going to be officially backed, I can switch gears.
Looking forward to either or both, but most importantly.. the future of 2d animation!
#3
@Doc308, as a competitor it wouldn't be nice for me to comment on Spriter. I will say that both workflow and game toolkit integration is important. I suggest creating a simple animation in both Spine and Spriter to see which you like. Keep in mind being able to tweak and refine is important to creating high quality animations.
02/14/2013 (10:59 am)
@Michael Perry, thanks a lot! :) Would you mind if we used your quote, "I am a huge fan of Spine. The tool is absolutely amazing.", on our Kickstarter page? :)@Doc308, as a competitor it wouldn't be nice for me to comment on Spriter. I will say that both workflow and game toolkit integration is important. I suggest creating a simple animation in both Spine and Spriter to see which you like. Keep in mind being able to tweak and refine is important to creating high quality animations.
#4
02/14/2013 (11:10 am)
The output for this would be a great candidate for utilizing the capabilities of the new CompositeSprite object....
#5
It's projects like these that bring back my passion for 2D. Do you have an idea of how long it will be before the C++ plugin will be available?
I'd really like to be able to set up something simple and test the product inside the engine.
02/14/2013 (11:13 am)
Nate, I'm really glad to see your positive attitude, even with competition out there. I see good and bad things in both products, but a very bright future for both. I'll be pitching in at least $30 for the license before the kickstarter ends (I'd do more if I could, but.. well.. times are tough). I'm glad you met and exceeded your goals tho!It's projects like these that bring back my passion for 2D. Do you have an idea of how long it will be before the C++ plugin will be available?
I'd really like to be able to set up something simple and test the product inside the engine.
#6
02/14/2013 (11:48 am)
@Nate - Absolutely. Quote away. If there is any way you can include Torque 2D in the quote, I'd also appreciate it. Either listing me as a Torque 2D developer or something along the lines of me looking forward to having Torque 2D utilizing Spine. 
#7
I want Onion Skinning and Free form Deformation!
02/17/2013 (11:51 am)
I have backed this project!I want Onion Skinning and Free form Deformation!
#8
02/19/2013 (11:19 am)
Backed ;-) 
#10
02/20/2013 (6:15 am)
In all honesty hadn't heard about this until this morning, had a look and downloaded the trial (shame export is disabled as I wanted to try that). However as it looks good so backed it and hope export is OK.
#11
02/23/2013 (4:35 am)
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. :)
#12
03/12/2013 (1:11 pm)
Congrats on having a super successful campaign Nate. We've already started making some basic changes to the core engine that will make a Torque 2D implementation a snap. Can't wait until we can all be using Spine.
#13
03/12/2013 (5:20 pm)
That sounds awesome. :) I can't wait to be working on the runtimes again, I'm in a bit of a quagmire getting OpenGL to work on all platforms (Mac giving the most problems). Almost have that sorted though, and then I can move on to the runtimes.
#14
Anyway, we created a small test using the system we will recommend when you start on the T2D runtime. We utilized the CompositeSprite system to piece together multiple, smaller sprites, and animated them using a very simple sin wave algorithm. It's just one way, but it seems like the most ideal approach for Spine.
We were even going to attempt to get Spine in for the sake of compiling, but were unable to because the cpp runtime is currently bound to SFML. Anyway, all of this will be well documented for when you do get back to runtimes. Good luck!
03/12/2013 (7:08 pm)
I feel your pain. Anytime I'm working on a big task for the Mac, I always find one hurdle that keeps me hung up to the point of fury. Xcode certainly doesn't help things, which is why I switched to using AppCode. Anyway, we created a small test using the system we will recommend when you start on the T2D runtime. We utilized the CompositeSprite system to piece together multiple, smaller sprites, and animated them using a very simple sin wave algorithm. It's just one way, but it seems like the most ideal approach for Spine.
We were even going to attempt to get Spine in for the sake of compiling, but were unable to because the cpp runtime is currently bound to SFML. Anyway, all of this will be well documented for when you do get back to runtimes. Good luck!
#15
03/12/2013 (7:14 pm)
Sounds great! Yeah, I need to break SFML into it's own project. You'll have to leave some work for me to do! ;) I hope to have this nonsense cleared up in a couple days so I can focus on making progress on the goals.
#16
03/12/2013 (7:20 pm)
Haha. No worries. The heavy lifting of getting Spine running will totally be left to the expert (you). We just wanted to make sure T2D was in the best possible place to accommodate it. 
#17
I just wanted to pop in and inquire about a status update on this effort.
@Nate - For what it's worth, many of the T2D MIT users are begging for an editor to work with the system. While that task is being properly pursued and guided by Mich and the rest of the steering committee, you stand to form a significant following by getting a runtime for T2D fully implemented.
There are many artists out there who have expressed interest in T2D MIT but who are mulling about the possibilities as opposed to working with the engine. Spine presents an immediate opportunity for those artists to begin working with developers.
@Mich - This CompositeSprite "test" that you mentioned: Does that extend the functionality of CompositeSprite by adding new fields/methods for potentially working with the Spine JSON data, whereas a CompositeSprite now encapsulates its own environment to operate independently of the World environment?
Basically, I'm wondering if, since a CompositeSprite is really the ideal solution for creating truly rigid joints (i.e. previously "mounting" in T2D/TGB), introducing this new functionality would be best served as a new T2D native type (something like CompositeSpriteAnimation that would be utilized by a like-minded CompositeAnimationAsset ) that can operate under its own rules within its own context but, as a whole object, responds to the World settings accordingly.
Hopefully, that makes sense. What I'm basically inquiring is whether or not it is feasible (performance-wise) to have multiple Box2D World environments running, where we have the traditional global World settings but then any CompositeAnimationAsset can establish its own Box2D World.
1. The CompositeAnimationAsset, as a whollistic instantiated object, responds to the Box2D World settings as any other object.
2. The Sprites that make up the CompositeSpriteAnimation respond to a self-contained World, a simulation within the simulation, if you will.
I know this could be emulated by adding various damping, gravity scale, density, friction, et al, to each sprite individually, but that seems a bit excessive.
I think it would be tremendous to have an animation created in Spine to react appropriately to a Box2D World setting within its own context.
Does that make sense?
Thank you,
Brian
03/25/2013 (7:24 am)
Hi All;I just wanted to pop in and inquire about a status update on this effort.
@Nate - For what it's worth, many of the T2D MIT users are begging for an editor to work with the system. While that task is being properly pursued and guided by Mich and the rest of the steering committee, you stand to form a significant following by getting a runtime for T2D fully implemented.
There are many artists out there who have expressed interest in T2D MIT but who are mulling about the possibilities as opposed to working with the engine. Spine presents an immediate opportunity for those artists to begin working with developers.
@Mich - This CompositeSprite "test" that you mentioned: Does that extend the functionality of CompositeSprite by adding new fields/methods for potentially working with the Spine JSON data, whereas a CompositeSprite now encapsulates its own environment to operate independently of the World environment?
Basically, I'm wondering if, since a CompositeSprite is really the ideal solution for creating truly rigid joints (i.e. previously "mounting" in T2D/TGB), introducing this new functionality would be best served as a new T2D native type (something like CompositeSpriteAnimation that would be utilized by a like-minded CompositeAnimationAsset ) that can operate under its own rules within its own context but, as a whole object, responds to the World settings accordingly.
Hopefully, that makes sense. What I'm basically inquiring is whether or not it is feasible (performance-wise) to have multiple Box2D World environments running, where we have the traditional global World settings but then any CompositeAnimationAsset can establish its own Box2D World.
1. The CompositeAnimationAsset, as a whollistic instantiated object, responds to the Box2D World settings as any other object.
2. The Sprites that make up the CompositeSpriteAnimation respond to a self-contained World, a simulation within the simulation, if you will.
I know this could be emulated by adding various damping, gravity scale, density, friction, et al, to each sprite individually, but that seems a bit excessive.
I think it would be tremendous to have an animation created in Spine to react appropriately to a Box2D World setting within its own context.
Does that make sense?
Thank you,
Brian
#18
1. Our current example of a complex object showing animation
What you want to look at is WaveComposite. This class is similar to CompositeSprite. It has the same inheritance, then adds a few extra fields that will animate its internal sprites on a sin wave animation. The source is in 2d/experimental/composites. The toy is in modules/Experiments/WaveComposite.
If you want to see something more sophisticated, you should check out my T2D fork. Kirk, Melv, and I are collaborating on implementing Spriter support. This is work is going down a different route. The SpriterComposite does not actually inherit from CompositeSprite. It inherits from SceneObject and SpriteBatch.
Additionally, we have added a SpriterAsset. This new asset type will read in a file (.SCML), process it into a DOM, and prepare the structure for animation. The SpriterComposite takes in a SpriterAsset, and will be responsible for creating the sprites and animating them.
We are adding Spriter support for two reason. First, we want to support it. Spriter is a great tool and is basically ready for implementation. Two, it sets the stage for Spine support. A Spine implementation will follow the same path, but with its own internals for parsing a Spine export, building the sprites, and driving the animation.
2. Spine animation support
Spine, similarly to Spriter, allows an artist to animate complex sprites along a timeline. The final animation has a fixed animation. Having physics stomp over those animation keyframes would result in a game animation that looks nothing like what the artist created. What would be better is to have basic IK support. For example, a character's walk animation looks the same in the game as it did in Spine. The only outside influence might be the character's "step height" when they are going up stairs. This is further down the road and outside very basic animation support in T2D.
3. Complex objects that represent an animated puppet, affected by physics simulation
Currently CompositeSprite sprites use warping to set X and Y positions, which is not accommodating to a physics simulation. This is ideal for an animation engine provided by tech like Spine. What you are talking about here is completely separate from an animation engine. This is a complex object with full physics reaction, like a rag doll. Two separate concepts.
4. Multiple b2World simulations
Yes, it's possible to have multiple b2World simulations in a single game. I have not tested the performance, but I think the better point to focus on is "Why?". Based on my above explanations, you don't need multiple b2Worlds to support Spine, Spriter, or physics driven puppet animations.
03/25/2013 (8:10 am)
@Brian - I think you are jumbling up too many different feature ideas. Your post can be broken down into the following topics (number not related to your list):1. Our current example of a complex object showing animation
What you want to look at is WaveComposite. This class is similar to CompositeSprite. It has the same inheritance, then adds a few extra fields that will animate its internal sprites on a sin wave animation. The source is in 2d/experimental/composites. The toy is in modules/Experiments/WaveComposite.
If you want to see something more sophisticated, you should check out my T2D fork. Kirk, Melv, and I are collaborating on implementing Spriter support. This is work is going down a different route. The SpriterComposite does not actually inherit from CompositeSprite. It inherits from SceneObject and SpriteBatch.
Additionally, we have added a SpriterAsset. This new asset type will read in a file (.SCML), process it into a DOM, and prepare the structure for animation. The SpriterComposite takes in a SpriterAsset, and will be responsible for creating the sprites and animating them.
We are adding Spriter support for two reason. First, we want to support it. Spriter is a great tool and is basically ready for implementation. Two, it sets the stage for Spine support. A Spine implementation will follow the same path, but with its own internals for parsing a Spine export, building the sprites, and driving the animation.
2. Spine animation support
Spine, similarly to Spriter, allows an artist to animate complex sprites along a timeline. The final animation has a fixed animation. Having physics stomp over those animation keyframes would result in a game animation that looks nothing like what the artist created. What would be better is to have basic IK support. For example, a character's walk animation looks the same in the game as it did in Spine. The only outside influence might be the character's "step height" when they are going up stairs. This is further down the road and outside very basic animation support in T2D.
3. Complex objects that represent an animated puppet, affected by physics simulation
Currently CompositeSprite sprites use warping to set X and Y positions, which is not accommodating to a physics simulation. This is ideal for an animation engine provided by tech like Spine. What you are talking about here is completely separate from an animation engine. This is a complex object with full physics reaction, like a rag doll. Two separate concepts.
4. Multiple b2World simulations
Yes, it's possible to have multiple b2World simulations in a single game. I have not tested the performance, but I think the better point to focus on is "Why?". Based on my above explanations, you don't need multiple b2Worlds to support Spine, Spriter, or physics driven puppet animations.
#19
Well, after a six-month hiatus from Mt. Dew, I have, once again, succumbed to its beckoning. That sweet nectar of the programming gods has refired areas of my brain that layed dormant--thus leading to frequent bouts of incoherence.
That being said, thanks for pointing out your efforts in the development branch. I will check out that WaveComposite.
I agree that there is an added level of complexity here. However, I have been reading through Erin Catto's (Box2D creator) GDC2012 "ragdoll" presentation and it seems to me as if his approach would be a logical solution for T2D.
Essentially, ragdolls are spawned at triggered events from a keyed animation's world interaction. This is exactly what I was trying to, unsuccessfully, explain.
He says:
So, I see the possible implementation of such a "ragdoll-esque" solution as being intimately tied in to the animation system. essentially, we are looking at a rigger system that ties to the animation system but is driven by the physics and event-based systems.
So, the keyed animation is carried out as designed by the artist until an event triggers the "turning on" of the 2D-ragdoll-like rigging (which are just Box2D's standard collision shapes and joints) and the world physics just take over from there.
It does read as very complicated but the approach Erin took really seems pretty straight forward. I am by no means trying to devalue the amount of effort such an implementation would take but to rather gauge what others feel about the importance and usability of such a feature while T2D MIT is still young and susceptible to the influences of developers with, shall we say, ambitious ideas.
At least one benefit I see to implementing Erin's solution is that we would not be susceptible to most of the potential "issues" that he experienced in a 3D world.
The PDF I referenced can be found here.
Thanks again for your input and explanations. I appreciate the conversation.
- Brian
03/25/2013 (2:17 pm)
@Mich - Thanks for providing feedback so quickly.Quote:I think you are jumbling up too many different feature ideas.
Well, after a six-month hiatus from Mt. Dew, I have, once again, succumbed to its beckoning. That sweet nectar of the programming gods has refired areas of my brain that layed dormant--thus leading to frequent bouts of incoherence.
That being said, thanks for pointing out your efforts in the development branch. I will check out that WaveComposite.
Quote:This is ideal for an animation engine provided by tech like Spine. What you are talking about here is completely separate from an animation engine. This is a complex object with full physics reaction, like a rag doll. Two separate concepts.
I agree that there is an added level of complexity here. However, I have been reading through Erin Catto's (Box2D creator) GDC2012 "ragdoll" presentation and it seems to me as if his approach would be a logical solution for T2D.
Essentially, ragdolls are spawned at triggered events from a keyed animation's world interaction. This is exactly what I was trying to, unsuccessfully, explain.
He says:
Quote:One thing to keep in mind is that a physics engine doesn’t know a ragdoll is a ragdoll. The physics engine just sees some rigid bodies, collision shapes, and joints. The physics engine doesn’t know how the ragdoll is authored, how it hooks into the animation system...
So, I see the possible implementation of such a "ragdoll-esque" solution as being intimately tied in to the animation system. essentially, we are looking at a rigger system that ties to the animation system but is driven by the physics and event-based systems.
So, the keyed animation is carried out as designed by the artist until an event triggers the "turning on" of the 2D-ragdoll-like rigging (which are just Box2D's standard collision shapes and joints) and the world physics just take over from there.
It does read as very complicated but the approach Erin took really seems pretty straight forward. I am by no means trying to devalue the amount of effort such an implementation would take but to rather gauge what others feel about the importance and usability of such a feature while T2D MIT is still young and susceptible to the influences of developers with, shall we say, ambitious ideas.
At least one benefit I see to implementing Erin's solution is that we would not be susceptible to most of the potential "issues" that he experienced in a 3D world.
The PDF I referenced can be found here.
Thanks again for your input and explanations. I appreciate the conversation.
- Brian
Community Manager Michael Perry
ZombieShortbus
I will personally be adding my own backing this week, even though it has already been successfully funded. I encourage others to do the same, because this tool can only get better from here with additional funding.
If there is anything Melv or I can do to help with any possible integration with Torque 2D, be it feedback on the generic C++ runtime or a specialized plugin, just let us know.
Making this a sticky so it stays at the top of the forum.