2D and 3D physics for spine-unity

December 2nd, 2019

Hinge Chain Demo

We are happy to announce improved support for HingeJoint and HingeJoint2D chains in our spine-unity runtime! This makes it easy to add realistic cape physics to your character, have it drag heavy objects around, swing a morning star, or much more.

HingeJoint and HingeJoint2D components are used to connect a Rigidbody or Rigidbody2D to one another, constraining them to move like they are connected by a hinge. It is perfect for doors, but can also be used to model chains, pendulums, and similar objects. When set up correctly, Unity's physics will apply momentum and collision response to all the chain elements. An important requirement is that chain elements must be laid out flat on the same hierarchy level, instead of forming a parent-child hierarchy.

Previous functionality

You might note that this functionality existed in previous spine-unity versions. You may have given it a try, but likely were unhappy with the result, no matter how you tweaked the Rigidbody parameters. The reason was that gravity was being applied, but it was not able to capture movement of the skeleton or parent bones, thus lacking momentum. Starting in the spine-unity 3.8, the physics rigging respects momentum and works correctly when flipping the skeleton.

Creating hinge chains

2D and 3D hinge chains are created from an existing SkeletonUtilityBone hierarchy.

Hinge Chain Setup

Select the first SkeletonUtilityBone chain element and in the Inspector choose Create 3D Hinge Chain or Create 2D Hinge Chain to generate the physics rig. The selected element and all its SkeletonUtilityBone children are turned into a hinge chain. Adjust the Rigidbody drag and mass parameters to tweak the result to your liking. Raising the drag value will make the Rigidbody move slower and create the effect of being heavy or interacting with air.

Note that the chain root node is no longer parented to bones of the skeleton, but placed at the top hierarchy level of the scene. This is a requirement in Unity to have momentum applied properly. Do not reparent the chain root to bones of your skeleton, or chain elements will no longer be affected by skeleton movement!

2D hinge chains

  1. Create your SkeletonUtilityBone hierarchy as usual.
  2. Select the first chain element in the Scene panel and in the Inspector choose Create 2D Hinge Chain to create the 2D hinge chain rig. Create Hinge Chain 2D
  3. This will remove the GameObject chain from the previous parent (cape-root in the example) and place a new HingeChain Parent GameObject at the top level of the scene. As mentioned above, do not reparent this GameObject to the skeleton! Hinge Chain 2D Hierarchy
  4. Adjust the chain element Rigidbody drag and mass parameters to tweak the result to your liking.

Note that this GameObject contains two child objects, named Hinge Chain and Hinge Chain FlippedX. When the skeleton is flipped, these GameObject instances will automatically be activated and deactivated to enable the respective hinge chain.

3D hinge chains

  1. Create your SkeletonUtilityBone hierarchy as usual.
  2. Select the first chain element in the Scene panel and in the Inspector choose Create 3D Hinge Chain to create the 3D hinge chain rig. Create Hinge Chain 3D
  3. This will remove the GameObject chain from the previous parent (cape-root in the example) and place a new HingeChain Parent GameObject at the top level of the scene. As mentioned above, do not reparent this GameObject to the skeleton! Hinge Chain 3D Hierarchy
  4. Adjust the chain element Rigidbody drag and mass parameters to tweak the result to your liking.

When the skeleton is flipped, the HingeChain Parent GameObject will automatically be rotated by 180 degrees to adjust the hinge chain to the flipped bone locations.

These additions to our spine-unity runtime make it easy for physics to affect your skeletons for more dynamic behavior. Don't hesitate to share your thoughts and creations on the Spine forum!

Holding a two-handed weapon

November 22nd, 2019

final result

Ever wondered how to create a setup in Spine that would allow your character to hold a weapon, but also throw it away if needed? Wonder no more! In this blog post we'll explain step-by-step how to do exactly that, expanding on one of our tips.

Spine Professional is required to follow this tutorial as we will use IK constraints and transform constraints to achieve our goals.

Skeleton setup

initial skeleton setup

We start out with a basic body rig and create a bone representing our weapon. We'll omit image and mesh attachments in this tutorial so we can more easily focus on the skeleton structure.

For the weapon bone to be able to move freely, it must not be a descendant of the body bone. A good place to parent it to is the root bone of our skeleton.

The above image illustrates this initial setup. The weapon is represented by the green bone called weapon, while the rest of the body follows a pretty standard humanoid bone hierarchy setup.

In addition to the weapon and body bones, we also created 2 bones called hand-on-weapon-l and hand-on-weapon-r. These will become IK constraints targets that help us to keep the hands of the body rig on the weapon.

Constraints setup

Once all the bones are in place, and with the weapon and the body being separate within the bone hierarchy, we can connect the two via constraints.

Creating the IK constraints

ik setup

First, we want to make the arms follow the left and right hand attachment points on the weapon. We start with the left arm by selecting the two arm bones arm-l-up and arm-l-down and creating an IK constraint with hand-on-weapon-l as the target. We repeat this process for the right arm.

The two arms will immediately try to point to their respective target bones. We want to disable this behavior in setup mode so we can more easily animate poses and movements without the weapon. For each of the two IK constraints, change the Mix from 100 to 0. This way the arm will use its original pose instead, allowing us to animate it as we please.

Creating the transform constraints

transform setup

As a final touch we want to ensure that the hands will match the weapon rotation, so they look as if they are actually holding the weapon instead of following their respective parent's rotation. We can achieve this by selecting hand-l and creating a new transform constraint with the bone weapon as the target. The same needs to be done for the other hand bone. To make things look right, we set the offset rotation to 90. We keep all the mixes at 0, so the hands don't rotate with the weapon in setup mode, again making it easier to animate weaponless movements and poses.

Creating animations following the weapon

When creating an animation where the arms and hands should follow the weapon, we simply key the mixes of the IK and transform constraints to a value of 100. Voila, the hands and arms will follow the weapon!

ik animate

transform animate

If everything went well, your final setup in animate mode could look like this:

final skeleton setup


It is possible to constrain both hands to the weapon using a single transform constraint. In general, fewer constraints is better because it makes the rig simpler. However, this may be an inconvenience if the character needs to detach only one hand from the weapon.

The character could use IK constraints on the arms when not holding a weapon. In that case, the mix for those IK constraints can be set to 0 when the mixes for the constraints to hold the weapon are set to 100.


final result

The character can hold the weapon with one or both hands, throw away the weapon, do tricks with it, and so on. Since it can be turned on or off, multiple similar setups can be used for different weapon types, such as a pistol, shotgun, machine gun, spear, etc. The constraint mixes can be set in animations or by code at runtime.

You can download an example of this setup here.

We hope you'll find this little setup useful for your projects! Feel free to discuss this post on the forum.

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.