Hello ! I was trying to build a straight arm but mGear seems to infinite loop or freeze during the process.
I guess mGear don’t know where to solve the IK, but that could be good to be determined form axis and/or from world orientation.
OR
When it builds, joint orients are broken like below :
Game Biped Template used inside mGear 5.0.7 / Maya 2023
I’m wondering if something can be fixed for this without adding a rotation in the arm😊
Thank you !
Do you see any warnings or errors in the script editor?
I don’t know, but my first guess is some divide by zero errors when calculating the pole vector angles.
As far as I know, there must be at least some bend. It could be interesting to have an option where the pole position can be placed manually, but that feature doesn’t exist yet (also as far as I know).
No error raised
= GUIDE VALIDATION ==============================================
Checking guide
Get options
Get controllers
Get components
shoulder_L0 (EPIC_shoulder_01)
Find recursive in [ 0:00:00.018049 ]
Get parenting for: shoulder_L0
Guide loaded from hierarchy in [ 0:00:00.020041 ]
Checking guide
|guide|root_C0_root|body_C0_root|spine_C0_root|spine_C0_spineBase|spine_C0_spineTop|spine_C0_chest|shoulder_L0_root
Get options
Get controllers
Get components
shoulder_L0 (EPIC_shoulder_01)
Find recursive in [ 0:00:00.017584 ]
Get parenting for: shoulder_L0
Get parenting for: shoulder_L0
Guide loaded from hierarchy in [ 0:00:00.024090 ]
Checking guide
Get options
Get controllers
Get components
arm_L0 (EPIC_arm_02)
Find recursive in [ 0:00:00.021019 ]
Get parenting for: shoulder_L0
Get parenting for: shoulder_L0
Get parenting for: arm_L0
Guide loaded from hierarchy in [ 0:00:00.029531 ]
= BUILDING RIG ==============================================
Initial Hierarchy
Init : shoulder_L0 (EPIC_shoulder_01)
Init : shoulder_L0 (EPIC_shoulder_01)
Init : arm_L0 (EPIC_arm_02)
Objects : shoulder_L0 (EPIC_shoulder_01)
Objects : arm_L0 (EPIC_arm_02)
Properties : shoulder_L0 (EPIC_shoulder_01)
Properties : arm_L0 (EPIC_arm_02)
Operators : shoulder_L0 (EPIC_shoulder_01)
Operators : arm_L0 (EPIC_arm_02)
Connect : shoulder_L0 (EPIC_shoulder_01)
Connect : arm_L0 (EPIC_arm_02)
Joints : shoulder_L0 (EPIC_shoulder_01)
Joints : arm_L0 (EPIC_arm_02)
Finalize : shoulder_L0 (EPIC_shoulder_01)
Finalize : arm_L0 (EPIC_arm_02)
Finalize
Cleaning jnt org
Creating groups
dagPose1
= SHIFTER BUILD RIG DONE ================ [ 0:00:00.783994 ] =======
Yes a pole vector could be a solution, but guide placement would be more demanding if we use it. What about a limb oriented from a specific plane, but pole vector is outside of this plane ? How should be controls and joints orients ? I don’t have the anwser.
But I guess for a straight limb it could / should work without any extra guide in this case🤔
You said it would infinite freeze. Was “infinite” an exaggeration? 
At the moment, the limbs are built on the assumption of a slight bend so the pole vector can be calculated. So a straight limb is indeterminate without something extra to define it. So I disagree that it could or should. Any assumption about default planes will disappoint people using a different plane.
If you have strong ideas about wanting different joint orientation than the pole vector plane, you’ll likely find it rewarding to make your own custom components. Cloning and modifying existing ones is all I ever did.
It wasn’t an exaggeration, the result I’ve sent is thrown when it works. Otherwise Maya freeze and I can’t do anything except killing the process from task manager. I will take a look further why it crashes on the other setup I have.
About the straight limb, when a plane is found, we’re sure there is a up vector and a forward vector. Why not using it to orient joints when the plane cannot be found ? I mean, if there is a zero division somewhere, we can run an exception where the plane is created from up and forward axis. Of course I could create my own guide, I’m just suggesting an idea because I had a crash when creating straight limbs. There is no big issue 
Hello @chrislesage !
Just to follow up my suggestion, i’ve found a solution.
In mgear > core > vector.py, we can replace
def getPlaneNormal(v0, v1, v2):
vector0 = v1 - v0
vector1 = v2 - v0
vector0.normalize()
vector1.normalize()
normal = vector1 ^ vector0
normal.normalize()
return normal
by :
def getPlaneNormal(v0, v1, v2):
vector0 = v1 - v0
vector1 = v2 - v0
vector0.normalize()
vector1.normalize()
if vector0.isParallel(vector1):
normal = vector0 ^ datatypes.Vector(0, 0, -1)
else:
normal = vector1 ^ vector0
normal.normalize()
return normal
That way, if the two vectors (generated from the 3 positions) are parallel, we can determine arbitrary a normal vector so joints will be aligned, at least.
Note : up vector is based on world up vector here. If we want to improve the precision, we could add a parameter like fallback_vector that is given from the guide axis. With that, whatever the situation, joints will be aligned from the guide orientation only if they’re parallel, instead of being broken.
That might solve the problem, but the second part of the solution would need many refactor for a tiny problem. I guess the first part could at least reduce the impact of the bug.
Very cool, thanks!
Would you be willing/able to submit that as a PR on Github? Miquel can review it, but it seems like a pretty reasonable improvement. And maybe in the future include the 2nd stage with vector parameters, like you mentioned, or a guide object, etc.
Sure ! Thanks to you too 
I did a pull request here
I’m quite a novice with github, but I hope it is enough for Miquel to merge it !
Hi @remicc
Thanks for this and the PR! 
but I don’t see it on the PR list on mGear repo 
Can you confirm if has been summited correctly?
If not I can just copy paste from your repo 
You’re welcome !
Sorry I’m not familiar with github, but I guess you can see the real PR here
Yup! the PR arrived correctly Thanks!