Esoteric Software

[Snow_storm]

We’ve found a super BUG about scaleX/scaleY of spine:

When I am trying to scale X/Y axis of a bone, all of its child bones will be scaled according to their own X/Y axis!! Once a child bone is rotated/scaled, it will be done in its own coordinate system rather than its parent bone’s coordinate system.

For example: there are two same rectangles, parent and its child, and the child bone is rotated by 90 degrees. When I scaleX the parent one (make it taller), the child one grows horizontally. Actually the child bone is supposed to grow in the same direction of its parent (grow vertically).

In setup:



after scaleX



This indicates that spine does not calculate the scale matrix correctly. I guess it’s been calculated separately rather than count as a whole matrix.

Hope this would be fixed asap. This function, for developers, is too hard to understand. Please just simplify it, because spine could not make some simple effect, such as stretching correctly (shown in pic below)

[Pharan]

It's not a bug. This was by design.

Though I suppose it would be a valid complaint about the design.
I guess one could make the argument that nobody would really rely on this type of scale inheritance.

This was brought up before and I vaguely remember this being an order of operations issue, and that the alternative had some drawbacks of its own. Can't really remember the details, or if I was remembering something else.

[Snow_storm]

It's not a bug. This was by design.

Though I suppose it would be a valid complaint about the design.
I guess one could make the argument that nobody would really rely on this type of scale inheritance.

This was brought up before and I vaguely remember this being an order of operations issue, and that the alternative had some drawbacks of its own. Can't really remember the details, or if I was remembering something else.

really?

If true, that's too bad...

I don't know what benefits can bring it by this design~~

I know this brings a lot of trouble,

for example, I want a special effects animation: flip left to right , then right to left ,then left to right...etc..
I can't do anything in this design, but it's easy to do it that I just setting scaleX(-1) to rootBone when normal design

and for another example, I want role can be dynamic stretching by Y axis, I can't do anything in this design, but it's easy to do it that I just setting scaleY to rootBone when normal design

at last,we just want spine animation like a "animation" , just like most of other Animation Editors, just like normal matrix transformation in cocos2-d,cocos2d-x,or other game engine

[Snow_storm]

I just looked at the source code,

I think void Bone_updateWorldTransform(...) can't be work correct

all "world variable" correct (worldX,worldY,worldRotation,worldScaleX,worldScaleY)

but I don't think m00,m01,m10,m11 is right

assume r0 = parent rotation
sx0 = parent scaleX
sy0 = parent scaleY

r1 = self rotation
sx1 = self scaleX
sy1 = self scaleY

correct if I use matrix transformation :
m00 = cos(r0)*cos(r1)*sx0*sx1 - sin(r0)*sin(r1)*sx0*sy0

in source code:
m00 = cos(r0+r1)*sx0*sx1 = cos(r0)*cos(r1)*sx0*sx1 - sin(r0)*sin(r1)*sx0*sx1

so when sy0!=1 , the equation was not ....etc...

[Søren]

Spine uses non-shearing scaling which in most cases is far preferred to classical scaling. With classical scaling using the matrix stack you would need to align your images perfectly to their parent bones to avoid images being distorted when doing non-uniform scaling. Classical scaling would make setting up your rigs in Spine MUCH harder especially if you have multiple images on the same bone.

One option we have is to implement both scaling types but it would become very hard to switch between them and the runtimes would be complicated.

You can read more about the subject here http://www.softimageblog.com/archives/84

[Snow_storm]

Spine uses non-shearing scaling which in most cases is far preferred to classical scaling. With classical scaling using the matrix stack you would need to align your images perfectly to their parent bones to avoid images being distorted when doing non-uniform scaling. Classical scaling would make setting up your rigs in Spine MUCH harder especially if you have multiple images on the same bone.

One option we have is to implement both scaling types but it would become very hard to switch between them and the runtimes would be complicated.

You can read more about the subject here http://www.softimageblog.com/archives/84

I Finally Got It~~ Thanks Pharan and Shiu...

we rellay very very very very much need classical scaling (fe: flip role in animation,scale role in animation, just scale rootBone ),

although that really very hard to switch between them, but I think it can switch between them in setup (just alternative), it's can't be runtime changes (like bone length,only can setting it in setup, or can setting it for each animation begin~~)

if do this, spine editor just add one UIMenu or add setting option.
spine runtimes just add a flag for two scaling types, and change a little code (only change Bone_updateWorldTransform(...) add classical scaling for m00~m11)

Thanks again~~

PS: I do change runtimes very simple, but I can't change spine editor...

[Nate]

The difference in the math for applying classical scale is minimal, as you mentioned. One issue is that it introduces skew. Skew cannot be represented by SRT, so once skew gets into the matrices, certain computations become more difficult or impossible. Eg, if a bone's coordinate system is skewed, bone compensation can't work correctly. This is because bones use SRT and it is not possible to compensate for a parent bone when skewed. The only fix is to store more than just SRT, but that becomes a significant change to how things work.

It could be possible to change from non-shearing to classical scaling in a project settings dialog. Editor tools like compensation that fail with classical scaling would have to be disabled, which is unfortunate.

[Snow_storm]

Thanks Nate,

and hope It could be possible to change from non-shearing to classical scaling in a project settings dialog!!