twist bones and snap IK fixes for the Simple IK rig

[Alessandro Padovani]

With simple IK the bend and twist bones don't work. That is, the twist bone doesn't twist. This is because in blender the IK solver always uses all three axis of the first bone in the chain, even if some are disabled.

To fix this we can make a simple ik chain that drives the daz deform bones.

steps:

1. duplicate lThighBend and name it lThigh.IK
2. duplicate lShin and name it lShin.IK
3. make lShin.IK child of lThigh.IK
4. add the IK solver to lShin.IK
5. add a copy rotation XZ to lThighBend from lThigh.IK
6. add a copy rotation Y to lThighTwist from lThigh.IK
7. add a copy rotation to lShin from lShin.IK

Below we can see the difference with and without the twist fix, that's the same as a full copy rotation from IK to the bend bone. Test scene included twist-fix.blend, that's the implementation above for G8F.

‌

note. For bones driven by IK as thigh bend/twist, it is wrong to keep the limit rotation constraints since the IK solver doesn't follow them and can be bad for fk/ik snapping. The limit rotation constraints are useful only for FK posing and only if we check "affect transform".

note. I didn't check mhx and rigify. It is possible they have the same issue with the G8 twist bones.

disclaimer. Rigging is not my area of expertise, I usually do very simple rigs, so there may be better ways to deal with the issue.

[Alessandro Padovani]

Thomas of course let me know if something is not clear, or if you think I miss something that’s entirely possible.

[Alessandro Padovani]

As for mhx I see it uses “damped track” on the bend bone and “copy transforms” on the twist bone. This works fine enough as visual deformation, but it is not the same because damped track also rolls there’s no way to limit it, while the bend bone should never roll, this is also required for jcms to work fine. I’d suggest for mhx to use a similar approach as above.

Again, unless I miss something.

‌

[Alessandro Padovani]

Back to simple IK, we could snap lFoot.IK to lShin in edit mode, this places the IK target at the bottom of the IK chain and should avoid feet sliding when saving the pose preset. The deform bone lFoot can keep its original position. I don’t foresee any collateral effect for ik/fk snapping by doing so, I tried it and seems to work fine. Again unless I miss something.

edit. Did some more tests, snap FK works fine, while snap IK needs to be fixed so that lFoot.IK is snapped to lShin.

‌

[Thomas Larsson]

Copy rotation constraints are tricky. Copying all three axes in world space is safe, but only copying some axes in local space can lead to unpleasant surprises, like the twist bones suddenly jumping. I had a lot of problems with that with the mhx rig, before switching to the damped track constraint. For a better explanation about what can go wrong, see the comment by Nathan at https://blender.stackexchange.com/questions/219681/copy-rotation-does-not-always-rotates-correctly.

Bend bones have IK Lock Y, and twist bones have IK Lock X and Z. However, those locks were only generated if the figure was originally imported with the global setting Rotation Locks enabled. In the last commit the ik locks are always generated.

The ik feet have been moved to end of the shin bones. I’m not sure if this makes things better or worse, though.

[Alessandro Padovani]

Thomas, as I tried to explain, in blender the IK lock doesn’t work for the first bone in the chain, that’s why I proposed the fix above.

If copy rotation doesn’t work may be you can use drivers instead ? Because damped track is good for original blender rigs but doesn’t work fine with daz twist bones and jcms. Or may be we can add a head bone to the thigh bend so the IK lock may work. Will do some tests and let you know.

[Alessandro Padovani]

update. copy rotation works in blender 2.9 local space.

I did read the article you linked it is very interesting thank you. Indeed with copy rotation in word space there’s an issue when I rotate the figure. If we use local space it works fine though. This is also reported by Daniel where it states that copy rotation doesn’t work in blender 2.8 but it is fixed in 2.9 with local space.

Will proceed with the head bone test and let you know. If it works there’s no need of copy rotation or damped track since the IK alone will handle it. But this also means the IK chain must be on the deform bones.

[Alessandro Padovani]

update. IK locks do not work on the first bone.

Nope, there’s no way to make the IK locks work on the first bone in the chain. That is, the only way is to add one more bone to the chain but then that bone will be unlocked, even if we lock all the IK channels, thus producing unwanted results.

