Question TwoBoneIKConstraint - Introduces unwanted twists to limbs?

I just found out about Animation Rigging the other day, so I'm still figuring things out. I'm trying to set up a minimal, easily manipulable, code-generated rig on an otherwise unanimated imported model (so no Animator or existing animations to override). I've set up some control targets/effectors and limb IKs from following a few video tutorials like Brackeys', and it's mostly working as I want it to.

I'm planning to use the simple rig to pose the model at runtime, which would involve manually manipulating the position of the sacrum/pelvis (top bone in the imported model's rig hierarchy) and the rotations of other bones. I've set up a controller for the sacrum which uses an Override Constraint, while the feet and hands are controlled by TwoBoneIKConstraints.

I had to add RigTransform components on a few bones to get the IK targets and sacrum working together.

I'm getting this subtle - but annoying - issue though:



It seems that once the IK adjustments set in when the distance is within the limits, unwanted twist issues are introduced, causing this 'snap' effect. The weird knee rotation was even more pronounced on a different rig, so I'm guessing it has something to do with the models' bone rotations. It'd be impractical to expect all imported rigs to have their bones aligned a very specific way though!

Before I found out about Animation Rigging, I was using a simple FABRIK-based IK script which produces this effect, for comparison:



That's the behaviour I'd expect and want. Well other than the feet, which are worse here!

The Unity IK has more accuracy when the pole moves around, though there's an inconsistent offset between the pole and the direction of the leg (the red rays are the forward vectors of the shins, though I don't know if those are even supposed to be pointing to the poles).



I've been using an addon from the Asset Store called UMotion for in-Unity animation for a while, which includes an IK wizard that can generate IK poles and targets with only a forward direction for the whole model to work with, and it produces results that have no 'snap', like the second example here, but with the higher accuracy of limb direction when the pole is moved around, which the FABRIK script lacks.

So I'm wondering, is this expected behaviour? I mean, it's *close enough* for most cases, so maybe everyone else just puts up with it since it's not a huge deal? It only becomes an issue when the limb is stretched beyond the IK limits anyway.

Or is there some obvious, simple parenting/component issue I can easily fix?

Or maybe there's some kind of rotation offset that's set behind the scenes in things like UMotion to get perfect results? Like how Blender's IK requires a pole angle to be specified. And if there is, how could it be calculated, as UMotion is apparently able to do using only the model's forward direction? I experimented applying simple tweakable float values to the bones' axes, but the results weren't as expected at all.

OR, is there some kind of perfect positioning for the knee poles to get ideal results? These are being generated by code at the shin's position + the rig's forward vector / 2f.

This might be too specific of an issue, but I'm hoping there's some simple thing I'm missing!

 

After a LOT of experimenting, I was finally able to figure out what was going on here. The imported rig's legs pointed very slightly inwards when viewed from the front:



That must've confused the Animation Rigging IK solver's attempt to figure out how the knees were supposed to bend. Straightening the legs in the front view in Blender - but keeping a slight bend when viewed from the side - eliminated the unwanted twists, and now the knees point perfectly towards the poles.

UMotion must use the provided forward vector when determining the knee bend direction in the way the Animation Rigging solver isn't able to. So it seems imperfectly-crafted rigs, like mine, produce subtle issues.