Do you strip whitespace? This can't be done when using meshes. Sorry it's a gotcha, I should really add a warning for this!
https://trello.com/c/8hdXgHcQ/131-warni ... ith-meshes

Yeah. I don't think this is a whitespace problem.
If it were, we'd have incorrect UV mapping and parts being cropped around the edges of the mesh, which isn't what's happening here.
Looks more like RegionAttachments are being scaled differently vs MeshAttachments (or SkinnedMeshAttachments).

(But yes, I think the warning is a good call for UX).

This incongruous scaling happened to me before and it was HILARIOUS. But re-exporting the json seemed to fix it. I couldn't really understand why. But it happened right when Skinning was introduced to the runtimes.
Did you try re-exporting the .json? Or is this a brand new export?

If that's not the problem, let's try investigating further:
Are you using the Scale field on the SkeletonData asset?
Are you scaling the root bone?

(Awesome art, by the way. Does your artist have a tumblr or deviantART account?)

EDIT:
Oh. hmm.. it does look like some cropping is happening on the sides. But that doesn't seem to add up with what's happening.
Can you share your json? (without the images)

wingstudio wrote

What do you mean with stripping whitespace? Could you explain more on the topic so that I can solve the issue?

I mean to uncheck these:

Image removed due to the lack of support for HTTPS. | Show Anyway

Pharan wrote

I wonder if it's easy or a good idea to add a per-attachment whitespace stripping feature that modifies your source images + applies transform compensation in the editor instead of modifying what comes out in the atlas on export :p

I would say either strip whitespace yourself before bringing it into Spine (easy), or the texture packer could use the mesh information to strip pixels that are outside of the mesh and adjust the UVs (complicated).

It does seem pretty strange and possibly more than just a whitespace stripping problem. Are you sure both your Spine and runtimes are using the latest?

Please post the .spine file.

I understand that the ideal is to prepare them, pre-trimmed and optimally rotated, outside of Spine before bringing them in and setting up and stuff like that.

But this honest mistake seems to happen a lot;
people not knowing about the consequences of having giant images with lots of space in the editor.
I've seen it before and it slows down the editor quite a bit if there are enough of them— I assume because of fillrate.
It also affects the feature of being able to click on images to select their parent bones in animate mode. (Unity uses alpha-based hit detection for selecting their sprites in 2D mode. Does Spine do this? I wonder how slow that is)
Some people proceed to animate a lot of stuff only to realize it's better to pre-trim the images.
What options do they have at this point?

I'm not really requesting for it. I certainly wouldn't benefit from it. :p
Maybe Spine should be able to detect the abundance of whitespace on the source images and warn the user accordingly instead?

Anyway, on the problem at hand :
I think the problem is in the exported data.
I'm seeing generally similar results when using the assets in Unity, but unlike the video, I don't see the mesh UV mapping chopping off the torso+arms image on the sides. From this, I think the whitespace stripping isn't the problem at all.

You should send Nate the .spine file.

Yep, seems to be a problem in the data, need the .spine file.

For hit detection Spine uses the center of the image as if it were whitespace trimmed. This is likely better than what Unity is doing, as images are easier to select because whitespace counts, but there still isn't a problem with images with lots of whitespace on top of each other. Could be better if it was the center of gravity, but probably not by much.

It's true it can cause problems for new users. We'll do something about it at some point!

I think the reason Unity used alpha-based is because things often get piled on top of one another (guess they chose to lean on selectivity over sensitivity). If, for example, you have a triangle image over a circle image of roughly the same enclosing box size, you'll have trouble selecting the one underneath. I remember selecting with untrimmed images was really impossible to work with before, I guess it was fixed. Thanks!

Good point. I was hoping the folder could be clearer in the script too.

Right now, if your psd is saved, it should save the images and json in the same folder as the psd, but in a subfolder called "images".
I'm not sure what happens if your image isn't saved.

Really? It didn't come out? Maybe you have two copies of the psd?

Also try to unlock all the layers and have no folders when you're doing this. Sometimes, even minutely complicated layer setups causes the script to fail without error messages and thus not save anything.

I've actually never tried the LayersToPNG script on mac, I wonder if there is a problem there. Don't see why it shouldn't work though it's fairly simple js. I recommend taking your entire PSD and if you have things like adjustment layers etc. make sure they are "baked" in. You can do this in a duplicated PSD or make a new group you copy everything to. That is how I do it.

Zip file is zero bytes.

For what it's worth ... I had an issue that looks very similar to this, but I was stuck on an old version of the editor. I updated it to the latest and my issue is solved.

The latest is 1.8.35. You are 35 releases behind! In the Spine Settings, change the update to "Latest" and restart Spine.