Can you send a project so we can see the problem firsthand? Does this only happen when using pixel grid scaling?

Yep! Thanks! You might find a version of your project with the problem by looking in the Spine backup folder (a button in the settings dialog will open the folder for you). Of course if you resized your images that only helps with part of it.

Great, thanks! I'm not back in full force yet, but I found a moment to take a closer look. It appears everything is actually working properly, as unintuitive as that may seem!

A region attachment's position is the center of the texture region. Eg, at 0,0 the image is centered on the bone. If the region size is odd, this places it half a pixel off. To get the pixel grid scaling effect, we render the skeleton to an FBO at 1:1, then draw the FBO. When rendering to the FBO, if the region is half a pixel off compared to the FBO pixels, the nearest filtering can cause pixels to be lost.

The solution is to move the attachment half a unit when it has an odd dimension. Eg, instead of offsetting it 9 pixels on X, if the width is odd, offset it 9.5 or 8.5. This allows the region pixels to match the FBO pixels 1:1 and no pixels will be lost.

Note the same problem can occur when the attachment dimensions are even and the attachment translation is off by half a pixel.

It's a bit of a tricky gotcha. Maybe we could automatically nudge attachments so their pixels match up 1:1 and filtering won't kick in, though that kind of magic can also be very confusing, depending what you are doing.

FWIW, with a region attachment selected and Parent axes chosen, in setup mode the translation shown is the center of the region attachment position relative to the bone. World axes can tell you where it is relative to screen pixels (assuming 1:1 mapping of world units to screen pixels). Remember, because the region attachment position is the center of the region image, you'll want even dimension region attachments on x.0 world coordinates and odd dimension region attachments on x.5 world coordinates.

The Photoshop script places the region attachment in the right place. Eg, if the width is odd, it is placed at x.5. We could add a setting to the Photoshop script so output images have even dimensions, but if using the script it should already be handling it for you by adjusting odd dimension positions by 0.5.

I had the same issue some time ago when creating this animation (the logo finishes on the left on purpose :p):

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

I agree it's a little tricky. Ideally you use the Photoshop script, your regions are placed at x.0 or x.5 automatically, and then you just have to be careful when translating bones that you end on integer coordinates. Have you found something in this workflow that causes unnecessary pain? If placing the images yourself there is a little more pain because you need to nudge region attachments with odd dimensions by 0.5.

We've wanted a "region sequence" attachment since the first version of Spine (and still want it!). This would show a number of regions at a given framerate so you don't have to key each image change.

It's not clear why you'd need a dummy bone/slot for those actions?

Maybe we could nudge the odd dimensioned images by 0.5 when you add them. We could do this only when pixel grid scaling is enabled, though I wonder if it would make sense to always do it? It's easier to zero the translation of all the images than it is to find the odd dimensions and nudge them 0.5.

Ah, I've increase the attachment limit. http://imgur.com/ or similar might be a better way to show many pics.

AxiomVerge wrote

This is because they are centering themselves on the parent bone, rather than on the current position of the slot.

I understand, though technically a slot doesn't have a position, only bones and attachments have positions.

AxiomVerge wrote

I name it "zdummy" so that it sorts to the bottom of the hierarchy, making it less of a distance to drag the frames in.

Note you can click Set Parent or press P rather than dragging.

I understand your dummy bone now, thanks. I guess most of the frustration is that since a slot can only have one attachment visible, it's hard to manipulate multiple attachments under the same slot. The dummy bone is a pretty OK workaround. You could put it in a separate skeleton so it is sure not to show up in your exports.

Another way to do it is bring all the attachments in as a grid, position them, parent them to the right slot, the delete all the empty slots. There are a couple better ways though. Using copy and paste:

1) Drop all your attachments on the same slot.
2) Select an attachment that is where you want the others to be.
3) Press ctrl+c (cmd+c on Mac) to copy its transform.
4) Select the other attachments in the tree and press ctrl+v (cmd+v on Mac) to apply the copied transform. This modifies the selected attachments, even though they are not visible.

When dragging an image file (from the Images node) on top of another image file, it will replace it. However, when dragging an attachment on top of another attachment, it will copy the transform. Knowing that, the second way is:

1) Drop all your attachments on the same slot.
2) Select the attachments you want to position.
3) Drag and drop them on an attachment that is in the position you want. This modifies the selected attachments, even though they are not visible.

Sorry this wasn't more intuitive!

You may still have an issue if your attachments are not all even or odd dimensioned, since even should be at x.0 and odd at 0.5 and the above will put all attachments at the same coordinates.

Copy/paste is more magick than I like. It's context sensitive, it isn't discoverable, and it isn't super clear what it will do, or if it will do anything at all. Still, it's an easy way to add this sort of functionality and it's not completely foreign to users.

You can also copy/paste bone transforms. It remembers the hierarchy, so you can select different bones with the same hierarchy and apply the transforms. Also which axes are selected matters, which can be useful.

Probably the place where copy/paste is the most intuitive is in the dopesheet (for keys). However, even there you need to have last clicked in the dopesheet so it knows that is where you want to paste (rather than in the viewport).