I know this is an old post but i wanted to say that you can solve this fairly easily on OSX by calling out to Applescript and running the Spine export command on the logged in user's desktop session in Terminal.app.

It's still not truly headless since your OSX box needs to be configured to automatically login to the desktop, and maybe be connected to a monitor, but for us that was already true. We just wanted to be able to run it via some automated fashion (like via a chat bot or CI build trigger).

tell application "Terminal"
    activate
    set shell to do script "$cmd" in window 1
end tell

@Mitch - it should be pretty easy to reproduce.

For us, it happens 100% of the time:

• have a unity project shared via source control (we're using git)
• artist adds new spine.json + all the assets
• artist commits into git (definitely committing the meta files)
• programmer pulls from git
• programmer opens project

Boom, you get the Atlas not found error and you have to click "Skip" on every one.

It also happens on a fresh checkout. You have to click "Skip" like a hundred times.

We're on Unity 5.1.1p4 / f1. With project settings -> editor -> asset serialization = force text.
Also, you need to have the "Library" folder git ignored so it doesn't commit.

Is there any way to use the same atlas with Spine & Unity2D?

Each of our "levels" is a single 2048x2048 spritesheet. Some of these sprites are used by Spine and some are just normal 2D sprites.

Right now we're creating dummy spine animations to just render a single static sprite but this is obviously not ideal. Plus, we need to start doing things like rendering the sprites as 9-sliced, tiled, etc - not possible with dummy spine animations.

So, ideally we can just build 1 atlas (either via Spine, a 3rd party tool, or inside of Unity) and have Spine & Unity both share it.

I see this is possible using tk2d, where you can build a tk2d atlas and have spine use it - but we're trying to avoid using tk2d for any new work (trying to transition to Unity2D).

What are our options here?

I have a similar problem - when we open up our project for the first time (after checking out from git), we get that "Atlas Not Found" prompt for all our spine animations. The atlas definitely exists and is in the same folder as the json animation. Doing "Select" and choosing the atlas doesn't work. You just have to skip every error. Then when Unity eventually starts up, it works fine. There's no problems with missing atlases.

So, I'm not sure what is going on. If I had to guess, it's some order of operations problem with how Unity or Spine-Unity is loading the json animation first before loading the atlas, so it doesn't know that the atlas exists.

Is there a way to create Binary export data from Json?

Like, I already have 100+ Json spine animations in my Unity project. Can I convert those to Binary format?
If not in Unity, maybe I can automate it via the Spine.app cmd-line?

That looks great!

Do you think there are any significant performance differences (memory or cpu) on mobile devices for the baked native unity animations vs animating via spine runtime?

Nate wrote

Just pack your images into a single atlas. See the texture packing docs.

Is there an example of this anywhere? I looked at the texture packing docs first (http://esotericsoftware.com/spine-textu ... er#Packing) but they don't really explain this part at all. That's why I'm asking here.

I have multiple spine project files with images in different folders (they don't share the same root folder, and not all the images in each project is used by the animation). I was hoping to be able to export each separately, then combine them. But, it doesn't seem like that's how it works.

From what I can tell, you need to have all your source images in the same root folder (with no unused images since it will not skip over them even if they aren't used in an animation). And then, all your exported animation .json files needs to use the same "skeleton"."images" root path as your source images root folder.

Can you confirm this, or am I missing something?

I figured it out. I made a tutorial video for our artists and it's uploading now to youtube. I'll post it when done.

Some of it is specific to our animation workflow but the spine bits are pretty generic. https://www.youtube.com/watch?v=o3lN4j6 ... e=youtu.be

Shiu wrote

Keep in mind that you can still combine the texture atlases from multiple skeletons. Even if you have multiple skeletons they can share the same texture atlas.

How do you combine the texture atlases from multiple skeletons?

Hi,

I'm a bit confused how to best export the art for what we want to do here. Hopefully I can get it figured out with this post.

We have a Unity game (Unity 4.5 with the Unity Spine runtime). Each "level" for the game will be a single atlas (4096x4096 at 4x, 2048x2048 at 2x, and 1024x1024 at 1x).

In this single atlas, some of our sprites are animated via spine and some are just static non-animated sprites. I wanted to use the new Unity 2d sprite renderer for the non-animated sprites, but that doesn't seem possible since the unity spine runtime uses mesh renderer, and it doesn't seem smart to mix mesh renderer and sprite renderer with the same texture.

So, it seems like the best thing for us to do is to just throw all our sprites into Spine, animated or not. Then maybe make a stripped down version of the SkeletonAnimation component for static sprites that wouldn't have any animation overhead.

Does that all sound good so far?

The part that I don't know how to do is how best to setup our spine projects / spine exports to support this type of workflow. I've read this page a couple times but it doesn't really answer my question. http://esotericsoftware.com/spine-texture-packer

If we have multiple spine animations + multiple static images we want bundled up into a single atlas, how would we do that? Should each spine animation be its own project, and then exported via "Create Atlas"? Then, run "Texture Packer" and select the folder that contains the static sprites + all the individual animations? Or do we actually have to make some dummy spine animations that use the static sprites?

I was messing around with the "Texture Packer" feature in Spine, but it seems pretty limited, if I understand it correctly. It's not ideal for someone trying to take multiple spine animations and put them into the same atlas.

This is how I understand the "Texture Packer" intended usage:

1) put all your raw source images in the same root folder (with no unused source images there, because it will include them no matter what)
2) export your spine anims without spritesheet, so you just get a json file, and put the json file in the same root folder from step 1, and make sure the image path in the json file works with your directory structure
3) run Texture Packer on this folder

I am understanding that right? It's not very convenient.

I can think of 2 ways this process would be much more convenient for packing multiple spine anims into a single atlas.

A) when exporting a single anim, be able to export the raw images (just copy them from the source folder), instead of packed into an atlas. then, the json and images would automatically be setup for Texture Packer.

or

B) Texture Packer could read from a collection of exported spine animation json files (the full path to the source images would need to be included in the json files, which it isnt right now). Then, it would be able to build a single atlas.

Perfect. Breaking batching here is not such a big deal for us. Thanks Pharan!