sampsao

Hi, programmer here

We have a small problem regarding the export of frame sequence animation in our game. When we export these animations, the resulting texture atlases don't have any information about the original pivot that the artists have set in the Spine editor. I've tried to look for a solution from your forums and other sources, but seems like this has not been implemented in any way. I found these threads:
http://esotericsoftware.com/forum/Pivot-points-in-Frame-Atlas-9795
http://esotericsoftware.com/forum/Sprite-Sheet-Grid-Export-problem-10403
http://esotericsoftware.com/forum/Pivot-Problem-On-Export-Sequence-Anim-5585

Adding this kind of a transparent rectangle adds a lot of unnecessary space in to the atlas and bloats it. It also forces us to use other tools to get rid of said wasted space, and doesn't solve the actual problem of not having the pivot data in the resulting atlas data file. If we could get the pivot data to the atlas, we could write an automatic sprite animation creation tool to suit our purposes, but without it we need to do a lot of manual labour to get it working. So would it be possible to add this data to the export tool so we can take full advantage of your tool?
As a reference, this is an example how our exported atlas data looks like:

character-main.png
size: 2036,780
format: RGBA8888
filter: Linear,Linear
repeat: none
character-main-Attack_00
rotate: false
xy: 836, 194
size: 107, 140
orig: 177, 212
offset: 25, 1
index: -1
character-main-Attack_01
rotate: false
xy: 139, 247
size: 103, 167
orig: 177, 212
offset: 25, 1
index: -1
and I'd want it to also contain the pivot (x,y) of the original sprite, for example 836,194 and 139,247 respectively.
To me it seems like it should be fairly trivial to add the pivot data from the root/editor origin. Seeing that this has been requested multiple times over the years, is there some technical restrictions that prevent you from doing this or could this possibly be added in a near future update?

Thank you in advance!
sampsao
  • 記事: 3

Nate

There are a few kinds of "pivots" in Spine, though it is more accurate to call them "origins" because it's not just used for rotation but also scale (and shear for bones).

The obvious one is bones: when a bone is rotated, scaled, or sheared all descendants are affected and the bone's position is the origin.

Another kind of origin is for region attachments. When a region attachment is positioned or scaled, the origin is the center of the rectangular image. Spine doesn't require or allow a different origin to be specified because this would be tedious to set manually. Using the center of the image defines the origin without requiring needing to set it manually. Note the region attachment position is relative to the parent bone.

For mesh attachments, they don't have a single position, instead they are made up of a list of vertices (also relative to the parent bone). The values shown in the editor for the attachment's position are for convenience and are the mesh hull's centroid. Since the hull vertices can be manipulated via deform keys, vertex weights, or scale of ancestor bones, the centroid can vary as the mesh is manipulated. The origin for rotation and scale defaults to the centroid but can be anywhere: in Spine, hover over the little + until a circle appears around it, then you can drag the origin elsewhere.

If you want to attach an image of a different size in the same place, you'll need to define how you want to calculate the "same place".

If you have another image, possible of a different size, how will you know where to place it? You need to know some reference point on that image that matches up to something on your skeleton, such as a bone position or the origin (center) of an existing region attachment. If you want to define that position manually, then in Spine you can just create an attachment from the image and then position it where you like. However, that is a manual solution and unreasonable to attach hundreds or thousands of images. For that you want an automated solution, you do not want to manually define the reference point.

As you found mentioned elsewhere on this forum, one easy solution is to use images with extra whitespace. That way the center of the images is the same, giving you a reference point, and so you can use just replace the old image with the new one without any calculations. Note that the extra whitespace does not bloat the atlas at all when using whitespace stripping. That is a feature Spine's texture packing supports, so other tools are not required.

If you are exporting data from Photoshop, the JSON data contains the positions of the region attachments. Since each position is the image center, that data tells you exactly where to place the images. These positions in the JSON from Photoshop are in world coordinates (unless you use [bone] tags in Photoshop layer tags). You can convert them to bone local positions using Bone worldToLocal.

It's uncommon to need to position a mesh of a different size at the same position. This is because you likely create the new mesh in Spine, so you have already positioned it where you want. For meshes it is much more common to use the same mesh but replace the image it uses. Linked meshes are used to do that.
アバター
Nate

Nate
  • 記事: 9642

sampsao

Hi Nate and thank you for answering so quickly.
I was specifically asking about the frame animation export option you have in place, maybe that was a bit unclear. I'll post a few images if that helps to clarify the situation a bit more.

Screenshot 2020-03-03 at 14.39.22.png

The first image shows how we have our character set up, with the root bone selected. This root bone is always located at the editor origin and is also the origin for the character, we use it as the pivot for our skeleton animation characters. But for smaller characters like this one, we want to export it as PNG atlas to save CPU on our game.

Screenshot 2020-03-03 at 14.40.00.png

In the PNG export settings, I noticed that we can use "Maximum bounds" setting to have all the resulting images to have the same size. I assume this is the solution you have provided as an option after the feedback in the threads that I mentioned, and it works very well. I can use the whitespace stripping to pack the frames more tightly and still have the information of the original sizes in the atlas.

Screenshot 2020-03-03 at 14.41.01.png

The only problem is, that the root bone that the artists have setup in the editor is not recorded anywhere. I know that with the original size data I could easily set the origin in my use case at the center/corner of each frame, but I can not exactly rotate them or draw something at their feet, since I don't have the data where the feet are located. For this I'd want the exporter to record the root bone position in a frame, so I could easily set the frame origin at the feet of a character. Since it is already possible to make every frame the same size based on the maximum bounds, I'd assume it would also be possible to record the the origin position inside those bounds and save it to the atlas json?

With this data I could easily automate our whole asset flow and reduce the possibility of human error when we create new assets for our game. Hopefully this clarifies our situation a bit and you can point me to the right direction!
添付ファイルを見るにはパーミッションが必要です
sampsao
  • 記事: 3

Nate

Ah, no worries. Due to "automatic sprite animation creation tool" I thought you were wanting to attach images at runtime without having first attached them in Spine, so I went off into the weeds a bit.

For exporting frames, it's true we don't export where world 0,0 is in the resulting images. The best you can do is export as you've shown, then determine the offset manually. When you export all animations at once and they all have the (whitespace stripped) bounds, then the same offset will be used for all frames. This means at least you only need to do this manual process once after exporting. Unfortunately if you add new animations that change the maximum bounds, you'll need to determine the offset again.

I agree we should improve this. I've created an issue, you can subscribe to get notified when the status changes:
Provide world 0,0 offset for exported frames · #539 · EsotericSoftware/spine-editor

You can see all issues on our roadmap here:
Spine Roadmap
アバター
Nate

Nate
  • 記事: 9642

sampsao

Ok, I wasn't sure if I had just missed some setting or if there was something wrong with our setup regarding this :) I guess I'll have to deal with the manual offsetting for now and hope that you can get this feature done in the future.

Thank you Nate!

---

Hi,

It's been a few months, so any updates on this?
sampsao
  • 記事: 3

Nate

Sorry, there hasn't been progress on this yet. We've been bogged down with getting the 64-bit launcher and curve editor finished. :(
アバター
Nate

Nate
  • 記事: 9642


Return to Editor