• Editor
  • Using Existing Spritesheet/Atlas with Spine

I've seen a few answers about this but they were highly specific and I haven't seen any definitive answers for this.

We recently implemented Spine into the FlatRedBall game engine, which primarily focused on frame-based animation before. It's a common practice in our engine (and many others I think) for the artist to hand edit a spritesheet (aka Atlas) since they are usually working on tilemap tiles, characters, weapons, and other art in one place. We have an Animation Editor that allows you to map animation frames on a spritesheet, and a Texture Mapper that maps textures on a spritesheet. Many games released on our engine have a single 4k texture with all game art on the texture (across multiple tools like Tiled, the engine itself, and UI tools).

It was important to us to support existing workflows while also adding Spine. But I can't find an easy way for Spine to support existing atlases. Here's the process I found:

  1. We built the ability for our animation editor to save out a Spine atlas format, so the game might produce spritesheet.atlas, allowing the artist to map textures during their normal process.
  2. Unpack the Spine atlas into a Spine project, which extracts a bunch of sprites into a folder the way Spine expects to work.
  3. Do skeleton animations and such using the individual images extracted.
  4. When ready to export, export the skeleton and repack the texture atlas. This will result in a new atlas with textures in totally different places using Spine's packing algorithm.
  5. Destroy the repacked atlas and just make sure the skeleton file has the same reference names and relative location to the pre-existing atlas.

The main problem with this process is that it can be fragile. You don't want to accidentally destroy your original atlas with the exported one. You also have to really understand how Atlas files and Spine work to properly get this set up in the engine. You also must carefully preserve paths and naming conventions or textures will break in the exported skeleton.

It would be awesome if Spine supported existing Atlases more natively. The functionality is all there. Extracting as individual images temporarily is fine. The only missing feature would be registering your existing Atlas with Spine and an option to auto-unpack that atlas on file change and to not overwrite it when exporting. I imagine this as a checkbox when unpacking to "preserve this atlas on export" and then Spine references assets as if they were packed but doesn't overwrite the existing texture or atlas file.

Does this make sense or is there a better way to do this that I don't know about?

    Related Discussions
    ...

    Here's an example pre-existing atlas. I work on tiles, characters, decor, and other things within a single Photoshop file. I may do specific things in other programs such as Aseprite but ultimately I bring everything into a single large spritesheet for ingestion into the engine and textures for everything in the game are mapped to that spritesheet.

    profexorgeek It was important to us to support existing workflows while also adding Spine. But I can't find an easy way for Spine to support existing atlases.

    I'm not sure I understand all of your requirements in the description above, but you can write your own
    AttachmentLoader and can then pass your custom AttachmentLoader to constructors of SkeletonJson() or SkeletonBinary(). This way you can import from any atlas format that you want instead of being limited to the Spine (libgdx) atlas format.

    The atlas file format is fine, we don't need to import a different type of atlas.

    The TLDR on the requirements is that we need to work at design time with sprites that are already texture atlased, not individual sprites. It's not easy to do this in Spine. You have to have some really clear patterns and workarounds to do this without destroying content data.

    It would be nice if Spine supported working with sprites that are already atlased, versus expecting to always work with individual sprites and pack them with its own algorithm.

    @profexorgeek Thanks for the clarification and sorry for the misunderstanding. I'm afraid there is currently no better way available than to slice up an existing atlas into single attachment images for use in Spine, be it via Spine's Texture Unpacker or by external tools like Photoshop's slicing feature or custom scripts.

    @profexorgeek The easiest solution currently would be to not export any atlas from the Spine Editor while exporting the skeleton. Then you just need to ensure that the runtime AttachmentLoader reads attachments from your existing atlas in whatever format provided.