PSD to Spine: how Riggy reads your layered file

What is read from the PSD

• Layers and groups. Every visible layer becomes a slot with its own image, in the draw order of the file. Hidden layers are skipped and named in the import report.
• Layer masks, not only alpha. The shape of a part comes from what you see in Photoshop: the layer mask (a vector mask too — Photoshop stores it rasterized), the masks of every parent group, and opacity are baked into the part. Art split into layers by an AI often has opaque pixels over the whole canvas and gets its shapes from masks alone; it reads correctly.
• Clipping groups. A clipped layer is cut by its base layer below, the way Photoshop draws it.
• Groups tagged [bone]. A group named with [bone] or [bone:name] becomes a bone. [slot:name], [path:name] and [ignore] work too — the tag convention of the official PhotoshopToSpine script, so a file marked up for it reads here as is.
• Images trimmed to their pixels. Each part is cut to the bounds of its visible pixels, and the layer position on the canvas becomes the attachment position.
• Downscaled to fit the atlas page. A file too large for one atlas page is not rejected: the whole rig is scaled down at once — images, positions and bones — with area averaging, so thin lines survive.

What does not carry over

Blend modes other than normal are taken as normal, adjustment layers have no pixels of their own and are skipped, and a feathered mask edge comes out sharper than in Photoshop. Every such case is listed in the import report the AI reads, so nothing disappears silently.

What you get

Plain Spine 4.2 data: skeleton.json, a .atlas file and its page .png, plus the part images and a readme, downloaded as one archive. Unity, Phaser, Pixi, Godot and any other engine with an official Spine 4.2 runtime play these files — nothing in them is specific to Riggy.

You see the rig live in the browser before exporting, in the official Spine runtime. See examples.

How it differs from the PhotoshopToSpine script

The official script runs inside Photoshop and exports images and a JSON file for the Spine editor, where the rigging and every animation are still done by hand. Riggy needs neither Photoshop nor the editor: the file is read on the server, bones are placed along the measured shape of each part, and the animations come from a sentence — “the cart shakes on the rails, the gold bounces”.

What you need to ship it

Riggy writes the data with code. The runtimes that play it are licensed by Esoteric Software, and whoever integrates an official Spine runtime into a game needs a Spine license. Spine runtime licensing explains what that means for the files you export.

FAQ

Do I need Photoshop or the Spine editor to convert a PSD to Spine?

No. Riggy reads the PSD file itself, without Photoshop, and writes Spine 4.2 data with code, without the Spine editor. You upload the file in the browser and describe the motion in a sentence.

How does Riggy decide the shape of each part?

From what you see in Photoshop, not only from the alpha channel: layer masks, vector masks, group masks, clipping groups and opacity are all baked into the part. Hidden layers are skipped.

Can I control which groups become bones?

Yes. A group named with the [bone] tag becomes a bone, the same tag convention as the official PhotoshopToSpine script, so a file marked up for that script reads here too. [ignore] skips a layer.

What files do I get?

A Spine 4.2 skeleton.json, a .atlas file and its page .png, plus the part images and a readme. Any engine with an official Spine 4.2 runtime plays them.

Do I need a Spine license to ship the exported animation?

The official Spine runtimes that play the files are licensed by Esoteric Software, and whoever integrates them into a game needs a Spine license. The licensing page explains what that means.