I'm not sure what you mean by "Flipping around the axis that is local to the skeleton could also be valid". What would define such an axis? A skeleton has a global coordinate system and then a number of bones, which each have its own a coordinate system.

The root bone is indeed a bone in every sense. It is only special because it has no parent. A bone has its own coordinate system. It originates at the bone position and is rotated and scaled by the bone. Each child is defined in this coordinate system and so is affected by the scale, rotation, and translation of the parent. Since the root has no parent, it is uses the "global" coordinate system which is (typically) screen axis aligned and has no rotation and scale.

The question is: Do we define flipping the skeleton as flipping the global coordinate system or flipping the root bone? This decision affects how the skeleton is positioned at runtime.

Currently, in some runtimes the skeleton is placed by setting the root bone position, so flipping the skeleton by flipping the global coordinate system changes the position, which is not desired. The skeleton could have an x and y position which is added to the world positions of the bones. Leaving the root bone at 0,0 and then setting its position is just another way to do this.

In other runtimes something else is positioned, eg a scene graph node. In this case 0,0 is the position of the skeleton. This means the root bone does not need to be positioned to place the skeleton, so the root bone doesn't need to be at 0,0 and can be used for part of the skeleton. If the skeleton is flipped by flipping the root bone, the root bone position is not changed and so will be in the wrong place.

What is the reference point for a skeleton? 0,0 or the root bone position? It's an interesting decision since both approaches are valid. I'm leaning toward not using the root bone for position. This means 2 extra additions are needed to offset each bone's world position for rendering, but we will have one less bone transform, which is 10 multiplies, 5 additions, a cos, a sin, 3 ifs, a method call, and about 25 field accesses. What do you guys think?

I don't think I should have to understand all the nuances of the root bone to use spine. It sounds like the root bone also means too many things and has conflicting uses. Anytime I find something like this in my code I know I'm asking for trouble.

I think all the runtimes should support positioning a skeleton in the same way they all support positioning sprites or whatever objects they have in their engines. Its not really productive to have to understand the way spine does positioning so I can then position the skeleton where I want it to be. At that level the skeleton should just be another object not something that I have special understanding of. I also think you are asking for a support nightmare if everyone has to write their own "make the spine skeleton position correctly" in my game engine code. There will be an endless supply of forum posts asking why my skeleton is not positioned where I want it to be. And please don't get me wrong I know I can figure out how to do it no matter what you provide but you really probably know better than me how varied the spine user skillset is going to be.

For example, in Cocos2d, I should be able to set the position and anchorpoint of the AnimationNode just like I can any other node and the skeleton should work like I expect. So if I set the anchorpoint to 0.5,0.5 and then set the position of the AnimationNode to the middle of the screen the skeleton should be centered on the screen.

Barry escribió

For example, in Cocos2d, I should be able to set the position and anchorpoint of the AnimationNode just like I can any other node and the skeleton should work like I expect. So if I set the anchorpoint to 0.5,0.5 and then set the position of the AnimationNode to the middle of the screen the skeleton should be centered on the screen.

Sort of. A skeleton doesn't have a (meaningful) center, since it is animating and (almost always) changing size. You need a reference point in the editor so when you place your character it is relative to that point. Eg, typically with a standing character you want the reference point between the feet. We are discussing whether this reference point should be 0,0 in global space or the root bone. There won't be any special nuances you have to deal with, have a little faith. :*

terryhau escribió

When i say 'Flipping around the axis that is local to the skeleton', i meant, the axis that you see in the spine editor. IE, if you placed your root bone, 5 units to the right of the origin in spine editor, at run time it would flip around the point 5 units to the left of the root bone no matter where it was positioned.

The axes you see in the editor are 0,0 in global space. The root bone is positioned in global space, this is why flipping global space messes up where you have positioned the root bone.

Do you mean just giving the skeleton a position attribute?

Yes. I think this is the best way to handle it. The two options are not so different, but this option is slightly more efficient. It is basically what you described. Giving it a go right now.

I finally have made these changes. Flip now flips the root bone around the origin. Use skeleton x/y to position your skeleton, not the root bone. It is no longer necessary to leave the root bone at 0,0 and unkeyed.

What is the origin now? The middle line in the editor or sth? Or is it calculated?

What's sth?

sth = something Old habit.

The origin in Spine is 0,0. When you place the skeleton at x,y you are placing the origin in Spine at that position. So, use 0,0 in the editor as a reference point for positioning your skeleton at runtime.

OK. Thanks. That should make things easier.

Yes, flipping changes rendering so everything is drawing facing the other way.

thanks nate i thought that was how it worked -perfect (again)

thanks
jim

btw - is it possible to test this out inside the GUI when creating an animation, or is this api runtime process only??

Runtime only for now.

thanks -look fwd to GUI version soon then

actually, it would be a VERY useful addition to the xml (related to the animation), to have a property on the timeline that indicated that (e.g at 00:00:02:23) the skeleton flipped x|y. This way, I could design inside the GUI and use the dopesheet to insert an 'event' that flipped the orientation of the animation until flipped back (or indeed had a duration to the inserted event).

I hope I'm clear in what I'm expressing here!?

You could do that with the event timeline, when it is done.