• Editor

  • Information on exporting before I buy

    engleski

I've been evaluating my options for an animation tool, and Spine is inching its way to the top, both for impression of quality and price. The first is nice but the latter not, so I'd like to make sure I can make it work in my tool chain. Everything else is well documented except export options and formats, and that is also not available in the trial version.

The kinds of questions that are not answered:

  • When exporting as PNG, are all animations exported as individual frame images? How are they named, can I customize the naming?
  • Are all animations for a sprite rendered using a common crop rectangle or does it vary by animation? Does it vary by frame? Can I configure this?
  • Are batch exports handled properly when animations are updated? If I make an animation shorter and re-export, are the frame images for the previously existing extra frames removed, or is there an option to delete old assets beforehand? If animations were to share crop rectangles and I only export one particular updated animation, is it sure to have the same settings as the previous batch export that exported them all?
  • When exporting PNG files, is there any way to tell where in the resulting images the root bone of the sprite is? Does exporting PNGs in general create auxiliary data in JSON form or otherwise that lets me know where the origin and/or crop rectangle is? If animations render at different image sizes, how can I tell where their shared origin is?
  • When exporting as JSON, how are the needed image assets exported. The screen shot in the manual doesn't even have an option for specifying image format, I assume it's PNG by default?
  • If I export as PNG, how do I get access to events?
  • Is there a way to customise the exported data files so that they would fit the engine's requirements better?

My primary use case at the moment uses XCode for atlas creation so anything else is just in my way and I do not intend to use runtimes (i.e. I need fully baked animation frame images) for this project.

This is probably just a scratch, but you probably get what I mean. I'd love to think I found the tool for the job, but the last step is the most important so any help here would be well appreciated.

Related Discussions
...

  • Nate

  • Objava #3
  • This post is in engleski

You can export PNG, JPG, or GIF images. Sequence export writes images as individual files which can optionally be packed into an atlas. Individual files are named name1, name2, name3, etc and this can't be customized (but of course could be renamed afterward). Exporting first deletes files following this naming convention.

Each set of images that make up an animation sequence have the same size, which is the size of the largest image in the sequence. There isn't yet an explicit setting to customize this, but you can use a transparent image which is larger than all frames of your animations to have the same image sizes across multiple animations and later exports. This leads to a lot of white space around most frames, but that is not an issue when packing the images into an atlas with whitespace stripping. Currently the origin location within the images isn't written as metadata, however when using a large transparent image you know where the origin is.

If you need access to events, you could export the JSON data and parse the event section.
Spine: JSON export format: Events

Please let me know if I missed any questions!

Nate wrote

Each set of images that make up an animation sequence have the same size, which is the size of the largest image in the sequence.

I assume this means the size that all the frames in the sequence take? If you have an animation of a jump, the resulting size includes both the necessary space for the sprite to go up as well as the jumping distance to the side?

I guess the biggest concern is how to sync up all the animations with respect to the sprite origin in the actual program. The solution you recommend would be a transparent image centered at the root that would be big enough to accomodate all frames of all animations. I'm pretty sure this would work for my immediate needs, because XCode does indeed do whitespace stripping when packing atlases so any excessive space would not be a concern when deploying.

I've worked on some HTML5 projects where I could have used something like Spine to make life easier and I'm wondering if this will work there as well. Does the texture packer export a JSON file to go with the atlas image specifying the placement of each image in the atlas with respect to its original position in the frame? Is it possible to get an example of what this file looks like?

In general I was well impressed with your tutorial videos, but info on exporting is very lacking. Maybe you could provide samples of the spine boy demo being exported with different methods to help others with a similar concern.

EDIT: Thanks for the prompt reply!

  • Nate

  • Objava #5
  • This post is in engleski
Whistler wrote

I assume this means the size that all the frames in the sequence take? If you have an animation of a jump, the resulting size includes both the necessary space for the sprite to go up as well as the jumping distance to the side?

Yes, it uses the maximal bounds across all exported frames of the animation.

Whistler wrote

Does the texture packer export a JSON file to go with the atlas image specifying the placement of each image in the atlas with respect to its original position in the frame? Is it possible to get an example of what this file looks like?

It outputs a simple line delimited file with atlas information:
Atlas export format
The example projects in the Spine installation directory each have an export folder. You can find the latest examples here:
spine-runtimes/examples at master

Whistler wrote

In general I was well impressed with your tutorial videos, but info on exporting is very lacking. Maybe you could provide samples of the spine boy demo being exported with different methods to help others with a similar concern.

It's a good idea, we'll see what we can do.