Leg_3jnt_01 Not Building in Right Place

[mrVal]

Hello. I’m pretty new to mGear, so hopefully this is a rookie mistake. I’m using Leg_3jnt to create the legs on a stylized insect, and they aren’t all facing forwards. The front legs (which are facing forwards) work perfectly. However, the middle and back pairs of legs (facing 45-degrees and 90-degrees away from the front) are building with the knees and ankles in the wrong position.

I’m experimenting with using a post script to manually move them to the right spot, but this feels hacky.
Any suggestions?

I’m on mGear 3.79, and unfortunately can’t upgrade due to my client’s pipeline.

[chrislesage]

Hi @mrVal I’ve just upgraded your user level, so now you should be able to post screenshots. That might help figure things out.

Or can you share a guide file to look at?

If you just moved the knee sideways to “rotate” the leg, it might not work as expected. You might have to only bend the knee in a forward angle, and then rotate the entire root of the guide. Or maybe there is a bug.

[mrVal]

Hi Chris, thanks for the quick response! I’m attaching here a screenshot of the guides and resulting legs, as well as a Maya file with just the offending guides included.

Maya file.

I was careful to keep everything planar when positioning the guides, so I don’t think that’s the issue.

Interesting update: Sometimes the legs work properly if I only build the leg… but if I build the entire rig they always build out of place.

[chrislesage]

I’ll try to take a look this weekend.

But if you change some of the space switches, does it pop? Or pop back into correct position? I wonder if any of the space switch constraints are flipping or something. That could possibly explain why it works when only the leg is built.

[mrVal]

I would appreciate that very much.

I went back in and tried the following:

• Removed the space switch references
• Changed from spring solver to RP solver
• Tried different space switches
• Tried adding a joint to the master control

Nothing helped, unfortunately. I’m interested to see if you’re able to find anything.

[chrislesage]

The ikSpringSolver (this is a Maya solver, not an mGear issue) is pretty temperamental. It’s hard to use, and it often flips.

You can solve the direction problem by changing the solver to rotation plane. (Like you already tried and mentioned.)

But that might not behave 100% the same. So you’ll have to test.

Even though the direction is fixed, the limb still does a weird bend.

And that is basically because the solver (or the component?) expects a leg-like bend, with the knee more forward than the ankle. If it doesn’t have that bend, I guess it just has trouble solving the angles properly.

If I put the knee more forward, and still using “rotation plane”:

This might mean you’ll have to either adjust the angles of your neutral model (if possible), or consider rigging this in a different method.

[mrVal]

Chris, thanks again for having a look at this. I understand that I’m asking the solver to do something it wasn’t intended to do (with both the knee and ankle bending in the same direction). The odd thing is that it works perfectly on the front leg.

Being so new to mGear, I’m hoping you can help me decide how to proceed. My first thought is to generate all of the legs facing forwards on Z, then rotating them and reparenting them to the main rig afterwards. How complex are the hierarchies and connections in an mGear rig? Is that going to be a huge pain in the butt?

[chrislesage]

Oh right, I kind of forgot the main aspect of your question; they work until you include them with the full rig. I’ll try to dig a little bit more and see if I can spot why that happens.

The hierarchies and connections can be a bit tricky sometimes. But building them straight and moving them into place might be a decent strategy. If you have space switches, you may have to update the constraints so it stays in place.

This is the PyMEL equivalent of hitting “Update” on a parentConstraint on a node that has been moved:

import pymel.core as pm
oCons = pm.PyNode('Your_Space_Switch_Parent_Constraint_Here')
oTargets = oCons.getTargetList()
pm.parentConstraint(oTargets, oCons, edit=True, maintainOffset=True)

[mrVal]

Ok, so I’m not super sure what happened here, but for the sake of anybody else running into this issue… I ended up setting up my scripts to import everything into the scene while building the rig (so the scene contained no geometry, just the rigging guide). For whatever reason, it always places the joints in the correct place when run this way.

Chris, thanks again for having a look at the file and helping me to troubleshoot.

[chrislesage]

Strange! But glad it worked out!

[wtfbbqjacob]

Apologies for resurrecting this thread but I’ve encountered a similar problem and I think it’s actually something to do with having multiple leg3jnt_01 components (I’m actually using a modified version here with 0 divisions but I’ve reproduced the problem with the original component too)

Here you can see the issue of the rig not lining up with the joints when I have two legs:

and here you can see the faulty leg works correctly when I delete the other leg:

Seems like they might be getting connected to the wrong curves or something?

Thanks very much!
Jacob.

[Miquel]

Thanks for the feedback @wtfbbqjacob I will check that.
Can you share the guide? thanks

[wtfbbqjacob]

Here’s a link - if you delete leg_c0_root then you should find that leg_c1 builds correctly. Thanks for the speedy reply!

https://drive.google.com/file/d/1y-r0SIFjEVGyHbueX0zGTPnh7tccJS81/view?usp=sharing

[wtfbbqjacob]

I’ve figured out a workaround - if the legs all have their own UI object then you don’t get the problem. It seems to be due to the legs all sharing the same BoneAMult attribute. Hope this is helpful!

[Miquel]

Good find! Thanks for sharing it. I will check that and try to add some notes to let the users know the limitation

[izze]

We have the same problem. Separate UI hosts for each leg helped the issue. But we also found that the leg will not build correctly when Maya pref’s are set to DG. It will only build correctly when set to Parallel.

[Miquel]

Maya sometimes is very funny

[actoratwork]

This issue is still happening in the current Mgear version!
I had to do separate Ui in order to solve it