spine-as3 and spine-starling development with Visual Studio Code

October 29th, 2019

At Esoteric Software, we work with a lot of different development environments and programming languages to ensure top notch Spine Runtimes support. Our development machines are full of different SDKs, IDEs, and compilers that we need to be able to switch between quickly and keep up-to-date. Quite the task!

Every now and then there is an opportunity to converge on a single tool for multiple purposes. In today's blog post we want to discuss such a convergence in the case of our ActionScript3 and Starling runtimes.

FDT - the old workhorse

When we started out with our Spine ActionScript and Spine Starling runtimes, we naturally gravitated towards tooling that we were familiar with. FDT is an Eclipse based integrated development environment for Flash development. Our Java background allowed us to quickly pick up FDT and create the first iterations of the these two runtimes.

While FDT is a great IDE, it also has some downsides. The source tree of an FDT project contains various FDT specific files, such as .project, .classpath, and the .settings/ folder which somewhat litter a pristine project directory.

Another downside of FDT is its lack of project dependency support in the free version. While we have a commercial FDT license, users of our runtime might not.

This meant we had to work around the dependency issue in a rather suboptimal way. The spine-as3 runtime is the base of the spine-starling runtime. Instead of linking the project, we have to compile a spine-as3.swc library file and copy it to the spine-starling project. This has to happen every time we change the spine-as3 runtime!

Worse, the example projects spine-as3-example and spine-starling-example also depend on spine-as3, which means even more copying.

Problems we encountered trying to get FDT to work on macOS Catalina finally made us look for alternatives.

Visual Studio Code - the new cool

Visual Studio Code is one of our main drives, especially when it comes to web development or work on our spine-ts runtimes. In our quest for an FDT alternative, we stumbled upon the ActionScript & MXML language extension for Visual Studio Code.

Combining these two pieces of software turned out to be a great set of tools for developing our spine-as3 and spine-starling runtimes!


Instead of 7-10 FDT specific project files, we now have 1-2 files per project, which feels a lot cleaner.

The extension supports all features you'd expect from a proper IDE, from debugging to code completion and light refactoring. Great!

One of the biggest selling points: no more dependency management issues! Each project can directly reference all the source files it needs directly. Changes to the base spine-as3 runtime are immediately reflected when running one of the example projects, without the cumbersome step of compiling an .swc and copying it around.

What it means for you

If you've been using the spine-as3 and spine-starling runtimes already, there aren't any big changes. The source folder structure is the same, so you can continue updating the sources directly.

If you have been using either runtime through the .swc files we provide, note that their location has changed. The spine-as3.swc file is now located in spine-as3/spine-as3/lib/, the spine-starling.swc file is located in spine-starling/spine-starling/lib.

If you want to run the example projects, or compile the .swc files from sources, you can now do so through Visual Studio Code. Here's how!

As a prerequisite:

  1. Install Visual Studio Code.
  2. Install the ActionScript & MXML extension for Visual Studio Code.
  3. Install Adobe Flash Player Projector version 32 with debugging support.
  4. Install the Adobe AIR SDK 32 by simply extracting it to a known location.

With all of this in place, you can now run the spine-as3-example project like this:

  1. Open the spine-as3-example/ folder in Visual Studio Code.
  2. Set the AIR SDK location when prompted.
  3. Launch the Launch Spine AS3 Example launch configuration.

That's it! If you want to recompile the spine-as3.swc file:

  1. Open the spine-as3/ folder in Visual Studio Code.
  2. Press CTRL + SHIFT + B (CMD + SHIFT + B on macOS) and select ActionScript: compile release - asconfig.json.

Similarly, running the spine-starling-example project goes like this:

  1. Open the spine-starling-example/ folder in Visual Studio Code.
  2. Set the AIR SDK location when prompted.
  3. Launch the Launch Spine Starling Example launch configuration.

And to compile the spine-starling.swc file (which will include the spine-as3 classes):

  1. Open the spine-starling/ folder in Visual Studio Code.
  2. Press CTRL + SHIFT + B (CMD + SHIFT + B on macOS) and select ActionScript: compile release - asconfig.json.

Unity Lightweight Render Pipeline support

August 26th, 2019

Animated Lightweight Render Pipeline Demo

We are happy to announce support for Unity 2019's Lightweight Render Pipeline in our spine-unity runtime!