The IK locks do not work on the first bone in the IK chain. Simple test is to lock all channels that should freeze the bone, the IK solver just ignores it.

[Alessandro Padovani]

update. SOLUTION. use IK locks and do not use poles.

Oops .. I forgot I already looked very deeply into this with Bandages at blender artists. The solution for the simple IK rig is to use IK locks and do not use poles. If we don’t use poles we can keyframe the twist bone to orient the knee and the IK solver will consider both the keyframe and the IK locks, so the bend bone doesn’t twist.

https://blenderartists.org/t/ik-lock-doesnt-work/1300633/

This means the IK chain must be on the deform bones though, so it works with simple IK but doesn’t work with mhx.

Below an example test with simple IK where the right leg has a pole and the left leg doesn’t. The twist bone works only without pole. We may place a warning in the tooltip that twist bones will not work with poles. Or remove the poles option for simple IK with G3 G8. Please note that poles can be used without twist bones as G1 G2.

‌

[Alessandro Padovani]

bug. snap IK

As for commit 046fc62, the IK bone snapped at the shin works fine to avoid feet sliding when we export a pose preset. But, as already noted above, snap IK must be fixed to snap to the shin as well, otherwise we can’t use snap IK for legs. Snap FK works fine.

‌

note. important. snap IK general bug.

There’s the same bug with snap IK hands, which don’t have the ik bone snapped to the forearm. So this seems a general bug with snap IK.

Please also snap the IK hands to the forearm in edit mode, this avoids IK “jumping”. The fk bones will stay offset same as the feet.

steps:

1. Pose hands and feet with IK. This makes the IK chains reach the IK targets so for example the shin will touch the ik foot and the forearm will touch the ik hand. While the fk foot and hand will be offset that’s fine.
2. Snap FK. This works fine.
3. Snap IK. This snaps the IK hand and foot to the fk bone that’s not good. It must snap to the end of the IK chain that’s where the IK target is reached. The fk bones will stay offset.

note. While we’re at it, it makes sense for “add custom shapes“ and “add simple ik“ to be one tool “Convert to Simple IK“, that will do the Simple IK rig same as “Convert to MHX“ or “Convert to Rigify“. There’s no reason to treat it differently it is a simple rig but always a rig same as the others. Unless I miss something.

[Thomas Larsson]

I have implemented your suggestion for simple IK, but it didn’t work terribly well, but that may be due to some misunderstanding on my part. The extra ik bones and copy rotation constraints are added if the Copy Rotation option is enabled. However, there are at least two problems.

1. The IK shin bones didn’t want to bend in the right direction, so I had to add an extra limit rotation constraints called Hint.
2. IK → FK snapping works perfectly (it didn’t before), at least if rotation limits are turned off. However, if you interpolate the IK influence between 0 and 1, the poses at intermediate values are different even if the end points are identical. This doesn’t happen with the old setup, at least not so much.

‌

[Alessandro Padovani]

As for commit dd5fbda.

question. important. I see you solved the snap issue by changing the shin and forearm bones to join the feet and hands. The main point of the simple rig is it doesn’t change the daz bones, so jcms and poses plus save pose preset work fine, since they all depends on the bones to be not changed. In this case though, it is only changed the bone end-point, while the pivot is not changed, so it may be fine I guess.

Will the daz poses and save pose preset be affected by the bone change, or do they only refer to the pivot so they will work fine ?

‌

‌

p.s. Also I’m going to test the new copy rotation and let you know. But basically if we don’t use poles it works now. The copy rotation is only needed if we want poles.

[Thomas Larsson]

Bug fixed: The IK influence should not be driven if there are copy rotation constraints. If both types of constraints are driven, strange things happen at intermediate values.

[Alessandro Padovani]

Ok I tested the new copy rotation. To reply your questions.

1. As for the IK shin bones, the limits should be stated in the inverse kinematics panel, not by adding a limit rotation constraint. I'm confused because the limit rotation constraint should not work with IK.
2. As for snapping, FK limits should always be turned off or it may not be able to snap to the IK pose, so this is normal. I see the issue with the influence but I have no clue why this happens.

