Pivot data for exported frame sequence

Nate · 3 мар 2020

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

Ssampsao · 20 мая 2020

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?

Nate · 20 мая 2020

Sorry, there hasn't been progress on this yet. We've been bogged down with getting the 64-bit launcher and curve editor finished.

Ttonydongyiqi · 1 сен 2020

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.

Any progress on exporting pivot in sequence animation png atlas export?
I'm using Unity to play the exported sequence but the pivot in a animation could not be determined. There an offset between different animation.
Looking forward the furthur information about the pivot export in atlas export.
Thanks a lot~

Ssampsao · 10 дек 2020

Hi,

It's been 6 months now, any news if this is going to get implemented at some point? Looks like it would help other developers also

Nate · 11 дек 2020

Sorry it's taking so long. We are finally wrapping up v4.0 but we might be able to fit this in.

I wonder if adding fields to the atlas is the best way to go. The origin for all the images from the same animation is the same value and adding entries to the atlas limits the kind of values we can write. For example, it could be useful to write the position of a few bones per frame. This could be used for particle effects, spawning projectiles, etc. Lastly, changing the atlas file format may surprise some parsers.

We could write a separate file containing the origin for each animation. Maybe during export you can choose which bones you care about and it writes the positions of those bones for every frame in every animation. It could also write the rotation.

Any other ideas?

Ssampsao · 16 дек 2020

Hi Nate,

Sorry for late reply, seems like I didn't receive any notification from your response.

So just to clarify, I'm still talking about the frame animation export, where the resulting atlas and .png files have no data related to the bones anymore. The atlas only holds the frame data for the animations. Since nothing requires you to have every frame to be the same size, I think it would be necessary to have that pivot data as "per frame" data since otherwise people can use it wrong Also to note here, I think the using of "maximum bounds" when you export all animations to one sheet would require only one pivot point data, as you could tie it to the size of the original frame size, which is the same for all of the frames (example data in my first post).

I think I've failed to mention that we use Unity also and you are right, adding data to the atlas might break some parsers. I would honestly just be happy to get those pivot datas out in another file I could then read that data from the file when your Unity import scripts do their things and then combine them together to have all the animations with proper pivots, without the need to manually set those for every frame.

Hope I'm making sense, let me know if I can clarify this further Btw, are you using your own texture packer or a third party solution?

Best,

Sampsa

Nate · 18 дек 2020

We've been working on this! We decided to store extra data in the atlas file itself. Since Spine's atlas format is based on libgdx which is FOSS, we have gone through the process to make the changes there. You can follow along here:
https://github.com/libgdx/libgdx/pull/6316

After that is merged (likely tomorrow) we'll add support to Spine. We may not add support to output bone locations in 4.0, but likely will write the origin for each frame of image exports.

Using "maximal bounds" means you can't export just a single animation, you have to export them all and that could be time consuming. Storing the origin per frame is redundant but still pretty OK.

sampsao написал
Btw, are you using your own texture packer or a third party solution?

Spine's texture packer is based on the FOSS one in libgdx (of which I am the author). We've forked it though to add features like polygon packing.

Ssampsao · 18 дек 2020

Alright, this is great news! That is probably the best way to go. For our use case, we really want to use the maximum bounds to export all the animations to one file because that allows us (with this new data) to recreate the frame animations straight from the data you provide. Currently if we have wanted to put these animations to one atlas, for better performance, we have had to use Unity's own tools which aren't that great to be honest... So very glad you decided to do this

Nate написал
After that is merged (likely tomorrow) we'll add support to Spine

So can we expect this in some minor release during Q1?

Nate · 21 дек 2020

Ah, I guess you do need to export everything at once so the atlas data will contain all the origin information. You could export all animations to a folder and re-export individual animations there, then run the texture packer separately to have a single atlas, but it wouldn't contain origin information. Hmm, you could export and pack animations individually, then concatenate the atlas files to make a single atlas that has all the origin information.

It should make it into one of the next few beta releases.

The new feature is in 4.0.46-beta, available now!

