Python in Maya #2: list comprehension, izip, ...

Examples for:
  • List comprehension
  • List slicing
  • Iterate over strings
  • izip (zip iterator)

1. Basic example

transform parent / child association

from itertools import izip

import pymel.core as pm

# 1. PyMEL + list comprehension
transforms = ['joint1', 'joint2', 'joint3', 'joint4']
# convert strings to PyNodes
transforms = [pm.PyNode(transform) for transform in transforms]
# create list of parents
parents = [transform.getParent() for transform in transforms]
for parent, child in izip(parents, transforms):
    print('%s > %s' % (parent, child))
# None > joint1
# joint1 > joint2
# joint2 > joint3
# joint3 > joint4

# 2. Strings + list slicing
transforms = ['joint1', 'joint2', 'joint3', 'joint4']
for parent, child in izip(transforms[:-1], transforms[1:]):
    print('%s > %s' % (parent, child))
# joint1 > joint2
# joint2 > joint3
# joint3 > joint4

2. Bad example (Thanks to Viktoras Makauskas for pointing it out)

Essential attribute connections for 
transform driver, driven relationship.

import pymel.core as pm
driver, driven = pm.ls(sl=1, type='transform')

# 1. list comprehension 
for attribute in [at+axis for at in 'trs' for axis in 'xyz']+['ro']:
    driver.attr(attribute) >> driven.attr(attribute)

# 2. constant is better here, because it is:
#    - more readable
#    - almost same character count
transform_attributes = ['tx', 'ty', 'tz', 'rx', 'ry', 'rz', 'sx', 'sy', 'sz', 'ro']
for attribute in transform_attributes:
    driver.attr(attribute) >> driven.attr(attribute)

2016-03-06: updated


Python in Maya #1: Decorators

Two examples of simple Python decorators for Maya. There are many resources online that explain decorators, so I don't want to add yet another one. I just want to demonstrate their usefulness to Maya coders that are not using them yet.

1. Preserve Maya selection (maya.cmds)

