Home Website Youtube GitHub

Tips for customizing mGear

Support
#1

Hey everyone,

Edit: here is a WIP document of how I am learning and implementing mGear on our studio’s film. I hope it can help beginners learn how to begin with mGear: https://rigmarolestudio.com/mgear-rigging-workflow/

I’m on day 4 of implementing mGear for a film pipeline. I just started writing my own custom finger module where the parent joint aims towards the controls when you translate a finger control. So far so good! It’s a nice workflow!

Now I have a question before I get too deep into customizations. Does anyone have any tips for how to customize and extend the modules, without causing a giant mess when it is time to upgrade mGear? Do you handle it like a branch in git? Do you try to keep your own modules separate somehow?

I’m also going to want to redesign a lot of the control icons in the standard biped template. Should I do this by tweaking the code, or is it better to handle stuff like this by using “Post Custom Step”?

So far I have not found very many videos or tutorials that deal with the overall best practices and guidelines for working with mGear. (But I’ll keep watching. Some of the playlists are in reverse order, so maybe I’ll get to that last, hehe.)

Thanks!

2 Likes
#2

Oh great! I just came across the video for extracting and saving control icons, so that is cool.

Still wondering about tips for writing custom modules or making tweaks to existing modules, and staying in sync with new versions of mGear in the future.

#3

Hi @chrislesage,

I think the best option is to create a fork and do any modification in a branch. If you do things that other users can take advantage will be very cool if you can create a pull request with the changes so we can add it on the main branch.

If you are interested, We have a guide for contributing: https://github.com/mgear-dev/mgear_dist/blob/master/CONTRIBUTING.md

Also, let you know that mGear 3.0 will be released soon. We have changed many things in the structure so some refactoring of your components will be needed.

I will prepare a new beta today. But the documentation and video tutorial will take a little bit. Also the release log is not properly updated

For the moment you can check this projects in github. At less will give you a better grasp of what have been change:

Guides serializations: https://github.com/orgs/mgear-dev/projects/6
New structure and documentation: https://github.com/orgs/mgear-dev/projects/9
Misc updates: https://github.com/orgs/mgear-dev/projects/10 also this old project https://github.com/orgs/mgear-dev/projects/2

I wil post the beta in another thread so everybody can find it :slight_smile:

1 Like
#4

here is the beta: mGear 3.0 Beta 4

1 Like
#5

Great thanks Miquel, I’ll dig into this.

I’ll consider contributing, but I bet I’ll make a mess to begin with. I’ll likely have some “Getting Started” notes that I can post somewhere. I’m going to try to write a guide that gives all the context we need to understand how to start learning mGear. When I started last week, I didn’t have headphones at work yet, so Youtube really wasn’t working for me, and I was wishing for some text. I’ll see if I can help in that regard.

#6

I just learned that you should store custom modules under MGEAR_SHIFTER_COMPONENT_PATH, an environment variable pointing to a custom directory of your choosing. That was the question I meant to ask.

I’m trying to learn the context and best-practices of how to use mGear. Not to branch and develop it (yet). I’m watching every Youtube video in order, but it is taking a long time.

I wonder if it would be helpful to keep my notes in this thread for people who are also getting started? Again, I’m writing notes as I learn, and it will likely turn into something I can share (or possibly add to the documentation someday).

#7

Hi @chrislesage

for developer or final user?

Yes, you can also add custom path for synoptics “MGEAR_SYNOPTIC_PATH” and custom steps “MGEAR_SHIFTER_CUSTOMSTEP_PATH”

I am planning to add an interface and setting so is easier to manage, but since is not a priority I am posponing this.

That will be awesome. Also, this can be used in the future as part of the documentation :smiley:

Thanks,
Miquel

#8

I just posted a WIP draft of my pipeline document. It is still messy, and I’ll update it more as I go.

But for anyone interested, I am including a broad overview of how rigging in Shifter works. And an example of how I set up my pipeline directories for a feature film involving 33 characters.

Over time, I’ll improve this. I’m still learning mGear! And maybe some parts of it can be re-written to be included in the official documentation some day.

2 Likes
#9

Super nice post @chrislesage! Thanks!

I didn’t read all, but I will try to give you some feedback ASAP :slight_smile:

Thanks,
Miquel

1 Like
Tutorial rig Base
#10

New tip: How to access parts of the rig in your PRE and POST build scripts.

In the “Custom Steps” tab of your guide settings, you can access all your PRE and POST scripts. If you click “New”, it creates a Python file for you, and it includes some important boiler-plate code.

