Spine 3.6 - Tint black, clipping, weight painting, and more!

June 19th, 2017

After a few months of work, we've finally completed Spine 3.6! The focus was mainly on things that have been bugging both you and us for a while, including hundreds of small improvements to existing features and bug fixes. On top of that, we managed to add a few great new major features, see below!

For a full run-down, check out the editor changelog, as well as our brand new runtimes changelog. All the runtimes are already up to date and work with 3.6.


While the Spine Runtimes faithfully reproduce your animations in your games as you see them in the editor, it was previously only possible to review transitions in-game. In 3.6, you can now preview your animations using many of the same controls that are available to you at runtime, including modifying your setup pose and animations while the preview is running! The usefulness of seeing your animation at the same time you are editing that animation cannot be overstated.


The new clipping feature lets you define a polygonal area, similar to a bounding box attachment, that will mask other slots in the draw order. The clipping area can be any concave polygon without holes and self-intersection. You can also animate the clipping area vertices. Only one clipping area can be active at a time.

Clipping is implemented CPU-side in all runtimes, as most engines do not support direct stencil buffer access or masking. Clipping can be a very expensive operation, especially if you use dense mesh attachments. Always check the performance of your clipped animations on your target platforms.

Tint black

This makes for more powerful tinting so you get more out of your images. You can do some nice effects, like the Super Mario invincibility star flashing, solid color outlines, inverted colors, and more. It can also look nice when using additive, screen, or multiply blend modes.

Tint black is supported by all runtimes except spine-ts Canvas, spine-corona and spine-sfml due to API limitations of the respective framework/engine.

Mesh manipulation tools

Modifying vertices in a dense mesh attachment is now considerably easier with our improved mesh manipulation tools. You can now select multiple vertices through soft selection and then scale, translate and rotate the selected vertices as a group! Feathered soft selections will apply your transforms only partially.

Weight painting

In tandem with our new mesh manipulation tools, we've also introduced weight painting tools. The weight painting tools come with feathered brush support and different weighting modes, complimenting the existing automatic and manual weighting functionality.

Point attachments

This new type of attachment is a point in space and a rotation, which is transformed by parent bones like you'd expect. It can be used to spawn particles or do anything else that involves a position and/or rotation. Point attachments have one advantage over bones: a point attachment can go in a skin, so the position and rotation can change for different skins. For example, different guns may shoot from different positions.

Improved file dialogs

Many workflows involve working in a handful of directories. We've introduced new file dialogs that show you recently opened project files and often used directories. You can explicitly favorite a file or folder for it to show up at the top of the list. Right clicking an entry will remove it from the list. The filter box allows you to quickly filter for files by parts of their name. We've also added a few hot keys to make your file browsing even more efficient. Pressing enter will chose the most recent file or folder, pressing spacebar will immediately open the OS file dialog if you can't find the file or folder you want in your recently used lists.

AnimationState improvements

AnimationState is a part of the Spine Runtimes which controls applying and queuing animations, crossfading between animations, and layering animations on top of each other. With the 3.6 release, we've vastly improved on the previous implementation, ensuring that transitions between queued animations are always smooth, without bones snapping into place. You can read more about the inner workings in our blog post AnimationState: multiple mixing without dipping.

Runtime improvements

Alongside the improvements to the Spine editor, we've also put a lot of work into making the official Spine Runtimes better!

We've added support for clipping and point attachments to all runtimes. Tint black is supported in all runtimes except spine-sfml, spine-ts canvas, and spine-corona. The tint black feature requires additional vertex attributes which these engines currently do not support.

The libGDX runtime is now also released to Maven Central. The version string is composed of the latest Spine Editor version the runtime supports, plus a patch version. The latest beta version is also continuously built and deployed to the SonaType snapshot repository.

The Cocos2d-X and Cocos2d-ObjC runtimes have seen performance gains of up to 15% by removing all per-frame allocations. We've completely rewritten the rendering infrastructure and also added mesh debug rendering support!

The Unreal Engine 4 runtime is now using the excellent RuntimeMeshComponent instead of the built-in ProceduralMeshComponent. That also means that you have to copy over the RuntimeMeshComponent plugin to your project's Plugins folder! This change was required to implement the tint black feature, for which we need custom vertex attributes. We've also ensured that the runtime works with the latest Unreal Engine 4.16.1 release. Please note that Unreal Engine 4.16 had a regression which made it impossible to compile plain .c files with MSVC++. We've submitted a PR for this issue which is now in 4.16.1!

spine-unity now supports tint black via the UV2 and UV3 vertex buffers and special tint black shaders. This capability is now shared across all Spine rendering components via the new single Spine.Unity.MeshGenerator class. You can also set the initial flip state of your skeleton in the inspector. On the Unity Editor side, we've added several improvements and tools. The biggest change you'll notice is that [SpineAttributes] now show icons in their inspector dropdown drawers so your inspectors are more readable at a glance! They can also use sibling fields as data fields so you can limit your scope within your custom serializable structs/classes (previously, it only used fields your Component class). Two new windows were also added: SkeletonDebugWindow for seeing invisible skeleton parts in Scene View and runtime debugging skeleton states, and SkeletonBakingWindow for accessing specialized baking features.

Both the spine-ts WebGL and Widget backends now support WebGL context loss recovery out of the box! The feature is on by default. We've also increased performance of the WebGL and Widget backends considerably by being smarter about what data we move to the GPU and when.

The spine-ts Canvas backend now supports shear and alpha tinting. Full color tinting is sadly not supported as the Canvas API does not expose this feature.