The Lightweight Render Pipeline (LWRP) is a prebuilt Scriptable Render Pipeline (SRP) optimized for delivering high graphics performance. It scales seamlessly from mobile platforms to high-end PCs and consoles.

There is now an additional Unity Package Manager (UPM) package com.esotericsoftware.spine.lwrp-shaders available for download which extends the spine-unity runtime by adding LWRP support.

Why a separate package

Unity has moved many of their optional modules to the new Unity Package Manager (UPM) ecosystem. Their LWRP base shader files are also provided as a UPM package under the name Lightweight RP and not part of every new Unity project out of the box.

Including our LWRP Spine shaders in the spine-unity runtime would lead to confusing error messages and additional configuration steps in case Unity's Lighweight RP package has not installed in a project. By providing our LWRP Spine shaders as a UPM package, such dependencies are automatically resolved, making it easier to use this additional functionality.

Going forward, we will provide separate UPM packages for other spine-unity features that depend on Unity's optional packages.


You can download the UPM package via the download page or find it in the spine-unity/Modules subdirectory in the Git repository. After unzipping or cloning, you can make use of the package in one of these two ways:

Copy into your project

Copy the package contents to the Packages directory in your project. Unity will load it automatically.

Via the Package Manager

Copy the package contents anywhere outside your Assets directory, then open the Package Manager in Unity (via Window > Package Manager), select the + icon, choose Add package from disk..., and point it to the package.json file.

Window - Package Manager Add Package from Disk Select package.json

The Package Manager window will now list a Spine Lightweight RP Shaders entry:

Listed LWRP package

In the Project panel you will now also find a Spine Lightweight RP Shaders entry under Packages:

Project panel lists package

If the entry is not yet listed in the Project panel, you may need to close and re-open Unity.

LWRP example

The package contains an example scene similar to the animated GIF above at com.esotericsoftware.spine.lwrp-shaders-3.8/Examples/LWRP Shaders.unity for you to check out. It demonstrates how to use the LWRP shaders and will react to changing the settings of your current LightweightRenderPipelineAsset, set under Project Settings > Graphics.


The standard Spine shaders in the spine-unity runtime Spine/Skeleton Lit, Spine/Sprite/Vertex Lit, and Pixel Lit are not compatible with the lightweight render pipeline. Instead, the Spine Lightweight RP Shaders package provides three shaders specifically built for the lightweight render pipeline:

  • Lightweight Render Pipeline/Spine/Skeleton is a lightweight variant of the Spine/Skeleton shader.
  • Lightweight Render Pipeline/Spine/Skeleton Lit is a lightweight variant of the Spine/Skeleton Lit shader.
  • Lightweight Render Pipeline/Spine/Sprite is a lightweight variant of the Spine/Sprite/Vertex Lit and Pixel Lit shaders.

The shaders can be assigned to materials as usual via the Shader menu in the material properties:

Lightweight Shader Selection

Both lightweight shaders will respect your settings of the assigned LightweightRenderPipelineAsset under Project Settings > Graphics. The following GIF shows how characters in the scene are affected by changing these settings:

Project settings - LWRP asset

LWRP asset settings live update


Like all other Spine shaders, the LWRP shaders do not support Premultiply alpha (PMA) atlas textures when using the Linear color space. If you are using the Linear color space, please export your atlas textures as straight alpha textures by disabling the Premultiply alpha setting. See these instructions for straight alpha export and import settings for more information.

If you are unsure you can check the currently active color space via Edit > Project Settings > Player > Other Settings > Color Space.

Player Settings - Gamma

We hope that these additions to the spine-unity runtime let you create even more impressive games and apps for both high- and low-end devices. Share your thoughts on the forum.

Spine 3.8 released

August 5th, 2019

Summer is here and with it comes a brand new Spine release! Watch the video above or read on for a run-down of the most important new features below. Check out the editor changelog as well as our runtimes changelog for a more detailed overview of the latest changes.

Mesh tracing

skin bones

Spine can now trace an image to generate a mesh for you automatically. To see it in action, edit a mesh and choose Trace. The sliders control how many vertices are used and how they are placed. Automatic tracing is much faster than placing vertices manually. Spine uses advanced algorithms that work well even with few vertices, which is important for runtime performance.

Polygonal texture packing

Spine can now do polygonal texture packing. When chosen in the texture packer settings, mesh attachment vertices are used to pack images as tightly as possibly. This lets you fit more images into each texture atlas page and reduces the size of your exports.

