Spine characters in and out

Bring a character made in Spine into Rive with its skeleton still a skeleton, or take a Rive character (a rig, a flipbook, plain vector art) out as a Spine skeleton for Unity, Godot, Unreal or the web. Both ways are checked against Spine's own runtime, which reads the result.

You bring
A Spine export: the skeleton (.json or .skel) with its .atlas and page pictures beside it, or the folder of images it was exported from, or all of it in one .zip. Or a .riv / .rev to take to Spine.
You get
A .riv with your skeleton, skins and animations (and from there any other format). Or a .zip with the skeleton .json, its .atlas and pages.
Needs
Nothing beyond the install. Drawing shapes for Spine needs Chrome or Edge.

Ask your assistant

  • Convert hero-pro.json from my Spine export folder to Rive.
  • Bring the goblin and goblin-girl skins in as two artboards.
  • Put the base body, the green dress and the red hat on together and convert that.
  • Export character.riv to Spine 4.2 for my Unity project.
  • Turn my flipbook explosion.riv into a Spine skeleton.

Spine to Rive

  1. Read with Spine's own runtime. convert_format reads each file with the Spine runtime of its version: 4.0 to 4.3, JSON or binary, and Spine 3.8 JSON. The atlas is found beside the skeleton (spineboy-pro.json finds spineboy.atlas).
  2. The skeleton stays a skeleton. Every Spine bone becomes a Rive bone with the same name. Slots keep Spine's draw order. Each attachment becomes a Rive image or mesh, and a weighted mesh stays bound to its bones. Clipping, image sequences, draw-order keys and events come along.
  3. Keys stay keys. A bone you keyed in Spine keeps its keys and its curves. A bone moved by IK, a transform or path constraint, or physics is played in Spine's runtime and written as keys, so Rive shows exactly what Spine shows.
  4. Skins become artboards. Each skin gets its own artboard, and the pictures are stored once. To combine skins (mix and match), say which ones to wear together. A state machine picks the animation with a number input called animation.
  5. On to anything else. From the .riv, the same conversion continues to .rev, Lottie, dotLottie, Spline (3D), Figma or a Rive CLI project.

Rive to Spine

  1. Bones from every part. Every group, shape, image and bone becomes a Spine bone, with Spine's origin at the artboard's bottom centre. Directly keyed parts keep their keys and curves. Parts moved by constraints or layouts are read frame by frame from Rive's runtime.
  2. Pictures. Images go into the atlas as they are. An image's mesh becomes a Spine mesh: bound to bones if it was bound in Rive, with vertex keys as deform keys. Shapes, text and nested artboards are drawn by Rive's own renderer and placed exactly where Rive draws them, on every frame when their colour or outline is keyed.
  3. Built the way a Spine artist would. Pictures that never show at the same time, like flipbook frames or an eye's open and closed pair, share one slot with attachment keys. A clip becomes a Spine clipping attachment.
  4. For any Spine runtime. The zip holds the skeleton .json (Spine 4.2 by default, which the 4.0, 4.1 and 4.2 runtimes read, or 4.3), its .atlas and page pictures. Spine's own runtime loads it as a check before you get it.

How close it is

Measured by drawing both sides at the same moments, half way between frames:

  • Spine to Rive: 99.8% or better on the Spine examples tested: spineboy, raptor, goblins, mix-and-match, dragon and two physics rigs, as 3.8, 4.0, 4.1, 4.2 and 4.3 files. They cover meshes, IK, path constraints, physics, skins and skin combinations, and a five-page atlas. The exception is additive glow layers blown up several times (spineboy's portal), at 93 to 99%, where the two renderers round the blending slightly differently.
  • Rive to Spine: exact on a vector rig, a keyed colour, a flipbook and a bending mesh. 99.9% on a Spine character that went to Rive and back.

Good to know

  • Rive has no colour tint on pictures. A slot whose colour is keyed gets a picture per colour it shows, switched each frame.
  • Spine has no state machines. Going to Spine, every animation is written and your game picks which one plays.
  • Constraints are written as their results. The motion is exact, but the Rive or Spine file plays keys rather than a live IK chain.
  • Spine bounding boxes and path attachments have no Rive drawing and are left out. The constraints that used them are kept, as keys.
  • A Spine 3.8 binary (.skel) isn't read. Export 3.8 as JSON, or re-export from Spine 4.

Related