Leg_3jnt_01 can't be reversed

[chrislesage]

There’s a bug with leg_3jnt_01 spring solver. This exists in 3.6.0 and 3.7.9.

If you reverse the angles, you get problems. This only happens with the spring solver. (Which I realize is a solver that has plenty of problems. But I really think this particular bug can be solved.)

In this image, my intended limb shape is on the left. The way that leg_3jnt is designed to work is on the right.

In the angle calculations, it seems there is some assumption about the direction the angles must face. And when the rig builds, the one on the right is completely mangled and doesn’t function correctly at all.

(I’ll dig further and see if I can find why it’s happening.)

[Miquel]

Hello @chrislesage

@chrislesage

In the angle calculations, it seems there is some assumption about the direction the angles must face.

Not that I recall now.

Can you check if the 3 joints that have the spring solver are working correctly? Sometimes the solver resolve the inverse direction with the up-vector
I have a checker with some precision rounding test that and flips it if it fails.

In my test looks like is working correctly

can you try to move slightly the locator positions? Sometimes that does the trick

[chrislesage]

The chain3 isn’t flipped, but the chain2 is. I was aware of the flipping spring solver, but usually when I saw it flipped, it would flip all the way into the skinning skeleton’s final result. I hadn’t looking into those chains yet.

I’ve tried several different positions. It consistently acts this way. It doesn’t seem the same as the random flipping you get. This seems like a flip, but a different level.

chain3 visible:

chain3 and chain2 visible:

I’ll keep investigating too.

[Dave_Moulder]

Hi all, I was finding this flip happened when I started to investigate the “slightly off planar” solution for this component. The error for me lay in the 180 degree flip calculation line 750. I’ll post below the line as I have it now. Maybe it’s the same issue and this fixes it. I think the method of checking the vectors was too strict for the off planar solution. But also might apply to the previous component.

if not self.chain3bones[1].getTranslation(space=“world”).isEquivalent(self.guide.apos[1], tol=0.5):

-Dave

[chrislesage]

Thanks @Dave_Moulder I’ll check this out this week!

[Miquel]

This component needs a good revison/refactor
I will be also checking it ASAP

[Dave_Moulder]

I’ve also found that this code here mgear.core.primitive.add2DChain line 330-347, when commented out pretty much fixes the issue with the legs flipping and not working when slightly off a plane. The code is also flipping the direction of the Z jointOrient that has a bearing on the flip we were discussing above. I’m not sure the rounding method is accurate and it should be delegated to dt.Vector.isEquivelant with a tolerance check. It’s again used in the “flip test” on the Leg_3jnt_01 component and we could be flipping 2 times.

I’m not sold on this code, it’s a fundamental bit of code that is enforcing logic that it doesn’t really need to, I’d push that back into the component if it’s really desired to check in this way or write somekind of utility method.

I’m fixing up my changes today and will get something ready to push to git tomorrow.

[Miquel]

Hello @Dave_Moulder

Thanks for checking it. I have created a new ticket to track this and fix the issues

Shifter Components: 3jnt leg Issues

Maybe a silly question, but… About the lines, you comment (330-347 ) are for the primitive.py module or the init.py in the 3jnt component? are you using mGear4 repo or the old mgear_dist?
That lines are the addIKHandle implementation

[Dave_Moulder]

Hi @Miquel this issue is at line 288 in the screengrab above, thats the code flipping the Z orient and I don’t think the rounding method is that tolerable to float inconsistencies and should include a tolerance before doing the flip. I’m not sure the code block itself is needed tbh if the creation is simplified. I’ve submitted my pull request now, take a look.

I’m finding it pain to develop in these separate repro’s and also test in our own deployed repro where is one folder structure. How are you guys working for development? This is prob best done in another thread.

[Miquel]

Hello @Dave_Moulder
Thanks for the PR. I will check it ASAP. For the moment I see that we have some merge conflicts with the curve.py module. But no worries, I will fix the conflicts

Also just let you know that I am going to archive all the old repos for mGear4 release. I would like to recommend you to use the mGear4 repo. It can be used directly since is all in one single repo with the final release structure. That should remove the “pain”