For a full list of changes to all runtime, check out our new runtime CHANGELOG, which details API breakage, additions, as well as new features and improvements!

New runtime branching model

Up until this release, the master branch on our spine-runtimes GitHub repository was the latest stable release you should use. Starting today, we are removing the master branch and will henceforth use branches named after major Spine versions. The latest stable version will be the default branch on GitHub, e.g. 3.6 for the current release, while development will happen in the beta branch of the next version, e.g. 3.7-beta.

If you have scripts of continuous integration builds that rely on master being the default branch, now would be a good time to update them and explicitly specify your Spine Runtime version!

Up next

With our kitchen sink release out of the way, we plan on shorter release cycles corresponding to single big features. Our roadmap for 3.7 will bring audio support, which will be available as a beta version surprisingly soon. On the runtime side, we will focus on documentation, samples, and performance improvements, as well as adding support for more engines.

Thanks to all of our users who reported issues, tested the beta, and proposed new features. We couldn't do it without you!

Happy animating! Your Spine Team

Discuss this post on the Spine forum.

Preview animations with mixing inside Spine

June 1st, 2017

Spine 3.6.22-beta has a new feature: the Preview view. This is allows you to play animations with mixing (crossfading) and tracks (layers), similar to the Skeleton Viewer. However, since you are previewing inside Spine, you can edit an animation while previewing it which is really, really neat!

It's currently a work in progress and has some known issues that we are working on (such as images that aren't loaded), but we thought we might as well get it in the beta early, especially since it's so useful. We'll have more beta releases soon to fix it up, then 3.6 will be released as non-beta. We've already started on audio support for 3.7, which we intend to release in a much shorter time frame than 3.6.

Discuss this post on the Spine forum.

AnimationState: multiple mixing without dipping

May 16th, 2017

AnimationState is a part of the Spine Runtimes which controls applying and queuing animations, crossfading between animations, and layering animations on top of each other. In the Spine Runtimes 3.6-beta branch, we have an AnimationState update for you which provides a better method for crossfading and layering animations. This ensures animation transitions are always smooth, without bones snapping into place.

Multiple mixing

In the Spine Runtimes, "mixing" is what we call crossfading animations. Multiple mixing is where you are mixing animations a -> b, then you interrupt that mix by mixing to animation c. This is common when playing animations based on user input or when using long a mix duration between animations.

In Spine v3.4 and earlier, only two animations could be mixed. We would keep either a or b, whichever the interrupted mix was closer to, then discard the other animation, leaving a -> c or a -> b. This was suboptimal because snapping occurs when we stop applying an animation mid-mix.

In Spine v3.5 we improved AnimationState by supporting multiple mixing. This allows us to mix between 3 or more animations: a -> b -> c. Animation a is mixed with b and the result is mixed with c. Since we don't discard any animations, transitions are always smooth, without snapping.

The "dipping problem"

Unfortunately multiple mixing in v3.5 brought a new problem: when mixing a -> b, animation a is mixed out to the setup pose while b is mixed in. If both animations key the same bone property then at the start of the transition, as the application of animation a drops from 100%, the bone starts to mix out toward the setup pose. Meanwhile the application of b has just started rising from 0%, so doesn't have much impact. The end result is that the bone appears to dips toward the setup pose until b reaches more than 50%.

This has been dubbed the "dipping problem" on the Spine forums. Applying animations in this way allows AnimationState to support mixing any number of animations, but the dipping is quite noticeable in many situations.

The holy grail

In v3.6 we wanted to support multiple mixing without the dipping problem. This turned out to be a quagmire. It is surprisingly complex to combine 3+ animations in a smooth and efficient manner while still supporting all the AnimationState features.

After quite some effort, we ended up making multiple mixing optional. When off (the default) you got v3.4 behavior, when on you got v3.5 behavior. This wasn't a real solution, just a stopgap while we worked on two color tinting and clipping.

It took a few more months until we finally had a breakthrough, but now we are happy to report the problem has been solved! With some clever calculations, AnimationState now does multiple mixing without dipping. This is currently in the 3.6-beta branch, but should be a drop-in replacement if you'd like to use it with v3.5.

Discuss this post on the Spine forum.

3.6 beta has clipping

April 8th, 2017

3.6.14-beta is now available and it has clipping! To use clipping, create a clipping attachment which has a polygon similar to a bounding box attachment and an "end slot". All attachments between the clipping attachment's slot and the end slot are clipped by the clipping polygon.

When it comes to computer graphics, there are a few clipping techniques with various pros and cons. For Spine we used a CPU clipping approach because it has the best compatibility with game toolkits. This ensures clipping works in every game toolkit exactly like it does in the Spine editor. Other approaches using shaders either aren't possible in many game toolkits, or can cause conflicts with other shaders an app may want to use.

Keep in mind that clipping comes with a CPU cost. Using complex, concave clipping polygons increases the work that needs to be done. Also, the more triangles you are clipping (ie, complex or many meshes), the more work that needs to be done. If you are exporting images or video from Spine or making a desktop game, clipping performance is unlikely to be important. However, if you are making a mobile app, you will want to keep an eye on CPU usage when using clipping.

There are two additional caveats: 1) Only one clipping polygon can be active at a time, and 2) the clipping polygon must not self intersect, else clipping behavior may look strange.

We continue to work on clipping and other version 3.6 features, but we are happy that you can now try it out for yourselves.

Discuss this post on the Spine forum.