Enabling/Disabling Markers Automatically

Help
1

Hello!

I have a rig that is bound to several character meshes at once; they all use the same core joints (pelvis, spine, head, etc) but have several unique feature controls (hair, ears, tails etc) that get turned off/on via an enum on the world control. I’ve set up one big ragdoll for the rig, enabling/disabling character-unique markers via the world control enum- I’m using SDKs to set the ‘enabled’ marker channel. However the enabled channel does not always update when I change the enum; the enabled channel will say 0, but the marker is still visible and colliding with other objects. It’s especially bad when the rig is referenced in. I’ve found that they’ll update after I open the rMarker settings in the channel box, but to do that for every marker every time I want to switch characters is very time-consuming.
Is there a better way to set up automatic enable/disable?

I’m also interested in the LOD channel in the rMarker settings- is this a potential way to have one marker with multiple meshes? Or possibly a better way to enable/disable markers?

Thanks!

2

Sorry for the delay on this one, we’ve seen it and one of us will tend to this first thing tomorrow morning.

1 Like
3

Hi @Hallie, I’ve had a look at this and it’s true; the Enabled attribute does not respect changes happening via a connection, only changes made by directly editing the attribute.

This is an oversight, as we did not expect this attribute to be connected, which typically means animated, which this attribute cannot be. But wiring things together with higher level logic is a solid usecase.

This can’t be addressed without a change to the software, so you’ll need a workaround. Something that involves directly setting the Enabled attribute.

So how about this:

from maya import cmds

# Something to set the Enabled attribute directly
def script():
    value = cmds.getAttr(attr)

    for marker in cmds.ls(type="rdMarker"):
        cmds.setAttr(marker + ".enabled", value)

# An attribute to monitor, e.g. the same one driving your SDKs
attr = "head_jnt_rPin.visibility"

# A script job to trigger our script when this attribute changes
job_id = cmds.scriptJob(attributeChange=[attr, script])

# Do delete it, run this
#cmds.scriptJob(kill=job_id, force=True)

With this, you could monitor an attribute on your high-level controller, and within the script iterate over connected Markers - similar to what the SDKs would do - and set the Enabled attribute for those Markers.

Finally, to have this script job always be available when using this rig, you could put the above into a script node set to Script Type: Open/Close.

Hope it helps, we’ll look into making this attribute able to respond to connections for the next release.

4

Thanks so much!! This was extremely helpful, and works perfectly. Luckily we’re not looking to actually set keys on the enabled attribute, so I didn’t need to worry about that; we just needed the markers to update instantly.

For anyone else looking to do this, here’s what I did:

  1. Create a Script node with Source Type Python and Script Type GUI Open/Close (I found GUI to be better for my situation because I needed the script to fire whenever the scene itself is opened/closed, not the whole of maya).

  2. In the Before section of the script node, I imported my python script and ran my ‘create script job’ function, which takes three parameters: the file name (for checking and adding reference namespaces to control and rMarker names), the watched object.attribute, and a dictionary of the rMarker names as keys, the enum value they’re enabled on as keyvalue. Being able to pass these custom parameters to the script allowed me to reuse the code for all the rigs that needed this.

  3. Script job gets made that triggers every time the object.attribute I inputted is changed. The scriptjob script looks at the value of the watched attribute, and changes all the rMarker enabled values based on that value.

  4. In the After section of the script node, I called my ‘kill scriptjob’ function.

Super simple!! Thanks for your help!

1 Like
5

Another question occurs to me however: Does the same apply for enabling/disabling the rSolver itself, and rGround? Should I connect those via a script as well, or will direct connection work in that case?

6

Every node would have this limitation, except for the solver as it’s a special case.

1 Like