search

bendmorris / spinehaxe

Spine runtime for Haxe 3. Based on current AS3/libgdx runtimes.
Other
64 stars 28 forks source link

Are Bone matrix values correct? #27

Closed jeremyfa closed 7 years ago

jeremyfa commented 7 years ago

I was hoping I could discard my own port of spine (https://github.com/jeremyfa/spine-hx) in favor of spinehaxe, but I am running into a couple of issues. The main one is related to bones matrix values.

When drawing a quad from a spine animation, we can normally map bone's matrix values (a, b, c, d, worldX, worldY) to a renderer's quad matrix, allowing to get all transformed values (rotation, scale, translate and... shear (matrix-wise: different values for rotationX and rotationY).

Currently, the matrix values I get from spinehaxe are different from spine-hx and I don't get correct display as soon as there are shear transformations involved (the display get slightly different in a way or another, but not exactly what is expected). As an additional information, spine-hx is used for quite a lot of different animations (involving shear) in a production game (using these matrix values), and all these animations get correctly displayed, so, while I can't guarantee it's bug-free, it has proven to give expected output so far.

I was wondering if these matrix values are tested for spinehaxe and if there are any examples, based on spinehaxe, that use them directly (and handle shear correctly)? So far I have only seen code using values like rotationX, scaleX, scaleY, worldX, worldY thus not always displaying the expected transformation at the end.

bendmorris commented 7 years ago

Can you provide an example? It would be helpful to see the output from spinehaxe, one of the official runtimes (preferably AS3) and spine-hx to compare. I just reviewed the implementation of Bone.updateWorldTransformWith and spinehaxe is identical to the AS3 runtime.

jeremyfa commented 7 years ago

At the moment I can't provide an example as is as it's related to a private project, but I will anyway setup a haxe + (official) starling project that allows me to test the 3 runtimes implementations you mentioned. That will indeed help to spot which implementation doesn't match the expected (and even allow for further testing). I will update this issue when I have more information on the subject.

bendmorris commented 7 years ago

Thanks. I'm updating SpinePunk to use these matrix values as well so I can try to reproduce the issue you're seeing.

jeremyfa commented 7 years ago

Some updates: I succeeded to get correct display with both spinehaxe and spine-hx, but I still had to use the matrix values a bit differently for each implementation (see code screenshot below). spinehaxe output seems flipped vertically compared to spine-hx. I don't know which one is wrong/right but this convinces me more and more to set up a project to make it easier to compare with the official as3 spine runtime. It will be a useful tool for future tests anyway. I also have plenty of animations to test on it. Will set this up soon.

capture d ecran 2017-06-08 a 09 40 40
bendmorris commented 7 years ago

Are you explicitly setting Bone.yDown? In spinehaxe it defaults to true, and in spine-hx it looks like it has no default specified, so it would be false if not set.

jeremyfa commented 7 years ago

Ah, interesting. Didn't notice this option.

spine-hx reflects what is done on the as3 runtime, which doesn't seem to have any yDown default value either (and should default to false as well).

Any reason why it is set to true by default on spinehaxe? I would expect it to behave the same as official runtime here as well.

(by the way, currently working on setting up this starling project to test the 3 runtimes)

bendmorris commented 7 years ago

Any reason why it is set to true by default on spinehaxe?

Yes. yDown is an environment-specific setting. While the official runtimes cover multiple frameworks and languages (all of which share the same default) and the editor itself uses increasing Y for up, the AS3 examples explicitly set yDown to true. spinehaxe is based specifically on spine-as3 and is generally used with OpenFL, and I'm not aware of any users of spinehaxe in an environment where yDown = false would be more common. So it seems most reasonable to use yDown = true as the default.

jeremyfa commented 7 years ago

Given that the default is yDown = false in official runtimes, I would expect it is the same on spinehaxe instead of making assumptions on how people use it. Imo it would make more sense to follow the same pattern as the official as3 example if you are based on it: setting yDown = true explicitly in the examples and keeping the default to false. But anyway thanks for pointing to this option that I was not aware of. I am explicitly setting the value and both runtimes are giving the same values now. Closing this issue as it is solved.