Home Website Youtube GitHub

Leg_3jnt_01 upV Ref Array - unwanted world_ctl? 3.2.0

Testing out mgear. 3.2.0. What an amazing tool!

I seem to have an issue with the leg_3jnt_01 adding world_ctl to the upVref constraint array upon build without me asking it to. Wouldn’t be a big deal, but it messes up the order that the condition nodes plug into the upV_constraint, making the enum attribute entries for upVref switching have an offset, and not being able to switch to the last array entry. See attached image.

I’ve tried the base quadruped template, and a more basic shifter rig with just less components. I also tried mgear 3.1.1 and 2.6.1 and seem to get the same problem.

Anyone else getting this issue, or have I missed something? If it’s a bug, I’ll probably set up a post-build step to remap the condition plugs going into the constraint, ignoring the world_ctl.

Yes!! I noticed this, made a post process script to fix it, and then forgot to log the bug!

This is a bug, and since at least 2.6 I think too.

In the meantime, here is the script I wrote to fix it:

import pymel.core as pm
import mgear.shifter.custom_step as cstp


class CustomShifterStep(cstp.customShifterMainStep):
    def __init__(self):
        self.name = "fix_leg_polevector_index"


    def run(self, stepDict):
        for side in 'LR':
            self.fix_polevector_index(side)

        return

    def fix_polevector_index(self, side):
        '''
        Here is a hack! There is a problem in the leg module, where it adds "Global"
        automatically to the leg pole vector spaces. So the indeces after Global are
        shifted incorrectly. This reorders the indeces in the condition nodes that drive it.
        This is a brittle fix. It depends on the bug existing and being in the correct order... :(
        '''
        # if leg_L1 exists, it is a quadruped, so do all 4 limbs. Otherwise just the leg_L0 ones.
        if pm.objExists('leg_L1_upv_ctl'):
            limbs = [0, 1]
        else:
            limbs = [0]
        for limb in limbs:
            poleControl = pm.PyNode('leg_{}{}_upv_ctl'.format(side, limb))
            poleConstraint = list(set(poleControl.getParent().inputs(type='constraint')))[0]
            conditionInputs= poleConstraint.inputs(type='condition')

            counter = 0.0
            for i, each in enumerate(conditionInputs):
                if 'world' in each.outputs(plugs=True)[0].name():
                    each.secondTerm.set(len(conditionInputs))
                else:
                    each.secondTerm.set(counter)
                    counter += 1.0

1 Like

Thanks for that Chris. I’ve made a slight adjustment for what must be a naming change on the newer Leg_3jnt control names, if anyone else has the same issue. Worked a charm!

import maya.cmds as cmds
import mgear.shifter.custom_step as cstp
import fnmatch
import pymel.core as pm


class CustomShifterStep(cstp.customShifterMainStep):
	def __init__(self):
		self.name = "post"


	def run(self, stepDict):

		for side in 'LR':
			self.fix_polevector_index(side)

		return

	def fix_polevector_index(self, side):
		'''
		Here is a hack! There is a problem in the leg module, where it adds "Global"
		automatically to the leg pole vector spaces. So the indeces after Global are
		shifted incorrectly. This reorders the indeces in the condition nodes that drive it.
		This is a brittle fix. It depends on the bug existing and being in the correct order... :(
		'''
		# Only works for quadruped
		limbs = ['Front', 'Back']
		
		for limb in limbs:
			try:
				poleControl = pm.PyNode('leg{}_{}0_upv_ctl'.format(limb, side))
				poleConstraint = list(set(poleControl.getParent().inputs(type='constraint')))[0]
				conditionInputs= poleConstraint.inputs(type='condition')
	
				counter = 0.0
				for i, each in enumerate(conditionInputs):
					if 'world' in each.outputs(plugs=True)[0].name():
						each.secondTerm.set(len(conditionInputs))
					else:
						each.secondTerm.set(counter)
						counter += 1.0
			
			except:
				print 'Single sided rig?'
				pass
2 Likes

Hello! This bug is still happening in latest mGear version, any plans to get a proper component fix?
Cheers.

I ran into this too and my current solution is to remove the backwards compatability check in the connectRef function in component/init .py

The unvalidated list seems to be introducing the extra node into the constraint list thats throwing the target order out of sync with the driving enum attr. Though I’m not entirely sure why. It just needs to be ref_names = self.get_valid_ref_list(refArray.split(","))

It’s a bit of a hack though, needs a proper fix

I have added this thread as a reference for this ticket to improve this component

2 Likes

Has been a long wait but, I just fixed upv index bug today :slight_smile:
Since it was affecting more components, I created a new ticket for it

5 Likes