Some Maya commands automatically modify the selection. 
This is often unwanted behavior. 
Sometimes there is a flag to disable that behavior. 
Other times it is possible to avoid those commands. 
But if neither is an option (or you don't want to worry about it) 
this decorator will always disable it.

from functools import wraps
import maya.cmds as mc

def preserve_selection(func):
    """prevent Maya selection changes"""

    def wrapper(*args, **kwargs):
        selection = mc.ls(orderedSelection=True)
        result = func(*args, **kwargs)
        for each in selection:
            if mc.objExists(each):
                mc.select(each, add=True)
        return result

    return wrapper

def create_cube():
    return mc.polyCube()

# cube was not selected on creation

2. Run in "Settings > Working Units > Linear > centimeter" (PyMEL)

Some commands do not run properly in scene working units other 
than the default centimeter. This decorator is a simple 
workaround for that problem, by temporarily setting it to 
centimeter for the duration of the wrapped function/method.

from functools import wraps
import pymel.core as pm

def working_unit_linear_cm(func):
    """temporarily set working unit to cm"""

    def wrapper(*args, **kwargs):
        scene_unit = pm.currentUnit(q=1, l=1)
        if scene_unit != 'cm':
            result = func(*args, **kwargs)
            if scene_unit != 'cm':
        return result

    return wrapper

def snap_vertex(driven_vertex, driver_vertex):
    driven_vertex = pm.PyNode(driven_vertex)
    driver_vertex = pm.PyNode(driver_vertex)

snap_vertex('pCube1.vtx[2]', 'pCube1.vtx[3]')
# snapped properly with non 'cm' scene_unit


  • Both examples show the good practice of using the optional, standard library, convenience function functools.wraps to not lose/overwrite the wrapped functions func.__name__, func.__doc__, ... docs: https://docs.python.org/2/library/functools.html#functools.wraps
  • Theoretically both examples would be good cases for context managers. But practically it does not seem like a good fit to me: 1. preserve_selection: You should never write scripts that rely on selection changes during their execution (macro style copy/paste code vs proper programming). 2. Working units only ever make problems when they are something other than cm (in my experience).
  • 2017-01-31: preserve_selection now works when a selected object gets deleted


Harald rig breakdown

Harald rig breakdown from Parzival Roethlein on Vimeo.

In 2011 I worked on my last student short at Filmakademie called Harald: https://www.facebook.com/haraldfilm

I was responsible for the main character rigs (including blendshape and some meshflow modeling), animation scripts/support and animated one shot.

Final meshflow

At first I updated my PyMEL autorigger from 2010 and rigged the bodies with it. Both spine and the bendy limbs are modified ribbon setups (see older post: Joint chain rigging techniques). There are no (corrective-) blendshapes for the body, only skinning.
The faces use a standard blendshape + joint combination to match the expression sheet and allow for customization. Reverse wrap deformer for eye bulge in eyelid. Eyelid joints sliding on geometry. Rig performance had some priority and the finished rig showing the final deformation (one subdivision level) ran at over 20 fps.

I created some animation scripts for the project Maya shelf including a UI (first time using Qt) requested by the animators, which was supposed to be similar to the one they used in a previous Filmakademie short: Der Besuch

And finally I animated one shot because I always wanted to do that, even thou I am not an animator. My previous experience was very limited, so I had to learn most animation principles for the first time and it certainly was a fun exercise to use my own rigs.


BabyDragon walkcycle rig breakdown

Baby Dragon walkcycle rig breakdown from Parzival Roethlein on Vimeo.

This is a personal project from early 2013.
When I saw a turntable of the dragon on Vimeo (https://vimeo.com/52581835), I contacted the modeler if it would be possible for me to rig it. And since he liked the idea I did it in my spare time over a few months (there were many breaks), and after that was done a co-worker / fellow student from Filmakademie did the animation.

For the neck / spine / tail I used the curve/up-curve setup, described in an older post of mine, with one joint for each spike:
Joint chain rigging techniques

Modeller/Surfacing: Angel Navarro angelnavarroart.com/
Character TD: Parzival Roethlein
Animator: Alexander Dietrich cargocollective.com/alexanderdietrich

Unrelated to this post, I recently updated an older post:
Maya naming conventions


Harald Trailer

Here is the trailer for the last student short I worked on at Filmakademie. I was the Character/Animation TD and animated one shot.

Facebook page for the short:

It recently got the SIGGRAPH 2013 Best Student Runners-Up award, yay!
The Best Student award also went to a Filmakademie project called Rollin' Safari, all clips are online at: http://www.youtube.com/user/rollinsafari/videos


Maya wrap deformer tips

  • After creating a wrap deformer the driver surface gets a dropoff and smoothness attribute. Usually the user can expect these attributes to be in the deformer ChannelBox/AttributeEditor. This has been changed for the wrap deformer for a case were there is one driver on multiple shapes, so the smoothness attribute gets connected to each wrap deformer. The smoothness only works with Falloff Mode: Volume and Exclusive Bind: off. As the name says it can help create smooth deformations. On the downside it moves unaffected neighbors of deformed vertices in the opposite direction, so that may be a reason not to use smoothness for some cases.
  • When enabled Exclusive Bind improves performance a lot, but may lead to bad deformation. Works especially well when driver and driven have a similar resolution. I used this setting a lot in the past.
  • I usually use Falloff Mode: Surface for smooth results, probably because my driver and driven object usually have a similar shape. The smoothness attribute requires Volume mode thou.
  • maxDistance 0.0 disables maxDistance
Use cases:
  • Deform highres geometry with easier to rig/cloth-simulate low-res geometry. For this case my tip is to output the lowres mesh into a separate mesh node and smooth/subdivide that and then use this highres version of the lowres mesh as wrap deformer driver on the actual highres mesh. The result is surprisingly fast when using exclusive bind etc and allows for much better deformation than using the wrap deformer the normal way and trying to adjust the wrap deformer attributes, which can never work properly (it's a non-barycentric binding) and gets really slow. As with many deformers in Maya, they are not very functional, but they are fast, so when making these procedural deformations you can compensate for the lack of features.
  • When the driving mesh just has a skinCluster I prefer to copy the skinCluster and weights to the highres, because it calculates faster than a wrap deformer and you also have the option of tweaking the weights further.
  • Use as partial blendshape, to be able to work on local area and with those patches drive the final one-piece mesh. Edit membership has to be used to avoid double transformation. Not a user friendly workflow. Exclusive Bind can be used to greatly improve speed (if meshflow is similar).


Kool-Aid commercial: Rig breakdown

Kool-Aid commercial: Rig breakdown from Parzival Roethlein on Vimeo.

The complete spots:

The node order of the face, starting with the low resolution geometry:
-> blendShape
 -> skinCluster (for the mouth I put the joints on a curve with motion paths, to tweak the curve cvs without getting intersecting loops, see old post: Joint chain rigging techniques)
 -> bend deformer (To roughly match the body shape. Works for this range of motion, for more range I would recommend using a surface constraint / rivet on the nurbs surface and connect translation to UV values)
[lowres for animators]
 -> smooth (subdivide)
 -> sculpt deformer (project on nurbs surface with the same shape as the glass)
[highres, final shape]

And the highres geometry was used as a mask in compositing.


Adventure Time - A Glitch is a Glitch

Yesterday aired the Adventure Time episode "A Glitch is a Glitch" (AT S5E15 AGIAG).
It was a special 3D episode (usually the show is 2D) and directed by David OReilly.
The rigging was done by Mark Feller and me at Studio Soi in July 2012. My main responsibility were the faces and spines. The faces were made by hand, some parts I could import and adjust after the first one was done. The mouth joints were sliding on a nurbs surface, that had the shape of the face polygons. For the spines I wrote a script (ribbon based. See older post: Joint chain rigging techniques).

This is a clip from the episode:


Maya Naming Conventions

(updated on 2014-09-10)


  • L_arm_1_upper_joint  >  L_arm_2_lower_joint
  • Prefix = Region: Side ("L_..." / "R_..." / none for center) + region ("...arm_", "spine_", ...)
  • Middle = Hierarchy numbering starting at 1 (not 0) followed by descriptive string ("...1_upper...", "...2_lower...")
  • Suffix = Nodetype: Default Maya nodenames ("..._blendColors", "..._multiplyDivide", ...)


This is a simple naming convention that currently seems the most logical to me, after having used different ones of myself and coworkers in the past. The main goals are:
  1. Readability (from the name know what it is and where it is used. But not too long)
  2. Simplicity (easy to learn, avoid confusion, hard to make mistakes, few exceptions)
  3. Functionality (easy to work with: string search / filter)

Prefix = Region ("L_arm_...", "spine_...")

If a region is in the center and/or only appears once start with it "spine_...", "head_...". Else insert side shortcut before region "L_...", "R_..." ("L_arm_...", "R_leg_..."). Reasons:
  • For regions that appear multiple times (L_arm, R_arm, ...) all related nodes will have unique names, just by adding the side prefix
  • Abbrevation to save reading time and space. If a name is too long for a Maya UI element (ChannelBox, graph editor, ...) the name usually (always?) gets cut of at the right side. So having a short prefix delays that. Opposed to using the more descriptive, but longer versions "Left_"/"Right_" or "Lf_"/"Rt_".
  • This is a "special rule" (anti readability and simplicity), but it is such a simple one and used so frequently that is hard to use wrong or forget.

Middle = Hierarchy ("...1_upper...", "...2_lower...")

  • Start with number, counting in the cranial (spine) / distal (limbs, fingers) / lateral (clavicle) direction, to allow for alphabetic ordering, which can be useful in the paint skin weights tool for example. For most people it is more intuitive to start counting at 1. Opposed to loop variables usually starting at 0 (Python: for x in range(..)).
  • Followed by a string description to understand where the element actually is (readability). This string could be standardized, but this post is about a simple naming convention. 
  • Going from general to detail is easy to read and helps with isolating regions for string search / filter ("L_hand_2_index*"). 
  • All this also helps to have unique transform node names. Which can have the same name, if they are not in the same hierarchy level. Opposed to "pure" DG (dependency graph) nodes (multiplyDivide, skinCluster,...).
L_arm_1_upper_... > L_arm_2_lower_... > L_arm_3_wrist_...
L_hand_1_thumb_1_metacarpal_... > ...
L_hand_2_index_1_metacarpal_... > L_hand_2_index_2_phalanxProximal_... > L_hand_2_index_3_phalanxIntermediate_... > L_hand_2_index_4_phalanxDistal_...

Suffix = Nodetype ("..._multiplyDivide", "..._locator")

The nodetype is usually the suffix. Theoretical that should not be necessary, since command searching allows for a type filter (pm.ls('L_arm*', type='joint')). But when manually working in a scene it helps to read graphs / history and it also helps at having unique names.

Usually it is also shortened to 2-3 letters, which I used to do as well (joint = jn/jnt, blendColors = bc, multiplyDivide = md). But after changing my "rules" over the years and using different ones at companies I suddenly wondered what the purpose of these abbrevations even is. Since they always introduce special rules, exceptions and may not even be readable from an outsider.

So my conclusion was to just use the full default Maya node names / types as suffix:
"..._blendColors", "..._multiplyDivide".
In the beginning, when more nodes were created manually, it might have been more convenient to only type a few letters as suffix. But by now most are generated with scripts anyway.  And even when working manually and following this rule the default Maya behavior will generate the suffix by default (minus the 1 at the end).
But more importantly this rule creates unique, easy to learn, obvious suffixes for almost all nodes. There are a few exceptions, but even their solution are partly given from Maya. So they always make sense to Maya users.

Exceptions - from Maya:
  • Default transforms will get different names in Maya, depending on how they got created: null1 (empty group), group1 (group for transforms), transform1 (actual node name). Most people call default transforms (no shape / special function) groups, so I stick with group as well. To prevent hard to read suffixes when using stacked groups ("..._group_group_group") I like to use descriptive names ("..._null_group", "..._sdk_group", "..._space_group").
  • Transforms with shapes get names from the shape nodeTypes (locator1, annotation1, ...). So Maya already gave an answer how to name those transforms. Shapes themselves will get the Shape suffix.
  • Transform Handles (deformer handles) get named: "nodetypeXHandle" in Maya. So I also use this convention, except for the number in between, so it's only "deformertypeHandle". Example: L_cheek_clusterHandle (cluster itself: L_cheek_cluster)
  • ... (probably more)

Exceptions - from user:
  • Animation transforms: Usually transforms are the only nodes animators are exposed to. That's why they often get named differently. For this convention I prefer "_control" over "_nurbsCurve".
  • ... (probably more)


# python code
import pymel.core as pm
# prefix given from script / autorig
myPrefix = 'L_arm_'
# ...
myJoint = pm.createNode('joint')
myJoint.rename( myPrefix+'1_upper_'+myJoint.type() )
# I recommend using a default function that will
# also check for the special cases (shape child, 
# handle). So the user only has to input the
# middle / hierarchy section ("1_upper"), if you
# are in a class that knows about it's prefix