Up to date documentation and plugins dependency

[Nix]

Hi!

I was delaying checking mGear out for far too long and after finally trying it out gotta say I’m quite amazed with the latest version! So many cool things both for riggers and animators. But I do have a couple of questions.

First one is general one, I’m a bit confused as to where should I look for documentation on the frontend tools? Most of it seems to either be out of date or state that it’s WIP and point to YouTube channel which also does not cover everything or covers older versions. Is there no written up to date documentation for people who are just getting into mGear and were not following it from the start? I’m not talking about rigging beginner stuff here, just mGear docs telling about the general workflow, how it operates, which tools do what, how to connect modules (i’ve poked around and seen at least 2 ways of doing it, through direct parenting of blueprints and through specifying “Host” it is called I believe? Would’ve figured it out a lot faster if it was in docs)

And second one is - I see that there are some precompiled plugins and nodes, and this is a bit of a concern for me. I usually prefer to not use precompiled plugins or at least not require animators to have them. It makes a lot of thing easier, especially when working with outsource studios. And I’m also always concerned about support for new Maya versions, which is less of a concern with mGear, it being FOSS MIT and all, but still.

Are those required by every rig, or just some modules? Is there any indication of which module requires plugins? Or is there any way to make plugin-free rigs?

Thanks!

[chrislesage]

Hi Nix,

Yeah, there is no complete written documentation for the workflow. It’s definitely something that would be wonderful to have. I started writing an overview, and I got busy in production and I haven’t updated it in over a year. And now I’m 2 to 4 mGear releases behind!

The compiled plugins are currently required. Miquel has mentioned an intent to port the Shifter components to not rely on them. For now, they do.

For “connecting modules”, I assume you are talking about Shifter components (arms, legs, spine, control_01, etc). To be clear, it’s better to call them components, because when you refer to “modules” it sounds like you are talking about Python scripts.

In general, yes connecting things is done by parenting.

Some components, like the arms, have extra attributes in the guide, like “Connector”, which lets you choose “shoulder_01” or “Standard”. I don’t actually know, but I’m assuming Standard would revert to using the parent.

The Host (or UI Host) is any shifter component that all the switch attributes for a component are going to be put on. So for example, in the Biped Template, it uses a control_01 component named “armUI_L0_root” that node is the “Host” setting for the arm. All the arm IK/FK switches, stretch attributes, etc. will end up on a control “armUI_L0_ctl” when the rig builds.

In the component settings of the guide, you also have “IK Reference Array” which is basically a space switch. On the arm component, there are 3:

1. “IK Reference Array” = the space switch for the IK control
2. “UpV Reference Array” = the space switch for the pole vector control
3. “Pin Elbow Reference Array” = controls that the elbow can be pinned to for elbow locking.

After you build your rig, on your Host control, you’ll end up with a drop-down list of space switches that correspond to what you entered. They will say “master_C0_root” for example, but that is just the component root. It will actually follow “master_C0_ctl” in my example.

One other tip from one of Miquel’s videos: It is better not to parent your UI Host nodes under the actual component that it will be switching. For example, don’t put your armUI control underneath the arm. Otherwise, when you switch your IK/FK arm, it will cause extra evaluation cycles, and slow down the rig. Parenting the UI Host nodes under the COG or the world control instead, can save your rig 10 to 15 FPS!

(By default the biped template does have those nodes parented under the hands and feet.)

[Nix]

Thanks a lot for your reply! This clears things up a bit. Yes I was referring to components, forgot how they are called in mGear and did not have Maya at hand at the time of writing it.

Well, I guess I will keep playing around with it, but plugin requirement for the finalized rig is a bummer. Though I understand that custom nodes open a lot of new possibilities and performance improvements.

[Aerys]

Plugin nodes are such a tiny ask imo, copy paste a few files into your Maya folder and you’re good to go.