So, an update on what the system looks like in this video from Unite 2013 demonstrating the workflow: http://www.youtube.com/watch?v=B1F6fi04qw8
Seems to me like using the new Sprite Renderer system might become more sensible vs Spine's current setup that uses a mesh and a mesh renderer. But it's not clear from the video how well it supports Spine's system of setting the vertices and UVs yourself so that nonuniform scaling (and eventually also warping) will work.
It's actually a bit confusing 'cause it shows an auto-generated mesh in that mushroom example, but the other tool only showed rectangles. I guess there's a difference between background elements and small stuff? Or there's a consistency issue if regions change shape? Weird.
There's Box2D built in. It has polygon colliders. That probably has something to do with bounding boxes. XD
Another thing to note is their encouragement of using world units as meters. This is different from the 1 unit : 1 pixel standard that Spine uses for Spine-Unity by default. I personally prefer to use 1 pixel:1 unit, which works out okay 'cause I don't really rely on Unity's built-in physics to move things or do gravity for game-logic-relevant things. But it might be a thing for some users.
There is a segment in the video showing how the new Animation Window interacts with their new 2D system and sprite asset + sprite renderer. This is where it's doing some of the things that 3rd party sprite animation systems were necessary for.
There's a lot of very nice conveniences in the UI I'd love to see mirrored in Spine Editor. :p The advantage of their tools is obviously that it keeps with the typical image-is-a-bone paradigm so, usability-wise, it has very low cognitive overhead, and very little relearning for people used to ahem AfterEffects and other similar programs. Very familiar handle system too.
Flexibility-wise, I dunno where it stands. But if you're using Unity, this does immediately make Unity's built-in tools the better option if you're just making small, simple things, even if you need curves (or especially if you need complicated curves but not much else). That said, I'm on the fence with trusting it with character animations. (the image chooser makes me jealous though. XD)
But the new packer does also immediately seem like the better option for frame-by-frame effects that are comprised of frames that waste too much space as rectangles (which we happen to have a lot of). eg, images are are round and irregular and have big gaping holes in their center.
I'm not sure where libGDX atlas format currently is on that front. I didn't look into it too much but there's some mention of "polygon region" in their docs (but it was marked as work-in-progress).
No FFD on their end though, so... there you go.
