Best Practices for Setting Up a Scalable Rigging Pipeline for a Small Studio

, , , ,
1

Hi everyone,

I’m currently working as a technical artist for a small but growing animation studio, and we’re at a point where we really need to streamline our rigging pipeline. We’ve mostly been handling rigs manually in Maya up to this point, but as our project scope is expanding and we’re onboarding more animators, the need for a more scalable and modular solution is becoming critical.

I’m hoping to get some input from others who have either gone through this process or are in the midst of building something similar. Specifically, I’m curious about:

  • What tools or frameworks (e.g., mGear, PyMel, custom scripts) did you find most helpful when setting up a rigging pipeline?
  • How do you manage version control and updates to rigs, especially when multiple people are working on the same character assets?
  • Are there any common mistakes or pitfalls we should be aware of when moving from a manual to a more automated rigging setup?
  • Lastly, what’s your approach to naming conventions and organization so that TDs and animators can work more fluidly across departments?

I’d really appreciate any insights, resources, or even anecdotes about what worked (or didn’t work) for your teams. Feel free to drop screenshots, examples, or links to helpful for ansible training documentation as well.

Thanks in advance.

1 Like
2
  • mGear is always a good starting point for a growing studio, and it’s widely used enough that there’s decent community support for it too
  • Version control depends how you’re versioning the rest of your assets - if you already have an asset system to track models, animations, lighting setups etc, you should extend it to also include rigs (and if you aren’t versioning those things, you probably should).
    • If you mean multiple people working on the same rigs, not just models and textures, it gets difficult - you’d need to either break up the rig into separate components/layers, or export weight and control data separately to the build logic, or do something more flashy where everyone sees a live-updated version of the latest build script / rig build UI, as they submit changes to it. Maybe a bit excessive for a small studio
  • Big pitfall is trying to do too much at once - I’d say before trying to do anything complicated with an automated rigger, aim to be able to run a model update automatically (even a simple one, with same topology, UVs etc). That’s a big step up in efficiency
  • Naming conventions aren’t so important as long as they’re consistent - I picked up a useful habit of suffixes, so “_CTL” for animation controls, “_PLY” for techmesh polygons that won’t be rendered, “_GEO” for poly meshes appearing in final render etc.
    • Prefix “L_”, “R_”, “C_” for different sides of the character
    • In general the most important thing is instilling the right mindset in your artists - get your modellers to understand not to change mesh names or topology if they don’t have to, get animators used to updating / rebuilding their scenes with new rig versions. It doesn’t always feel natural if they haven’t worked in a more technical environment before
1 Like
3

What tools or frameworks (e.g., mGear, PyMel, custom scripts) did you find most helpful when setting up a rigging pipeline?

We use custom scripts for the most part. In the past we made heavy use of PyMel, but now that pymel is no longer a guaranteed install, we are converting our pymel to maya.cmds. For data heavy operations like managing skin weights on dense meshes, open Maya api 2.0 is preferable, but has a steeper learning curve. At the heart of any Maya rigging pipeline you will find cmds.ls(), cmds.setAttr(), .getAttr(), .listAttr, .connectAttr() and .listConnections(), and cmds.file(). they need to be well understood. For 3rd party packages, most studios consider NGSkintools mandatory. We also have in house libraries with ui widgets for various rigging tasks:

  • a control builder to make nurbs shapes( and buffers/null groups) aligned to a selected node.
  • Skin tools that copy weights between selected meshes/verts/faces/, automate the process of updating a skinned mesh (import new, copy weights from old, cleanup names )
  • Rig building tools that create consistent IKFK limbs, spines, faces, stretchy chains, etc.
  • Tools for mirroring systems (left arm to right arm, etc)
  • we have explicit publish tools for handing off our rigs for production

How do you manage version control and updates to rigs, especially when multiple people are working on the same character assets?

We use perforce, I’ve also used SVN in the past. We script automated checkout/submit when you use a “publish” tool to handoff assets to another dept. Between modeling, rigging, and animation depts we have a defined and tooled up handoff step, with clear deliverable expectations, and validation tools to check that those expectations are met.
If a rig has to pass between riggers, the key is having a consistent approach. Rig building tools are necessary in this regard. For animation, we use Maya’s referencing, so any rig updates get passed to animators for free. The Some rig updates modify joints and will break existing animations, so we have batch re-export tools for those cases.

Are there any common mistakes or pitfalls we should be aware of when moving from a manual to a more automated rigging setup?

The overwhelming need is flexibility. You need systems and code that don’t meet change with fragility or friction. What this looks like practically is hard to say concisely because it is very situational.
I’ll just share some thoughts

  • You’ll want to pursue a modular, procedural rigging approach. [Modular Procedural Rigging]
  • you should be able to destroy and rebuild a rig with a button press (or two)
  • separate the control hierarchy from the joint deformer hierarchy, the skinning from the rigging.
  • in code, be wary of thoughtlessly applying OOP. Try to keep functions that parse/modify Maya outside of classes that hold data.
  • develop a system for exporting and copying skin weights across meshes- many meshes to one and one to many. Identify situations that force you to repaint weights and ask if there is a better solution. You want the labor intensive part of weighting to be saved / copied / reapplied as much as possible.

Lastly, what’s your approach to naming conventions and organization so that TDs and animators can work more fluidly across departments?

  • any name convention is good as long as it is actually followed.
  • prefixes and suffixes are easier to code around than tokens in the middle
  • Tools that name things help.
  • Attributes on meshes and nodes are better for identifying “roles” in the process