hip bone is the root of Spineboy's body bone hierarchy. Spineboy's legs use IK constraints which target bones on the same hierarchy level as the
hip bone. This is done so Spineboy can be moved independently from the IK target bones. Were we to use the
root bone as Spineboy's hip, we could not move the hip without moving the IK target bones. The below GIF illustrates this using a simplified setup.
To the left, the skeleton root bone is used as the hip. Moving that root bone also moves the IK targets. To the right, the hip bone is a separate bone and attached to the root bone. The IK targets are siblings. Moving the hip bone does not move the IK targets.
Spineboy's legs are driven by IK constraints, which is commonly used to keep a biped's feet firmly planted to the ground while the upper body moves. IK is also a great way to efficiently simulate the bending behavior of legs and ankles.
Spineboy's front and back legs are setup in the same way. For brevity, we will only discuss the front leg in detail.
The two-bone IK constraint
front-leg-ik controls the leg's
front-shin bones, while the single-bone IK constraint
front-foot-ik drives the
front-foot bone. Note that the order in which those two IK constraints are applied to the bones is important. We first apply the
front-leg-ik constraint and then the
front-foot-ik constraint. The order in which constraints are applied is defined by their position in the
Constraint node of the tree view.
Each IK constraint ensures that the constrained bones point at their respective target bones. The
front-leg-ik constraint targets the
front-leg-target bone, while the
front-foot-ik constraint targets the
To make the foot bend when the ball of the foot is rotated, the
front-leg-target bone is parented to the
front-foot-ik bone. When the
front-foot-ik bone is rotated, the
front-leg-ik is transformed as well.
At the tip of the foot, we have the
front-foot-tip bone. This bone is not affected by any IK constraints. We also disabled
Inherit Rotation on
front-foot-tip to ensure the foot doesn't go through the ground when rotating its parent bone.
Spineboy comes equipped with a hoverboard, as can be seen in the
hoverboard animation. To ensure Spineboy doesn't fall off his hoverboard, we use two transform constraints:
rear-foot-board-transform. For brevity, we'll only discuss the front foot transform constraint, as the rear foot constraint works in the same way.
front-foot-board-transform constraint constrains the
front-foot-target bone, which is responsible for transforming the front foot of Spineboy via an IK constraint. Since this transform constraint is applied after the IK constraint, it overrides the effects of the IK constraint to take control of the front foot. The front foot is placed on the hoverboard by setting appropriate values for the the transform constraint's
Translate offset using Match.
front-foot-board-transform constraint targets the
hoverboard-controller bone. The
hoverboard-controller bone is a child of the
root bone and is used to move the hoverboard around.
Mix values of the transform constraint are set to
0 in the setup pose. This means that by default, the transform constraint does not affect the bone it constrains, in this case
If we want Spineboy's front foot to be placed on and follow the hoverboard, we can key the
Mix for the
Translate component of the transform constraint to
100%. This is done at the beginning of the
hoverboard animation. Since the transform constraint is applied with a
100% mix after the IK constraint, the IK constraint's influence is completely overwritten by the transform constraint. For Spineboy, this means his front foot is firmly attached to the hoverboard for the remainder of the animation.
Using transform constraints like these simplifies animating Spineboy on the hoverboard. Only the the hoverboard needs to be animated, while the legs follow automatically in a natural way.
In this animation, the angle of the hoverboard is changed by moving the
board-ik-target bone at the tip of the hoverboard. It controls the
hoverboard-controller bone via the single bone IK constraint
Since the position of the hoverboard defines the position of the feet, we again need to ensure the order in which our constraints are applied is correct. First, we need to apply the
board-ik IK constraint, since it defines the hoverboard's transform. Only then can we apply the
front-foot-board-transform constraint, which places the foot on the board. The order in which constraints are applied can be defined in the
Constraints section of the tree view.
When Spineboy aims, he moves not only his arm holding the gun, but also his torso, head, and front arm. All of this is controlled by a single bone to ease the animation process. It also enables letting Spineboy aim at a point at runtime by programmatically moving the control bone. This is achieved by using another set of constraints.
Animate mode, with the
aim animation active, a bone named
crosshair appears in the editor viewport area. Spineboy aims at this bone, as seen below.
For this effect, we use a single bone IK constraint named
aim-torso-ik. This constraint drives the
aim-constraint-target bone, a tiny bone parented to the
This bone always points at the crosshair and gives us a direction for the three transform constraints
aim-front-arm-transform. These three constraints are applied after the
aim-torso-ik IK constraint.
Each of these transform constraints have different
Offset values. These control the initial position of all affected bones for the
Mix values define how much effect the constraint has when moving the
crosshair bone. For example, we can change the
0 to prevent any rotation of the torso.
We can also key the
Mix value to
42.3 to give a little rotation and a more natural feel to the aiming motion of Spineboy.
aim animation can be layered on top of other animations, for example, to enable Spineboy to aim and run at the same time. The
Preview view can be used to see the effect of layering multiple animations.
Setup mode, open the
Preview view, select
0, then select the
run animation. Next, select
1, then select the
aim animation. Lower tracks are applied first, so the
run animation is applied, then the
While the animation runs in the
Preview view, select the
crosshair bone in the editor viewport and move it around. The
Preview view shows Spineboy aiming at the moving crosshair while running.
The same can be done in games and applications by using the Spine Runtimes. The Spine Runtimes let you programmatically playback multiple animations on different tracks and manipulate bones, giving you the same control you have in the Spine editor.
portal animation uses non-uniform scaling and clipping to achieve a portal effect.
The portal is made up of a set of layered images, giving the portal depth.
portal-streaks2.png are all circular images, and not elliptical, like they appear in the animation above. If the images were elliptical, they could not be made to appear as if the portal is rotating while keeping their shape.
To achieve the elliptical rotation of the portal, we apply non-uniform scale to the
portal-root bone, squishing the portal on the X axis. We then apply rotation to the child bones
These flare images make up a traditional frame-by-frame animation with 3 frame. The frame-by-frame animation is achieved by keying the visibility of each attachment at the appropriate times in the animation, surrounding Spineboy with sparkly flares when he exits the portal.
Spineboy appears to come out of the portal, with the parts of him inside the portal being invisible. We achieve this by using a clipping attachment.
The clipping attachment's polygon defines the area within which Spineboy is visible. Any parts of Spineboy outside this area will be clipped and hence be invisible.
Which parts of the skeleton are affected by the clipping attachment is defined by the clipping attachment's position in the draw order, and its
End slot property. Any attachments for slots in the draw order between the clipping attachment slot and the
End slot will be clipped.
Animate mode, with the
portal animation being active, scrub through the timeline in the dopesheet to see the effect of the clipping attachment on Spineboy as he goes through the portal.