Anyway, I see other issues too, such as the forearm doesn't twist with the hand, and bad settings as the IK bones must be quaternion to avoid gimbal lock. So I prepared my version of the simple rig that you can take as reference. It is fully functional apart the IK-FK snapping that I don't know how to do.

The layers are simple, bones on the left and controls on the right, fk up and ik down. Also left middle and right bone groups for the colors. I added a root bone for easy placing of the figure. I use sticks for the FK controls and empties for the IK controls so I don't need custom shapes.

‌

Features.

AUTO-IK. All the FK chains can be posed with auto-ik. To get this I connected the FK chains, paying attention to don't change the pivots, so parent tails are connected to child heads and not vice-versa. Also location locks must be removed from the chain tips, unless there's a single bone.

‌

TWIST BONES. The hand drives the forearm twist, and the shin drives the thigh twist, as expected. To get this I used copy rotation constraints in local space.

‌

[Alessandro Padovani]

example for simple-ik with working twist bones and auto-ik

[Alessandro Padovani]

update.

A little improvement. It is probably more stable to use quaternions both for the ik and fk bones, I mean for the free joints in shoulders and thighs. In this case copy rotation must be aware of the fk axis since xz and y are to be decomposed.

Also I removed the limits in the IK bones since I feel them unnecessary and probably limiting some poses.

Improved rig my-simple-ik-r2.blend.

‌

[Alessandro Padovani]

improved rig

[Thomas Larsson]

You can turn on the global Quaternion setting to import the shoulders and thighs with quaternions. That led to a crash when adding simple ik, now fixed.

[Alessandro Padovani]

As for commit 0530bd2 now I can import with quaternions thank you for the fix. There are a couple issues.

bug. twist bones. The forearm doesn’t twist with the hand. You can look at my setup as reference.

‌

improvement. forearm/shin ik. Instead of the “hint” we can lock the ik to x for forearm and shin, since this is how ik chains for arms and legs usually work. That is, with fk we may freely rotate the forearm and shin, but with ik this doesn’t make sense they only rotate in x. The same locks must be applied to fk for snaps to work.

Then copy rotation for fk is only on the x axis. Again you can reference my setup.

‌

improvement. root. Can you add a root bone please. Then when saving a pose preset we may add the root and object trasformations since daz doesn’t have a root bone.

improvement. auto-ik. Can you make the fk-chains work with auto-ik please. There’s fingers, toes, spine and tongue that would be good to have. Again you can reference my setup. For the spine may be we can keep out the chest upper bone from the fk controls since it doesn’t make much sense to bend, though in daz studio we can a little.

[Thomas Larsson]

I removed the hint constraint for the forearms. It is not possible to remove it for the shins, because the knees may bend in the wrong direction. The difference compared to the standard setup is that the knees are not bent in rest pose.

For auto ik the bone chains must be connected. That is better done by improving the Connect IK Chains tool.

With the hint constraint gone, the ik forearms can be manually rotated to match the hands. Your setup with constraints does not work. Here is what happens when the hip and all four ik goals are rotated 180 degrees in global space.

‌

[Thomas Larsson]

Sorry, I missed the pole targets. Anyway, your setup gives a dependency cycle: lForearmTwist rotation depends on its child lHand.

[Alessandro Padovani]

Sorry I didn’t check for dependencies, though this one doesn’t seem to harm.

We can copy the IK target instead, since it’s not connected we use “local with parent“. Since the hands are essentially free joints it may also help to use quaternions as the hand and hand-target coordinate system. This should help avoiding gimbal locks.

‌

[Thomas Larsson]

The Connect Bone Chains (new name) tool has been updated with several more chains.

[Alessandro Padovani]

As for commit 79f1486 the new options are very handy thank you, now we can easily make ik chains for auto-ik.

bug. connect bone chains. There’s a bug for the neck since it connects to upperFaceRig that’s not a deform bone so it doesn’t take part in the FK controls. Only neckLower and neckUpper should be connected. Didn’t check other figures than G8F.

edit. no bug. Oops .. no it connects to head sorry they overlap. So it’s OK.

‌

[Alessandro Padovani]

question. important. This is not clear to me so I’m asking please. When we connect bone chains, if we don’t change the pivots (location child head), will it affect the daz poses and jcms ? That is, do the poses and jcms only depend on the pivot or also on the bone tail ?

