Shifter: Ik/Fk switch/snap poole vector solving

[jdrese]

Handle the Pole Vector position as suggested by @chris-lesage

[thirstydevil]

Can you expand upon this so I can track this bug? We have badly solved pol vectors using the Epic components as with some more info I might be able to contribute.

Thanks.

[chris-lesage]

Hi @thirstydevil the basic idea is this. The previous algorithm for solving the polevector would move the pole vector directly to where the mid limb control was. It is very predictable to know where to put it. But placing it directly at the knee is not super intuitive for animators.

In this gist, I shared some code for how I calculate polevector positions so that it sits in front of the limb. https://gist.github.com/chris-lesage/0fcc9a344f2096cf6c82a353cb735b3e

However, I'm not 100% sure what algorithm Shifter is currently using. And there may be additional bugs that break IK/FK switching when the limb is scaled. Related forum thread (I saw your reply there too): http://forum.mgear-framework.com/t/ik-fk-match-on-arm-2jnt-freetangets-01-component/2327/7

I don't know if there any additional discussions anywhere, but I had an idea to store the neutral distance of the pole from the knee, and normalize that, so it puts it close to the neutral position. But any stored data like that, might have to be careful not to add backwards incompatability. Ideally the tool could work on any limb, even non-Shifter limbs.

[thirstydevil]

Hi Chris.

That code pretty much 1-1 of the code I have in our FK-IK matching function from our previous rigging system, and it worked very well. I'll take a look through the code to find out what required. I pretty new to the system and I see _mth and _ref nodes being required by the code. I'm not sure of their function within mGear yet. I don't think they are needed for the pole vector part of the calculation. They might be needed to solve orientation for the wrists and feet. Anyway, I'll have play, hopefully I can submit a patch if there isn't one already out there.

[chris-lesage]

Yes I think you're right. I think (but don't know) that _mth might stand for "match". Those nodes are in the regular Shifter limb components. But I haven't checked the Epic components. I think they are just reference transforms that store the neutral transform of some of the controls, including how the wrist/ankle gets oriented during the switch.

I think you're right about them not being used in the pole vector part, which more purely uses the triangle of the specified bones.

In fact, back in 3.0 or 3.2, there were some bugs (in our rigs) where the _mth nodes were misaligned 45 degrees with the neutral pose of the limb. And that caused drift in the IK/FK match. So in a post process, I matched the _mth to the neutral pose of the limb, and it fixed it. But I lost track of whether that bug still existed in 3.6 onwards, or whether it was just the way I was setting up my specific limbs, because I altered the hierarchy somewhat. (Sorry that's probably not super useful.)

[thirstydevil]

The _mth "match" nodes are essential to the current system as they are being used as the "ground truth" of the FK to IK solve. The system is setting the source.worldMatrix to destination.worldMatrix over time

        for j, n in enumerate(key_dst_nodes):
            n.setMatrix(worldMatrixList[i][j], worldSpace=True)

In my case, the _mth node "arm_R0_upv_mth" represents the final position of the pole vector control "arm_r_upv" and as you can see above it's just a world matrix get and set. It's elegant because it's defining a generic shifter way to solve the pole as these nodes just need to exist when building up the lists to send to the main function. Nice! However, it's wrong as I don't think you can say that the pole position can be defined as a simple offset from the upper arm.

Here's a video where the green box is the Pole Vector solved with @chris-lesage gist and the predetermined position represented as the red box.

Our animators have labelled this as a P1 issue and I'm going to have to role a fix. any input before I proceed would be welcome. I think I need to build the matrix array with some awareness of the destination nodes and thus calc just the pole differently. This method can be a fallback method if required.

https://drive.google.com/file/d/1UH9tpO-g0csq1ZDed3t-gZWCt5NA4FIr/view?usp=sharing

[miquelcampos]

Hello, @thirstydevil and @chris-lesage Thanks to bring this up. I have added it to the mgear4 project to-do list and marked it as High priority.

[thirstydevil]

Hi @miquelcampos I've submitted a merge request that fixes the calculation for our rigs. I think it's done with a minimal amount of code changes. Although I did refactor the 4 repeated code blocks into 2 functions just to reduce noise. https://github.com/mgear-dev/mgear_core/pull/87

[miquelcampos]

Thanks @thirstydevil I will review and merge it ASAP.

[miquelcampos]

@thirstydevil thanks again for the PR I have merged it manually in the mGear4 repo. I have found a bug while collecting the lists for the ikRot ctl. Because was appending a list to another list instead of extending it around the line 1835 I fixed by checking first if is a list, and for my tests looks like is working

            src_nodes = self.ikTarget + self.upvTarget
            key_nodes = self.fkCtrls
            dst_nodes = self.ikCtrl + self.upvCtrl
            if ikRot:
                if isinstance(self.ikRotTarget, list):
                    src_nodes.extend(self.ikRotTarget)
                else:
                    src_nodes.append(self.ikRotTarget)
                if isinstance(self.ikRotCtl, list):
                    key_nodes.extend(self.ikRotCtl)
                else:
                    key_nodes.append(self.ikRotCtl)

I am not making more releases for 3.7 so you may want to check this on your side

btw: I will archive all the 3.7 repos soon. if you have more PR please do it on the mgear4 repo. Thanks!!