New SpineUnity 3.3 runtime bug(?)

XXelnath · 30 जून 2016

Since I upgraded to the most recent version of the SpineUnity runtime and ex-ported my characters, one of the characters now won't raise his arm up anymore.

You can see it moves during the static "switch weapon" animations, but then it hangs down limply at his side. I thought maybe the IK override or the transform constraints attached to him were to blame... but they are all set to 0.0 Alpha (Blend %)

Can you guys think of any smoking guns? The idle animation looks and plays correctly in the editor.

If not, I'll dig deeper into the code and come back.

XXelnath · 30 जून 2016

BBluetiger · 30 जून 2016

Same for me, latest version of Spine-Unity runtime must have some bug, described my issue here: http://esotericsoftware.com/forum/color-key-affects-next-animation-possible-bug-6627

XXelnath · 30 जून 2016

Oh, wow, okay, this might have something to do with it:

The following is what shows up inside of the animation when I open it up in Spine Unity 3.3.0.7.

I am pretty sure my animator can't add animation keys that are less than one thousandth of a frame apart:

30 Jun 2016, 12:33

Nope. I deleted all of the keys and reanimated the idle - it's still not animating his arm correctly.

puzzled

30 Jun 2016, 12:51

Bones vs Target:

{
   "name": "LArmIK",
   "bones": [ "LShoulder", "LForearm" ],
   "target": "RArmIK"
},
{
   "name": "LFootIK",
   "bones": [ "LFoot" ],
   "target": "LFootIK2"
},
{
   "name": "LLegIK",
   "bones": [ "LHorseJoint", "LCalf" ],
   "target": "LLegIK"
},
{
   "name": "LThighIK",
   "bones": [ "LThigh" ],
   "target": "LThighIK"
},
{
   "name": "RArmIK",
   "bones": [ "RShoulder", "RForearm" ],
   "target": "LArmIK"
},

I noticed this strange loop my animator setup in our rig. What does the "Target" mean for an IK point - and is this possibly the source of the issue?

... okay, nope. I renamed all of these and it doesn't seem to be related.

30 Jun 2016, 13:10

Yeah... it looks like what's happening is that the RArmIK (Now renamed IK_FrontArm) is being treated as if it's set to 0% IK Mix for the entire animation. No idea why - even removing the override bones doesn't appear to have any effect.

30 Jun 2016, 13:19

Ok, I'm stumped. Somehow the IK mix is getting set to zero on any animation without an IK mix key.

Nate · 30 जून 2016

When you open your project in Spine it has way more keys than it should? :o Can you email the .spine file? contact@esotericsoftware.com

Otherwise if you have a problem, we need to be able to see for ourselves what is going on. If anyone can provide a self contained example or otherwise provide us with data and reproduction steps, that would be super helpful.

Pharan · 30 जून 2016

Just additional info:
"name" is the string checked against when you use skeleton.FindIkConstraint(string).
"bones" are the name(s) of the bones that are subject to/being constrained by the inverse kinematics behavior.
"target" is the name of the bone that the terminal constrained bone is supposed to point towards. The IK Target.

Are you saying those are new IK constraints that weren't there before?

XXelnath · 30 जून 2016

Pharan:

Those IK Constraints were there before.

Nate:

I'll send along the file. There's some specific steps you have to follow to trigger the bug:

Open the Spine file
Open an animation with an IK point
Swipe through the animation with "AutoKey" turned on.
As you do, Spine will inexplicably set a million keys.

Pharan · 4 जुल. 2016

Was it that the TransformConstraints are new?

The problem seems to be twofold:
(1) The editor wasn't behaving as expected so it was showing something was possible that shouldn't have been (at least through the editor).
(2) A current limitation of the editor is that you cannot change the update order of constraints, so certain uses aren't supposed to be possible: In your case, if your IK bones are children of transform constrained bones, the changes applied by the IK constraint becomes undone, even if the transform constraint is disabled.)

I think a way to fix this is fix the update order at load time, but I'm not sure what the order should be yet.
Can you try this Skeleton.cs code: https://gist.githubusercontent.com/pharan/a7f0109d8cd5719ceb8aefcee00ea318/raw/dc371ec487b0e51250be4c8650920177cb81fcec/Skeleton.cs
and see if the Transform cases for you?
The result is probably not the most efficient, but it might fix it.

XXelnath · 5 जुल. 2016

I will try it right now!

05 Jul 2016, 01:33

Serious question, why aren't transform constraints treated like additive weights?