Skin bones and constraints

skin bones

Next up is one of the most exciting features in this release! Skins can now have bones and constraints that are only active when the skin is active. When using skins for items, this means each item can have its own bones.

New tree settings let you hide inactive bones and constraints in the tree and viewport, so you can have as many skin-specific bones as you need, without cluttering up your project. Plus inactive skin bones and constraints are not computed at runtime, so there is no performance impact to having many skins with bones and constraints.

Skin bones and constraints can be used in other ways too! For example, a skin can use constraints to move bones so a skeleton and all its animations can be reused for characters with different proportions.

Drag and drop bones or constraints on to a skin to add them to the skin. Spine automatically adds other bones and constraints to the skin, if they are required. The tree shows a skin icon to indicate they are in a skin.

The tree shows warning icons if your skin bones and constraints cause unwanted results. For example, if a mesh that is not in a skin is bound to bones that are in a skin.

Mix and match project

We have a new example project called mix-and-match which shows off using the skin bones and constraints feature for user customizable avatars.

The mix-and-match example project is included in the latest Spine launcher which you install from your license page. We've also written an in-depth guide on how the project is setup.

Soft IK

skin bones

IK constraints now have a "softness" setting which slows down the bones as they straighten. Without this, IK bones will sometimes snap into place as the target goes out of range.



You can now use folders to group your animations, skins, and events. This makes organizing your projects a lot easier and reduces the amount of scrolling needed to find an item.

Folders also remove the need to use long prefixes to make names unique. For example, you can have a skin in one folder and another skin with the same name in a different folder. When the project is exported, the folder names are used to create a unique name for each object, like eyes/blue and clothes/blue.



Spine now has rulers to help with alignment and mesh creation. Click the ruler icon to activate the feature. In an upcoming release we will add guides and other improvements to the rulers.

Enhanced PSD export

You can now export your skeleton's pose as a Photoshop PSD with a layer for each attachment. This can be helpful when drawing a new version of an attachment for the middle of an animation, such as a different perspective or motion blur.

Welcome screen

welcome screen

When launching Spine you are now shown our brand new welcome screen! You can quickly access your favorite and recent projects, or explore the example projects that come with Spine. We have created walkthroughs for each example project explaining how they are rigged.

The tips section gives you a new tip every time you start Spine, so you can learn new rigging tricks and improve your skills. Click a tip to go to our tips webpage where you can see all the tips at once and share links with fellow Spine users.

The news section is where we post general Spine news and the changelog shows the latest details about Spine's development.

The little mail icon at the top of the Spine window will notify you if there are any new changelog or news items, so you can stay on top of what is going on in the Spine world.

New tree settings

The many Spine workflows have different needs for what you see in both the tree and the viewport. We have added some new settings to let you more easily focus on the task at hand.

Show all skin attachments

The Show all skin attachments setting displays all skins that have an attachment under each skin placeholder. This gives a great overview of your skins and makes operations like moving an attachment to a different skin much easier.

Retina support for OS X

Spine on OS X now makes better use of the pixel density of Retina displays. Rendering of fonts and images in the viewport is now done at high resolution. The Interface scale setting controls how the rest of the user interface is scaled. 200% is the default and recommended for Retina displays. 100% provides crisper graphics, but may be too small on high resolution screens. Values other than 100% or 200% will show scaling artifacts and are not recommended.

Minor improvements

As usual, we've added many minor improvements, such as selection history for the tree view. You can now go back to your previous selections by pressing PAGE DOWN and forward in the selection history by pressing PAGE UP. This makes it easy to jump back and forth between selected items, without needing to scroll in the tree.

highlighted deformed vertices

Spine now marks vertices that have been deformed with a different color, making it easy to tell which vertices have moved. Hold control and double click a vertex to select all the deformed or undeformed vertices. Also, in animate mode you can now Reset only the selected vertices.

motion vectors on region attachments

Previously ghosting only displayed motion vectors for mesh attachments, now it also shows them for region attachments.

multiple skin placeholders

You can now select multiple attachments and create skin placeholders for them all at once. This greatly speeds up creating and populating new skins.

Runtime improvements

Since the 3.7 release we have closed over 200 issues, including bug fixes and new features. Thanks to everybody reporting issues and suggesting changes to the runtimes! For a detailed overview of the changes, check out the Spine Runtimes changelog as well as the commit log for the 3.8 branch.