[Thomas Larsson]

Poses depend on the pivot and bone orientation, but not on bone length.

[Alessandro Padovani]

I don’t follow.

If we change the bone orientation for the rest pose, that’s what connect bone chains does, isn’t the pose relative to the rest pose ? I mean if the pose rotates x = 30 then it gets the same pose whatever the bone orientation is in the rest pose. For example below I changed the bone orientations for the rest pose. The pose imports perfectly.

Is it the same for jcms ?

This is important to know if we can connect bone chains without ruining poses and jcms.

edit. I did some tests and it seems to me that poses and jcms work just fine with different orientations. So we can connect bone chains with no issues. I need you to either confirm or explain when it doesn’t work please.

edit. important. In the example below I just entered edit mode and dragged the bone tails, that I suppose it is what “connect bone chains” does. But I see the comments on commit 0bd431e so I wonder if you do something different. So again please reply to my question so we know if using “connect bone chains“ is safe for poses and jcms.

This is related to #210, it means connect bones is compatible with daz poses and jcms.

‌

[Alessandro Padovani]

Commit 7e8333c works great thank you for the nice improvement.

bug. root bone. There’s a minor bug, the root bone is not saved in the pose preset. We need to add the root transforms to the object transform in daz studio since genesis doesn’t get a root bone. If this is not possible or too complex then at least we could have options same as import action.

The same issue seems to be there for mhx. The root bone animation is not saved in the pose preset.

[Thomas Larsson]

Fixed in last commit.

[Alessandro Padovani]

As for commit 15533c8.

bug. Doesn’t seem to work fine. May be it is difficult to add the root and object transformations when they’re both animated. If this is the case we could have options in save pose preset same as import action. To export as daz object transformations either the blender armature object or the root or nothing.

save pose preset: daz object transformations from

• object
• master bone
• none

note. The commit comment tells the fix is for simple-ik and mhx, is there any reason not to include rigify ?

Example of not working animation root.blend. This translates and rotates. If we save the pose preset to daz studio, or import it back to blender, then the figure transformations at frame 30 are different. Of course the camera is the same, daz studio default 65mm.

steps:

1. load the test scene root.blend
2. save the pose preset
3. load the pose preset in daz studio on G8F, or import action in blender on G8F

‌

[Alessandro Padovani]

test scene for object + root transformations

[Alessandro Padovani]

Please reply to my question above about pivot and orientation. It is important to know if “connect bone chains“ is safe. It should be.

[Thomas Larsson]

The simple answer is that I’m not sure. I thought that changing the orientation would change imported poses, but this doesn’t seem to be the case. Here is a comparison where connecting the spine doesn’t seem to matter.

‌

[Alessandro Padovani]

Ok thank you. It is the same with my tests. As I understand it, being the daz pose relative to the rest pose, the bone orientation in edit mode doesn’t matter because it is always perceived as zero. If you change the bone orientation in pose mode then it would be different.

Please let us know for the options to export the root, if it is doable.

[Alessandro Padovani]

update. SOLUTION FOR ROOT.

edit. new simple solution. It seems I found a easy way to export the root. I use a copy transforms from the root to an empty in world space. Then you need to bake and export the empty used as daz object. This works fine even if both the root and the rig object are animated in blender.

Let me know.

‌

[Thomas Larsson]

The pose preset should be saved correctly now.

[Alessandro Padovani]

As for commit 9f9b004.

The root for simple ik and mhx exports great to pose preset thank you for the fix.

For rigify I’m unable to export to pose preset, even if I bake IK to FK, but it’s probably me who miss something. Did you fix the root for rigify too ? Please reply so I will trust you and mark as resolved thank you.

[Thomas Larsson]

Now the Rigify root is found too. It was a casing issue; the root is called “root” and not “Root”. The save pose doesn’t seem to match the rigify pose exactly, but that is perhaps to be expected. Rigify is too far away from the daz rigs to be a good starting point for pose presets.

[Alessandro Padovani]

Thank you Thomas for the explanation.

I'm not good at rigify, probably I miss something how to bake it. So I trust you that it works and close as resolved. Thank you again for the nice improvements.