import mgear.maya.shifter.customStep as cstp

class CustomShifterStep(cstp.customShifterMainStep):
    def __init__(self):
        self.name = "name_of_script_here"
        self.charName = pm.PyNode('guide').rig_name.get()


    def run(self, stepDict):
        """Run method.
        [COMMENTS HERE]
        """

        return

Inside that class, there is something called stepDict, which stores a dictionary of all your steps. It also stores a “Rig” class where the class object of Shifter is stored.

You can access that by using:

stepDict['mgearRun']

If you go to scripts/mgear/maya/shifter/__init__.py you can find where that Rig(object) class gets defined. And you can see methods like Rig.initialHierarchy()

In that method, the top group for the rig is created and named according to the settings in your guide.

# Model
self.model = primitive.addTransformFromPos(
            None, self.options["rig_name"])

Note, that it is called “Model”, I think, because in Softimage XSI, top groups were stored in “namespaces” called Models. :slight_smile: But it is actually the rig top group.

So in your POST scripts, you can access that group by using:

stepDict['mgearRun'].model

Example 1, my character’s name is “billy” in the rig guide settings. I want the top group to be named “billy_Rig”

import pymel.core as pm

# get the name of the rig from the guide attribute
# I bet there is a way to query this with mGear, but I don't know it yet.
# this will return the string "billy" which is stored on my guide.
charName = pm.PyNode('guide').rig_name.get()
# Then rename the top group node on the rig
oModel = stepDict['mgearRun'].model
oModel.rename(charName + '_Rig')

Example 2, I want to parent the node “foo” underneath the top rig group:
This will really come in handy when you are preparing your hierarchy for publishing to your animators.

oModel = stepDict['mgearRun'].model
oFoo = pm.PyNode('foo')
pm.parent(oFoo, oModel)

Example 3: Hide the joints on the rig or change the other settings found on the top group.

oModel.jnt_vis.set(0)

I’ll post more if I find useful objects that we can find and query in the Rig class.

3 Likes
#11

Thanks @chrislesage this thread is getting better and better. I should linked in the documentation :smiley:

1 Like
#12

In one of the videos, Miquel adds some joint influences to a skinCluster, and then has to go into the paint weights tool to unlock the weights.

This was one of my least favourite parts of skinning in Maya. So here is a little script that fixes that. This unlocks all of the weight influences in all the skinClusters in your scene.

Obviously don’t run this if you meant for some influences to be locked. :slight_smile:

import pymel.core as pm

### Unlock ALL skin joints FFS! -_-

for oSkin in pm.ls(type='skinCluster'):
    skinJointList = pm.listConnections(oSkin.matrix, t='joint')
    for jnt in skinJointList:
        jnt.liw.set(0)
2 Likes
#13

[Write the list of PRE and POST scripts to a text file]

On our current film, we have about 75 characters. And one of the problems we just encountered is that a few of the characters had their POST scripts in the wrong order. For example, I was setting default values on attributes in one script, and then changing them afterwards in another. So they were not resetting to neutral properly. I had to open every single character to check. WHOOPS!

The list of POST scripts is inside guide.postCustomStep attribute, as a comma-separated string. So I just wrote this script, which exports the PRE and POST attributes from the guide, into a text file, so that I can easily check characters by reading these text files, without having to open every single Maya scene.

I add this in a PRE script which runs every time I build a character. If you use this, you’ll of course have to configure your own template path.

import pymel.core as pm
import os

def output_pre_post_scripts():
    ''' Export the pre and post script attributes to text files
    This is so I can easily debug the state of a character's scripts
    OUTPUT: split the PRE and POST lines and write them to text files.
    '''
    guide = pm.PyNode('guide')
    charName = guide.rig_name.get()

    basePath = r'Y:\10ave_Animation\Rigging'
    pathTemplate = r'data\characters\{}\configs\{}_scripts_{}.txt'
    prePath = os.path.join(basePath, pathTemplate.format(charName, 'pre', charName))
    postPath = os.path.join(basePath, pathTemplate.format(charName, 'post', charName))
    preText = guide.preCustomStep.get().split(',')
    postText = guide.postCustomStep.get().split(',')
    with open(prePath, "w") as myfile:
        myfile.write('\n'.join(preText))
    with open(postPath, "w") as myfile:
        myfile.write('\n'.join(postText))

output_pre_post_scripts()
3 Likes