• Editor

  • Usable Spritesheet != Texture Atlas SOLVED

    inglês
Related Discussions
...

EDIT Thanks to the latest update, we can now make traditional spritesheets with Spine. See the screenshots Nate posted below for where to select "grid" as packing option. Thanks to Nate for the extremely prompt reply here and feature addition!

I've seen a couple posts here mentioning spritesheets here and not being able to use them as expected in various 2d engines. I think what isn't getting through is that a spritesheet != a texture atlas. Many simpler 2d engines that don't employ atlases or even GPU rendering expect a spritesheet laid out as in a grid without an associated data file describing the regions. Just a grid of frames of equal dimensions, laid out in order from left to right, top to bottom.

You can almost make Spine's texture packer behave in this way, by unchecking all the whitespace stripping options, but the resulting sheet is still laid out un-ordered. Well not completely un-ordered; I think the problem stems from Spine not putting leading 0's on its region/frame names, so when assembling the atlas and data it goes 0, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 21, etc. Simply adding the leading 0's might automagically create a usable spritesheet maker, at least on a per-animation basis. Tracking down where one animation stops and another begins would be trivial if they were numbered correctly.

My workflow previous to using Spriter was to export frames from TV-Paint, and then use ImageMagick to make my spritesheet. Even that solution won't work here, due to the leading 0's problem.

So this is a feature request to be able to force a fixed number of digits when exporting image sequences?
Or were you just restating?

If it will give us traditional sprite animators the ability to get the spritesheets we need, as I suspect it will, then yes, it's a feature request. I've just seen at least 3 other posts about the same problem, and the answers have all been about how texture atlases work, which is less than helpful when you just want to make a spritesheet.

Rybar escreveu

If it will give us traditional sprite animators the ability to get the spritesheets we need, as I suspect it will, then yes, it's a feature request. I've just seen at least 3 other posts about the same problem, and the answers have all been about how texture atlases work, which is less than helpful when you just want to make a spritesheet.

:yes:
You hit the nail on the head! Many people don't want to have to deal with json files or importing bones. We want the pure art. Just the sprite sheet itself. But the default way it is creating an atlas does not import nicely into tools such as Unity. Your explanation for how Spine is naming things is the same conclusion I have arrived at. I wish there was an option in Spine to pick how the atlas is ordered. We need a simple check mark option to make it create an atlas using the same order that the animation is keyed from left to right.

Came here looking for a solution to this problem. All I want is a spritesheet with each frame in the correct order so I don't have to bother rearranging it or something like that.

I agree, packing into a uniform grid is a basic feature Spine should support. I've implemented it in the next version. Choose "Grid" from the "Packing" select box:

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

FWIW, it wasn't as simple as ordering the images. Spine's packer is pretty sophisticated, using a mix of heuristics and brute force to solve an NP-hard problem. There's no guarantee that the images would be packed in order. Thankfully writing a packer that uses a uniform grid was pretty easy. 8)

This is fantastic news, thanks for the quick response Nate! How/when do we get our hands on the update with this feature added?

Awesome!! Hope this is exactly what we need to get things imported quicker! Just gonna keep our fingers crossed that it will play well with Unity now

Rybar, I'll probably do an update today. When Spine starts it will update to the latest unless you've chosen not to in Settings.

Updated Spine this morning and gave the new grid packing feature a shot. Works perfectly. Thank you so much Nate for your prompt response and update! Spine has already become my favorite animation tool, but your superb customer service has made it that much better.

Thanks! 8)

:yes: :yes: :yes: :yes: :yes: :yes:
Thank you so much for adding the grid export option!! It has fixed all the problems with importing into Unity without the use of json! 😃

8 meses depois

Hi friends, I'm trying to achieve this kind of spritesheet :

But so far without success, I have the last version of Spine Essential...what are the steps for exporting to a grid file 😉 thanks !

Cheers,

  1. Ctrl+E then select PNG.
  2. Check Create atlas
  3. Then click Settings
  4. Now set Packing to Grid
    Lastly make sure you have PNG export set to Sequence and you can now export.
2 anos depois

Is there a way to export all the animations with the same dimension? Right now the output I get is a nice grid spritesheet... for each animation. But different animations have different sizes. (e.g. the run is wider than idle) is there a setting that would do that?

Not yet. That's something that would be useful in the future tho.

Yeah.

The current workaround is to make a transparent box png, make sure none of the animation poses go beyond that transparent box, then export the frames with grid packing.

3 meses depois

I tried the transparent png and didn't get an even grid of squares from it. I attached the png to a bone, positioned the png to encompass the entire character through the full animation cycle, and exported using grid packing. The frames came out at different sizes however and in different relationships to the animated character. I have 2 questions.

  1. Based on this, how would you write out a regular grid with the same dimensions, keeping the character in the same place in relationship the borders of the squares of the grid?
  2. Does the Atlas that is generated contain the information for registering the images on the sprite sheet so that they play back correctly in a game engine?

@[excluído]
Are you sure the bone that had the png attached wasn't moving?
Are you sure the transparent png was big enough to comprehend all the animation states? (big enough to fit a jump and not just the setup pose)
Answering to question one depends on the two questions above, a.bout question two, yes because it's just a standard spritesheet. You set the fps and then move the root in the game engine. Tested in various projects and it worked pretty well.