• Editor

  • Two IK2 constraints "fighting" each other.

    anglais

Hi there,

I have a skeleton with various transform constraints that change the Y scale of the model. They're linked to several skin constraints (Height+1, Height+3, etc) that I enable in Unity to create random generated characters with different heights and body types.

Then, I also have IK2 (two-bone) constraint for Arm_x and Forearm_x bones. Their target is well "up" the hierarchy under Root and NOT "under" bone with the scale constraints, so the hand always end up at the target coordinates of my choosing.

This is useful to "attach" a hand to something in-game, like a door knob, for example.

Now I'd like to have another IK2 constraint for the same arm bones, but this time with their target UNDER the scale constraints, so the animations that enable these IKs also respect the height (scale constraint) of the model.

This would be useful (I think) for all characters, regardless of their height, still be able to use a path with that IK. For example, moving their hands in an ample and complex circular movement (like casting a spell) and still look natural.

And if I were to try this with the previous IK, all of them would move their hands at the same absolute height, regardless of their relative height.

So, to solve this I went and created a duplicate of the previous IK2, but pointing them to a new target bone deep in the hierarchy.

It looks like this...:




Take notice both constraints are at zero mix in Setup mode. It's only on the actual animations that I set them to their effective value.

I tested it with the second use case and it worked fine. But when I look at the "hold door knob" animation it was completely messed up, with the arm disregarding the absolute target bone.

Then I switched the order of the constraints, and they also switched places in being wrong.

My guess is that it doesn't matter that both constraints start at zero mix in Setup mode. And they "fight" each other badly, as if both were activated at all times.

So... should I forget about having both IK2? Or there is a way of making them work at the same time?

If they can't exist simultaneously, I'll delete the relative one and just pose the arm bones, ofc, but it would be a shame not being able to use path contraints that also change height if needed.

Related Discussions
...

What version of Spine are you using? This should work fine in the latest 4.0. I just tested it, or something like it since your description is long and hard to follow. If you find it doesn't work, please post a simple project file that shows the problem.

I don't think this will work in 3.8, but in 4.0 we have improved how constraints are applied so they don't revert changes made by other constraints.

Ah, alright. I'm still in 3.8, yes.

I was waiting for off-slot linked meshes to upgrade, you know. But if you've made enhancements to constraints that would be nice reason to try. I have hundreds in my setup. It's a pretty crazy skeleton.

You should be aware than since in 4.0 applying a constraint doesn't revert changes made by other constrains, if you rely on the 3.8 behavior, you'll get strange results. In other words, if you rely on a constraint reverting the changes from other constraints in 3.8, you may not even realize you have constraints active that are doing nothing in 3.8. Then when you move to 4.0, to get the same results as you had in 3.8, you'll need to identify which constraints are active when they shouldn't be and set their mixes to zero.

Hmm... not sure what you mean. I guess it's because I only know the old behavior.

But most constraints I have are activated by a skin. And the ones that are not, usually have a zero mix in setup mode. Would that maintain things more or less like before?

Btw, does 4.0 logs migration warnings such as these, when loading a 3.8 skeleton?

Abelius a écrit

But most constraints I have are activated by a skin. And the ones that are not, usually have a zero mix in setup mode. Would that maintain things more or less like before?

Yes. It's only a problem if you had a constraint active and didn't realize it before, because another constraint was reverting the changes it made, preventing you from seeing it.

4.0 doesn't detect this situation, sorry. It would be tricky, but might be possible. However, I'm not sure it's worth the effort since it should be pretty obvious something is wrong when you have a constraint applied unexpectedly.