Particles for Spine

Spine has no particle system. Here is what people actually do about it.

The three routes

1. Image sequence on an attachment

Render the effect as a PNG sequence, bring the frames in as a sequence attachment, and play it back. Simple and predictable. The cost is that every frame is a full image, so the atlas grows quickly, and the effect can no longer be recoloured or retimed without re-rendering it.

2. Import it as a skeleton — JSON and atlas

Every particle becomes a bone and a slot, animated on the timeline, sharing one small atlas of sprite images. It stays editable in Spine — you can retime it, tint slots, parent it to a hand or a weapon, and mix it with your own animations. The cost is bone and slot count, so it suits shorter, sharper effects rather than a thousand-particle blizzard.

3. Spawn it in the engine at runtime

Put an event key in the Spine animation and let Unity, Godot or your own code fire its own particle system when it passes. Cheapest at runtime and infinitely tweakable, but the effect no longer lives with the animation — the animator cannot see it in Spine, and it has to be rebuilt for every engine you ship on.

Doing the JSON route with Ottomancer

Ottomancer is a free 2D particle editor that runs in a browser tab. It was built by an animator for exactly this problem, and its Spine export is the reason it exists.

1. Open the editor. No install, no account, nothing uploaded — your work stays on your machine.
2. Start from an effect or from scratch. There are 119 ready-made effects across nine categories; every one of them is an ordinary emitter after you apply it, so you can pull it apart and make it yours.
3. Bring your own art if you want. Import a PNG and use it as a sprite, or set a tile grid and play it back as a flipbook sheet.
4. Set the length and the loop. The timeline is a proper dope sheet with a frame ruler, a draggable loop region and a curve editor.
5. Export → Spine (json + atlas + png). You get a skeleton JSON, an atlas and its page image. Import that in Spine next to your own skeleton.

If you would rather have frames, the same project exports a PNG sequence — and MP4, WebM, animated GIF, animated WebP and SVG, for when the effect is going in a trailer or a store page instead of a game.

Working on your own skeleton, not beside it

The route above builds the effect on its own and hands you a second skeleton to place next to yours. There is another way round, and it is the one people usually want once they have a rig: bring your skeleton into Ottomancer, hang the emitters off its own bones, and export the whole thing back.

1. Import Spine — give it your skeleton JSON, its atlas and the page image. The bones and slots come in as a layer tree you can see and select.
2. Add an emitter under the bone you want it to follow. A torch bone, a sword tip, a wheel. It inherits that bone’s movement, so the sparks go where the hand goes without a single keyframe.
3. Export Spine again. Your original bones come back out with the effect baked in beside them.

Measured on a real 135-bone skeleton: it imports as 134 layers, an emitter parented to one of them emits correctly, and the bake returns 180 bones and 64 particle slots with the original skeleton intact. Two things to know — give the emitter a sprite before exporting, or it bakes to nothing to draw; and meshes, clipping and path attachments are not imported, so a rig that leans on those comes in incomplete and says so.

Honest limits

• Pick your Spine version in the export dialog: 3.8, 4.0, 4.1 or 4.2. Spine's own advice is to import skeleton data with the same version that wrote it, so the export writes the format your editor expects rather than one fixed format — the version string and the animation timelines both change with your choice. Set it to match your editor and import directly; there is no need to route a 4.x project through an older install. The version used is written into the report next to the files, so you never have to guess what a folder contains.
  Round-tripped through the real Spine software, automatically. The output is checked against the format on every build — bones, slots, skins and every animation key are verified to refer only to things that exist — and beyond that, exports are driven through Spine itself: imported, edited, exported again, and then loaded and animated with Esoteric’s own runtime. 78 effects have been through that chain. What has not happened is a person sitting in front of the Spine editor looking at one, so if you do, the feedback page is the single most useful place you could tell us what happened.
• The JSON export writes one bone and slot per particle, so a very dense effect makes a heavy skeleton. Keep counts sensible, or use the image sequence route for the big ones.
• It is a desktop tool. It works in a current browser on a computer, not on a phone.
• It is one person's free-time project, so there are rough edges. Bug reports are read on the feedback page and they are the most useful thing you can send.