Disabling IK Goal in complex nested IK.

[TheDogtoy]

Hi,
I have a solution for the problem I’m trying to solve but feel like I’m missing something fundamental. I don’t like my solution as it seams like a janky work around.

You can see in the picture here my hip IK happens first. The Spine IK has its solver strength set to zero but still is pinning to the location when using the hip Set Transform Ik. The legs are pinning too even though their strength is set to zero.

shouldn’t the Ik handles be ignored if their strength is set to zero?

The only way I have found to solve this is to split the IK rigs into many separate IK rigs and then apply them in different orders depending on the situation in the ABP

This seams wrong to me, as setting the “Goal Position Alpha” to zero should disable the IK handle for IK in ALL solvers but it only seams to disable the handle for the solver it belongs to. The handle still effects other solvers. You can see I put my “Poll Vector” IK in a separate solver so I could turn it on/off when it was needed as having that in the same “rig” I could also not fully disable the handles when setting the alpha to zero.

Am I missing something? Am I approaching this wrong?
P.s. If you wondering why I split this into multiple solvers, it gives more predictable results then trying to have one giant solver across the whole rig. I also need to change IK handles as the characters traverse the world.

[TheDogtoy]

For anyone that comes across this. I found a solution. Don’t use IK rigs. Instead create the IK handles as needed in a Control Rig and drive that through the Animation Blueprint.

[MostHost_LA]

Never used the IK rig, but you are doing many things “wrong”.

Using max could be a good idea, but as you can see you lost fastpath on the node because of it.

You cannot have any computations or evaluations of any kind to retain fastpath.

That could partially be why you get “wierd results” in certain scenarios.

Im not aware of IK having a strenght value anywhere. If you mean the Alpha, then all it does is it interpolates how much of the motion toward the goal should be achieved.

You can think of it this way, the hand is by the waist, the goal is a button about head height.
Simply shifting alpha from 0 to 1 slowly would move the whole hand chain along from hip to head high as if you animated it.
Yes. At a base level, 0 = don’t apply this.

Order of operations matters in just about anything.
That could be why splitting the nodes worked better for you.
But if the first setup moves by X and the second setup adds to that motion you could have issues.
You need to be sure of what you are adding on.

Most common mistakes with this are generally more basic, like adding an aim offset on top of a pose rather than before it.

I believe the particular solver you were attemtping to use has both a master and an indivisual switch, but how they are actually implemented needs to be tested out.

It could be the main alpha toggles them all off - but it could also be that when you assign individual values to each, the individual value is retained instead (And if thats the case, I’d suggest filing a bug report to change this feature, since it goes against most engine logic?).

Anyway, no idea what your end goal is, but you have the right idea with not using all one IKs (of any kind).

Id suggest you look up and stick to the older systems like cckid and fabric (unless they deprecated them).

Just remember that the animation bluprint is to have NO CODE.
You pass variables from the character into it.
All computation is character side.

[TheDogtoy]

@MostHost_LA

ou look up and stick to the older

Thanks super helpful. I’ve moved fully to setting up Ik through the control rig as I need it and that is working wonderfully thus far. I also discovered Full body IK isn’t great and am even using “Basic IK” with my own constraints in many situations, as the pole vector gives me more control.