E.g. If I have 3 constraints, A, B and C

A
B C

And I have 3 constraints set to 100% - why is the final bone position "C" rather than the center of the triangle formed?

05 Jul 2016, 01:35

In theory, you would just be doing the following operation:

Bone A pos * mixA
Bone B pos * mixB
Bone C pos * mixC
Base Pos * ( 1.0f - Mathf.max(mixA+mixB+mixC, 1.0f)

TotalPos / Mathf.max(mixA+mixB+mixC, 1.0f);

05 Jul 2016, 01:36

YES, that change fixed it!!!!

05 Jul 2016, 01:52

Correction, that only fixed it part of the time. T_T

Posting the video shortly.

05 Jul 2016, 01:55

As you can see here, it works fine, until layers get involved.

05 Jul 2016, 01:55

... hang on, I'll record another gif. ugh

05 Jul 2016, 01:58

05 Jul 2016, 02:04

https://slack-files.com/T08T0G6EN-F1NNWPL4F-37667184cf

It keeps saying the image I want to upload is invalid.

Pharan · 5 जुल. 2016

Upload gifs to imgur. I don't think the forum likes huge gif attachments.

Serious question, why aren't transform constraints treated like additive weights?

It was a decision. Some 3D animation programs do it that way. Some don't.

The current state of the matter is that constraints aren't aware of each other, nor are bones aware of the constraints affecting them. I think those would be requirements for making it work that way.

Just logically, it makes sense to me that when you set a Constraint to be applied 100%, it would just apply it 100%.
Though that logic possibly wasn't the reason for the decision they made.

You could still make it work that way at runtime, it's just that you wouldn't be able to preview it in editor.
@Shiu did mention this behavior though and it might become a different type of Constraint or something. We don't know yet. But thanks for the input there. Just to give a stronger case for such a behavior, what are your use cases for it?

Anyway, the strange behavior you're experiencing is a matter of constraint and bone update order.
We need to figure out the correct order in the update list for it to work as you expect.
Specifically, it's because the torso bone is subject to a TransformConstraint.
Applying a TransformConstraint requires all its child bones to be updated, and the torso is also the parent of the arms.
The arms are subject to IK Constraints. The effects of the IK constraints are undone because, by default and unless you reorder them, TransformConstraints are applied after IK Constraints.
I've yet to fully understand 3.3's new reordering methods. Nate probably knows the answer to this problem, though you may have to describe the intended behavior too. (which Constraint should be applied first, etc...)
I guess we could test a sorting algorithm that's aware of TransformConstraints that control parent bones of IK Constraints, huh?

XXelnath · 6 जुल. 2016

I'm happy to help in any way.

Regarding the transform constraints, it was more a question than an immediate need. For the moment, I've only need one transform constraint on most things I do. When I was making the UI ring (see Showcase forum) I wanted an easy way to make the cursor move towards whatever the active selected item was.

So I setup multiple Transform constraints, one for each item, then was planning to control the cursor's position by blending the transform constraints together. While test this in the editor, it was a pain to have to think-out how many constraints were going to be involved in my test and set the % mix appropriately for each, as opposed to testing by doing "100 of you and 50 of you and 100 of you" like a weighted system would use.

Not the end of the world, it was just that in most cases, Spine doesn't surprise me in how it works - and in this case it did. Maybe we should take this to another thread.

Back on the topic of the broken IK points:

And yes, I was expecting it to work like it did in the editor... but the editor doesn't display multiple tracks playing at once, so that behaviour is uncertain

As a thought exercise, doesn't it make the most sense for the transforms to position bones and controllers - then for IK to move the subsequent bones to their control points? Hmmm, I seee, then a bone that is moved by IK could never be fully relocated to its position by a transform constraint.

05 Jul 2016, 08:56

Oh - you asked me what the intended behaviour is:

The intended behaviour is that the "desired" aim angle is set on GunRotationJoint - this specifies what angle the missile will be leaving the body at.

This causes the head and chest to slightly tilt in that direction, while the arm IK specify exactly where the position of the end of the arm should be.

05 Jul 2016, 09:06

My animator said the following:

"The desired order I had for the transforms to be applied was Parent -> Child in sequence". So first the chest rotates to match the "GunRotationJoint", then the children are rotated, then finally, the IK are applied.

06 Jul 2016, 20:24

After playing around with this myself, I've concluded that while parent then child might work most of the time.... there's almost certainly a desire/need for manually ordered constraints.

In the process of getting the arm swing working, another, simple spine constraint stopped working. Cest la'vie