This release comes with a few breaking changes across all runtimes:

  • The file formats for both .json and .skel have changed significantly to support new features and reduce file sizes. To use the 3.8 runtimes, you need to export your files using Spine Editor version 3.8.20 and above!
  • We renamed Slot#getAttachmentVertices() to Slot#getDeform() to better communicate its intention.
  • We renamed Skin#addAttachment() to Skin#setAttachment().
  • We removed VertexAttachment#applyDeform() and replaced it with VertexAttachment#deformAttachment. The attachment set on this field is used to decide if a DeformTimeline should be applied to the attachment that is currently set on the slot to which the timeline is applied.
  • We removed the inheritDeform property from MeshAttachment.

All runtimes support all the new editor features, including polygonal texture packing, skin bones and constraints, as well as soft IK!

Reduced .json and .skel file sizes

While Spine's export formats are already quite space efficient, we have put in some extra effort to reduce their space footprint even further!

The JSON format parser now assumes more default values, that is, values that do not need to be explicitly written to the .json file. This reduces the file size, especially when there are a lot of timelines with many frames.

The binary format has been modified to store strings only once and share them across the file where possible, for example attachment names. This significantly reduces the file size when using attachment timelines with many key frames. In one case this improvement cuts a 3.5MB .skel file down to just 640KB!

Binary format loaders for spine-ts and spine-as3

Most of our runtimes have supported both the JSON and binary format for a long time. However, our web and ActionScript runtimes could only deal with the JSON format. Until now!

We have added binary format parsing to both spine-ts and spine-as3. Using the parsers is just as easy as using the JSON parsers. We've added examples for binary file loading to both spine-ts and spine-as3

Improved skin API

Many users of Spine create assets for mixing and matching, often for custom avatar creation. Our new skin bones and constraints feature makes this more powerful than ever. We've therefore improved our skin API to make creating custom skins at runtimes super easy.

A skin in our mix-and-match example represents a single item, like a shirt, pants, or eyes, and is composed of one or more attachments. When a user selects the items that should go on their character, all you need to do is combine those item skins into a single skin:

Skin mixAndMatchSkin = new Skin("custom-girl");

That's it! You can try this code out in the live code editor above.

The Skin#addSkin(Skin other) method takes the bones, constraints, and attachments of the other skin and adds them to this skin. Do this for all item skins a character should be composed of and you end up with a single skin you can set on a skeleton.

In addition to the Skin#addSkin(Skin other) method, we have also added the method Skin#copySkin(Skin other). This method will create deep copies of all the attachments, which lets you modify properties like texture coordinates without affecting the original attachment data.

To facilitate the deep copies, we've also added a copy() method to every attachment type, which will create a deep copy of the attachment. You can use this mechanism to selectively deep copy individual attachments. For mesh attachments, the MeshAttachment#newLinkedMesh() method can be used alternatively: it will created a linked mesh that's linked to either the original mesh, or to the parent of the original mesh.

Finally, we've added the Skin#getAttachments() method which lets you easily iterate over all attachments in a skin.

These API additions are available in all Spine runtimes! We have added mix-and-match examples to all the runtime example projects for you to play around with.

Engine specific improvements

We are of course also always hard at work improving engine specific areas of our runtimes!

For Unreal Engine, we've added quite a few quality of life improvements. You can now also integrate Spine skeletons in your Unreal Engine UI.

One notable new addition to spine-unity is support for Unity's SpriteMask and RectMask2D. We've also done some spring cleaning, removing some of the extension APIs in favor of our new Skin API.

For MonoGame/XNA, we've rewritten the example project to be easier to follow.

The Spine web player can now also display .skel files. Just set the SpinePlayerConfig#skelUrl instead of the SpinePlayerConfig#jsonUrl field!

Löve2D recently changed the way they handle RGBA colors. Starting with Löve2D 0.11, color components should be given in the range 0-1, while previously the range 0-255 was used. The spine-love2d runtime transparently deals with both range types. As before, colors specified on Spine objects use the range 0-1.

Have a look at the runtimes changelog for a full overview of engine specific changes!

Up next

The upcoming 3.9 release will focus on the secret project we have mentioned before. We can't wait to tell you more about it!

Thanks to everyone in our community who reported issues, tested the beta, and gave suggestions to help shape our latest feature additions. Your input is invaluable!

Happy animating! Your Spine Team

Discuss this post on the Spine forum.