An example has been added to spine-libgdx. When exporting an image sequence and packing, the world origin is written to the atlas file for each frame:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0-beta/spine-libgdx/spine-libgdx-tests/assets/spineboy/frame-by-frame.atlas
That is the new atlas format with "pretty print" turned off. Unrecognized values, like origin, in the atlas file are available at runtime. This is how you get the origin for a region and adjust the drawing position:
https://github.com/EsotericSoftware/spine-runtimes/blob/4.0-beta/spine-libgdx/spine-libgdx-tests/src/com/esotericsoftware/spine/FrameByFrameTest.java#L78-L81
The origin is the amount to add to the lower left corner of the region to get the position of the world 0,0 position in the Spine editor. That code makes the drawing position (x and y in the code) correspond to the world 0,0 position, which is the same way skeletons are positioned when using the Spine Runtimes.

Note you will need to read the new texture atlas file format. Currently the only Spine Runtimes that can do that are spine-libgdx, spine-csharp, spine-unity, and spine-xna. The other runtimes will be updated with support for the new format soon.

Ssampsao · 4 янв 2021

Hi Nate,

Thanks for the quick implementation! I just wonder if I did something wrong when I tried this out: having the same kind of setup as in the original screenshots, it seemed like the origin information didn't get written for every frame, like few animations lost the information. This shouldn't be a problem in my use case though as I should be able to work around it since I use the maximum bounds option. Implementing everything in our workflow will take some time from me so I can not yet comment on how everything works in a real life situation.

I did try to make a new clean Unity project with the latest Unity runtime and Spine examples. I then added the the test data you provided above to try out how it looks, but I failed to get the automated sprite slicing working. I setup the texture import settings to be multiple sprites but when I clicked the "Apply Regions as Texture Sprite Slices" - button, it only sliced one sprite out of the data. I just wonder if I downloaded the wrong runtime, but that was the most recent beta release that I could find from your website and Git. Would love to get this kind of an isolated test working before I move on to implementing it into our project

And the data seems quite different from the old version we have used (3.X, legacy data format) previously. Am I correct assuming that the new data is presented in this way:
bounds - x and y positions, height and width of the frame in the resulting atlas
offsets - x and y offset in pixels compared to the original frame, original width and original height of the frame
origin - the origin of the frame in relation to the original size

Nate · 4 янв 2021

Yep, that's how the new data looks.

sampsao написал
it seemed like the origin information didn't get written for every frame

Can you please post your atlas file? There should be an origin entry for every region in the atlas.

Re: Unity, the latest in the 4.0-beta branch should be able to parse the new format. I don't believe it does anything with the origin data though.

Ssampsao · 8 янв 2021

Hi Nate,

I'll attach an example atlas test data from my export. As you can see, some frames have no origin data and some do. For my use case where I use the "maximum bounds" - setting, this is no problem as I can use the same origin for every single frame. Just wondered if this might cause trouble for people using different setup, where every frame would have a varying size.

Thanks for clarifying the version, I'll get the files straight from Git to make sure I have the latest ones and try them out!

Adding a small update: so with my own data, the importing and applying the regions as texture sprite slices everything seemed to work just fine. I noticed that your example data used indexing for the frames. I made another test with my own data where I also used the indexes and seems like your Unity importer/tool doesn't know how to apply the texture regions when the indexes are used. Not sure if this is only a problem in the beta, but just so you know.

That said, the feature seems to be already good enough for my use case at least, so again, thank you for the quick implementation! I'll now look into making sure that the origin data works properly and report back if I encounter any problems with it. At a glance it looks to be correct though

Something more I discovered. Tried reading the new data and first failed miserably. I then noticed I had the texture packer setting to scale the resulting atlas at 0.5. I guess this option should mostly be used if you want to export different quality versions of your assets (hs/sd). However, the new origin data does not respect this setting but rather saves the origin data always using the 1.0 scale. For the smaller scaled one, this makes it impossible to use the origin properly as other data is affected by the scale. And now I specifically mean the scaling variant setting in the texture packing settings, the general scale in the general png export setting seems to work properly with the origin data.

The general scaling should be more than enough for my use case though, but maybe this is something you want to fix before rolling it out in a final release