Home Website Youtube GitHub

FK->IK Match not matching on leg when secondary IK foot controls are not zeroed out

Bug
#1

I’m having this issue in 4.0.9 on the EPIC_leg_01 component.

I get an imperfect match in certain situations when switching a leg from FK to IK, in that the upv control is placed in the wrong position. This occurs when the IK foot controls have non-zero values (i.e., “bk”, “heel” or “roll” controls). If I manually switch to IK, zero out these controls, then switch back to FK and perform the match to IK, it works as expected. Is this a known issue?

FKIK_switch_error

I have a secondary complaint with IK/FK matching in general: The upv control is placed uncomfortably close to the knee/elbow on match when the limb is at straighter angles, although it seems like this is by design. Any chance this could be revisited so the upv is offset at a more consistent distance from the knee/elbow, perhaps a distance that is a fraction of the default length of the limb?

Thanks!

#2

Thought I’d bump this. Can anyone reproduce this bug?

#3

For the pole vector placement, I proposed a potential algorithm that would set it ahead of the knee. As far as I know the current method just snaps directly to the middle joint, so it doesn’t have to make any assumptions about bend/stretch, etc.

For the pop in your matching:

Can you share your guide+rig, preferably in a pose where it is ready to be broken?

I’ve seen sometimes when limbs don’t match perfectly. And it can sometimes be fixed by either making sure your guides are aligned in a perfect triangle, with only translateX and rotation along the plane. No sideways translation or sideways rotation.

And then sometimes you’ll need to go dig inside the rig and find the “_ref” and “_mth” nodes, and see if they are misaligned at the same amount as the drift that you are seeing. I have corrected some arm drift by snapping those to match what they are supposed to match.

An example script from the arm in my rigs. I don’t know if this “solution” can be generalized to the legs, or all the components. And I don’t 100% know why it happens in the first place:

import pymel.core as pm
from mgear.core import attribute
from mgear.core import transform

# Fixes the IK drift in the arm
attrsToLock = ['tx', 'ty', 'tz', 'rx', 'ry', 'rz', 'sx', 'sy', 'sz', 'v']
for side in 'LR':
    armIK = pm.PyNode('arm_{}0_ik_ctl_npo'.format(side))
    ikMath = pm.PyNode('arm_{}0_ik_mth'.format(side))
    attribute.unlockAttribute(armIK, attributes=attrsToLock)
    transform.matchWorldTransform(ikMath, armIK)
    attribute.lockAttribute(armIK, attributes=attrsToLock)
#4

Thank you for your response @chrislesage !

For pole vector placement we’re doing something similar with a layer of tools on top of mGear, where it uses the vector from the knee joint and repositions the PV control a fixed number of units from the joint. I hope your solution can get implemented in the next version!

For match popping examples, please request access to the following scenes:

  • Scene 1: a simplified version of the rig I’ve been working with
  • Scene 2: a basic spine + leg + foot setup I built from scratch (no geo)

Each includes a guide and posed rig that does not switch back correctly from FK to IK, which I have found happens consistently with any Epic leg + foot setup. Whenever IK reverse foot controls have rotation offsets and the leg is in FK mode, the leg pops when switching back to IK mode. I believe it’s a different issue from the misaligned node issue you were describing; I haven’t found this to happen on an arm/hand setup, because there are no equivalent hand controls to the reverse foot offsets.