Registration Point support for PNG exports?

edzillion

I am wondering whether it is possible or planned to have the ability to send out some kind of JSON data describing the registration point for each animation?

I am currently using PNG export (Sequence, All Animations, only Images ticked) and then using TexturePacker to stitch them together.

2 options here:

1. make all frames in a spritesheet the same size . pros - you only need one registration point for the whole sheet. cons - you have a huge amount of wasted space since all frames have to be the size of the biggest.

2. pack them close together. pros - smaller spritesheets, cons - you need registration points for each animation in the sheet (since the frame size of all frames in one animation are the same size).

at the moment there is no registration point info with the PNG export. I wonder if it would even be possible to infer it from the bones export (?)

In my case I am creating a spritesheet for a knight - one of his animations is an overhead sword attack, which is about three times the frame size as the others so it is really too wasteful to contemplate option #1 since we are in a web context.

thanks!

edzillion

So I notice that if I use the Spine texturepacker it exports spritesheets and atlas .txt files - these atlas files seem to contain some reference to the registration/origin point

walk0
  rotate: false
  xy: 0, 1
  size: 128, 153
  orig: 138, 164
  offset: 5, 1
  index: -1
walk1
  rotate: false
  xy: 128, 1
  size: 128, 153
  orig: 138, 164
  offset: 4, 2
  index: -1

orig would seem to be the origin/registration point and offset would be the offset of the sprite against the reg point. can anyone clarify this?

edzillion

ok I did an export without whitespace removed and the orig and size were the same, and the offset is always 0,0

standard strike0
  rotate: false
  xy: 0, 0
  size: 276, 245
  orig: 276, 245
  offset: 0, 0
  index: -1

so orig is the original size and offset is the clipping offset. no registration point there.

what are our options?

Søren

Afraid it's not a problem I can help you with, luckily Nate is back tomorrow so he will be able to respond here soon 🙂

edzillion

hey any word on this?

thanks

Nate

The offset in the atlas is for whitespace stripping. It won't help you position multiple animation image sequences on top of each other.

Until we allow setting a specific export size, you can use a large blank image to force all frames of all animations to be the same size. The texture packer will strip the whitespace. This way you can draw any frame from any animation at the same location (assuming you compensate for the stripped whitespace when drawing the frame image).

doda

Hi Nate,

Do you have any plans for providing metadata in any format along with sprite sheet exports?

Even using your above example I would have to manually locate the root bone for the export, along with grouping individual frames into their respective animations. The last bit is doable, as far as I can tell the root bone bit would have to be done manually for each sequence as Spine doesn't pass along the information.

Nate

If we can avoid another format, I think we should. When you use a transparent image large enough for all animations, the 0,0 point in Spine will be at the same position within each frame. 0,0 is the reference point that should be used at runtime for positioning, not the root bone. You can compute the location of 0,0 within your animation frames by knowing the size and location of the transparent image in Spine.

I'd like a feature that looks at all animations and pads all frames with whitespace so they the same size. This is the same as using a transparent image, but easier. It could tell you the 0,0 offset within the frame size. This is just an single x,y coordinate pair though, so I don't think we need a new file format.

doda

Okay, I'll use the origin instead of the root bone then.

Our current plan is to add a 1x1 transparent PNG to the animations and stick it at the bottom left of all the animations, and make sure that it's snapped to an actual pixel rather than on a fraction. This image will have a special name, lower_left_marker in my case, and I can parse the export .json looking for the x and y coordinate of the skin, from which I can compute the coordinate of the origin. I don't need a full background image as knowing the offset from a single corner is enough.

I've attached the transparent pixel if anybody wants it. Spine requires PNGs with an 8-bit depth where as most purely transparent PNGs will only be 1-bit.

wrt adding another file format, I don't think I agree with you. I can obviously see why you wouldn't want superfluous file formats, but in this case there's information that needs to be passed from Spine to something else. I can either hack together something like I'm doing at the moment or it can be passed in a cleaner data format. I think the hack is much worse.

I'm having trouble with the built-in atlas creation feature so I can't comment on it.

Antriel

Sorry for digging up so old post.
No one had problems with this? There is no way to find out origin point in mysterious .atlas file?
We started using Spine and my artist seems very happy.
I started writing parser for the .atlas format, for which I did not find any reference/documentation (unexpected, but I managed). I now understand offset is for whitespace stripping, but what is orig? Because it does not correspond to origin point, which indeed doesn't seem to be anywhere.

Is official solution really ugly hacking of adding a transparent point and parsing another file for some skin position? Not only it's not always applicable but it's a lot more complicated than just having proper origin point in the first place.
Or am I missing something?

Nate

The atlas format is from libgdx. orig is the original size, before any whitespace stripping.

Unfortunately there has not been a feature implemented yet for knowing the origin. Use a transparent image that is larger than all animation frames along with whitespace stripping. This way the offset is the same for every frame. There is no "parsing another file" needed.

Eg, use a 1024x768 image positioned at -512,-384. Assuming this is large enough that no animation frame goes outside of the transparent image, ALL exported images will have an origin at 512,384 after you take into account whitespace stripping. Obviously it may make more sense to position the transparent image differently rather than centering it at 0,0.