A situation came up last week at work that was somewhat related to this issue. Another one of the TDs was in the process of writing a daemon script, and we needed a way of ensuring that all of our modules get updated automatically without re-starting the daemon every single time we commit a change.

I came up with a quick solution before leaving for the weekend, but I felt there was a better solution available. I decided to take on a small home project over the weekend to come up with a more robust solution. With a bit of playing around I came up with a recursive solution utilizing the inspect module that seems to be working pretty well, so I thought I’d share :).

recursiveReload.py:

'''
Created on 2012-02-25
 
@author: Mat
'''
 
import sys
import inspect
 
from distutils import sysconfig
from types import ModuleType
 
_processedModules = set()
_importedModules = set()
_remappingData = list()
 
class ImportRemapData(object):
 
    def __init__(
        self,
        destModuleName,
        destAttrName,
        sourceModuleName,
        sourceAttrName,
        attrType
        ):
 
        self._destModuleName = destModuleName
        self._destAttrName = destAttrName
        self._sourceModuleName = sourceModuleName
        self._sourceAttrName = sourceAttrName
        self._attrType = attrType
 
    def remap(self):
        '''
        This gets the new modules and assigns the new attr value to the
        attr name in the new destination module.
        '''
 
        #get the newly reloaded source module and then the new attr value
        sourceModule = sys.modules[self._sourceModuleName]
 
        #we need to get the new attr value as well
        newAttrVal = None
        #if the new attr val is a module, we need to get the module from sys
        if self._attrType == ModuleType:
            newAttrVal = sys.modules[self._sourceAttrName]
        #otherwise, just get it from the new source module
        else:
            newAttrVal = getattr(sourceModule, self._sourceAttrName)
 
        #get the newly reloaded destination module and set the new attr value
        destModule = sys.modules[self._destModuleName]
        setattr(destModule, self._destAttrName, newAttrVal)
 
def recursiveReload(module, debug=False):
 
    #get all of the data necessary for full reload of the module
    _getModuleData(module)
 
    #reload all of the collected modules
    for importedModule in _importedModules:
        if debug:
            print 'Reloading module: %s' % importedModule
        reload(importedModule)
 
    #now that the modules are all reloaded, re-map the extra data
    for remapData in _remappingData:
        remapData.remap()
 
    #clear our variables for future use
    _processedModules.clear()
    _importedModules.clear()
    del _remappingData[:]
 
    return True
 
def _getModuleData(module):
    '''
    Inspects the module and all of its sub-modules to get all imported modules
    and data required for us to re-map variables properly.
    '''
 
    #add this module to the list of processed modules so we do not try to
    #process it again and risk getting into an infinite loop
    _processedModules.add(module)
 
    #get all attr names from the module
    attrNames = dir(module)
 
    detectedModules = set()
    for attrName in attrNames:
 
        #get attr value and try to get the module where the value originated from
        attrVal = getattr(module, attrName)
        attrModule = inspect.getmodule(attrVal)
 
        #if we didn't get a module returned, we are dealing with a builtin, or
        #we are dealing with this module skip to the next loop iteration.
        #We need to do two checks for builtin modules, if it is in the builtin
        #module names and if it does not have a __file__ attr.
        if not attrModule \
        or attrModule.__name__ in sys.builtin_module_names \
        or not hasattr(attrModule, '__file__') \
        or attrModule == sys.modules[__name__]:
            continue
 
        #we also do not want to reload if the module comes from the standard lib
        #to check for this, we need to get the module's path and check that it
        #is in the lib folder, but not in the site packages folder
        moduleFilepath = attrModule.__file__.lower()
        pyStdLib = sysconfig.get_python_lib(standard_lib=True).lower()
        pySitePkg = sysconfig.get_python_lib().lower()
 
        if moduleFilepath.startswith(pyStdLib) \
        and not moduleFilepath.startswith(pySitePkg):
            continue
 
        #add the module to the list of modules that have been imported
        detectedModules.add(attrModule)
 
        #if the attr value does not have a name attr, skip to the next iteration
        if not hasattr(attrVal, '__name__'):
            continue
 
        #if the module where the attr value came from is different from the
        #current module, collect data we need to remap things
        origName = attrVal.__name__
        if attrModule != module:
            #print module.__name__, attrName, attrModule.__name__, origName
            remapData = ImportRemapData(
                module.__name__,
                attrName,
                attrModule.__name__,
                origName,
                type(attrVal)
                )
            _remappingData.append(remapData)
 
    #add the detected modules to the imported modules set
    _importedModules.update(detectedModules)
 
    #cycle through the modules we detected, which have not already been processed
    #and process them as well
    for detectedModule in detectedModules:
 
        if detectedModule in _processedModules:
            continue
 
        _getModuleData(detectedModule)
 
    return True

The recursiveReload method within the module is what is of interest here. To use this script, simply pass a module to this method. It will collect all modules that have been imported into the current working module, as well as all classes and modules that have been imported from modules or imported using aliases. It will then search each of the collected sub modules for the same information, and so on and so forth. When it hits the bottom, it will finish searching and then begin the reloading process. It will reload all of the modules, and then re-map extra data such as methods and classes and aliases.

Here is an example of the script in action. Save the following sample scripts in the same directory as the recursiveReload.py module seen above. Run test1a.py and then go and edit and save the test2.py and test3.py files while test1a.py is still running. Not everything will properly reload. Now, do the same with test1b.py. All changes should reload.

test1a.py:

import test2
 
from time import sleep
 
while True:
    print 'This is test1a.py'
    reload(test2)
    test2.printStatement()
    sleep(5)

test1b.py:

import sys
import test2
 
from time import sleep
from recursiveReload import recursiveReload
 
while True:
    print 'This is test1b.py'
    thisModule = sys.modules[__name__]
    recursiveReload(thisModule, debug=True)
    test2.printStatement()
    sleep(5)

test2.py:

from test3 import anotherPrintStatement
from test3 import PrintMultiplication as PrintMulti
 
def printStatement():
    print 'This is test2.py'
    anotherPrintStatement()
    PrintMulti(1, 2)

test3.py:

def anotherPrintStatement():
    print 'This is test3.py'
 
class PrintMultiplication(object):
    def __init__(self, x, y):
        print x * y

Feel free to continue adding more modules and make the importation chain even longer. It should continue to work.

You can pass True to the optional argument debug to have information printed to the console about which modules are being reloaded. The method will not reload builtin modules, the recursiveReload module, the __main__ module (it qualifies as a builtin anyways), and any modules that originate from the Python installation’s standard library but not in the site packages.

There are a few situations where this module currently will not work. It will fail when importing variables from other modules that are storing basic data types such as strings, ints, floats, booleans. They cannot be traced back to the module where they originated from using the inspect.getmodule method.

This will also fail if you change an import statement from from moduleName import moduleName to import moduleName, if moduleName is the name of the module and then name of an object from within the module that you are importing. I have yet to get this change properly remapping. You can, however, change an import statement from from moduleName import methodName to import moduleName with no issues.

If you go to the Edit Deformers menu, there is an option to paint blendshape weights. This is the tool we will be using, but the tricky part of separating blendshapes like this is the overlap area between the shapes. Since blendshapes are additive, if the overlap area is not done properly, when both blendshapes are enabled you may run into areas where it is morphing more or less than what you intended.

So, our issue is essentially that these weights are not normalized. There is a simple solution to this problem: paint the weights using a skin node so that they are normalized, and then transfer the weights over to our blendshape node.

To do this, you will need to have good UVs set up for your mesh. They don’t have to be perfect, but they definitely cannot have any faces overlapping. When the UVs are good to go, duplicate your mesh. This is the mesh we will add the skin node to.

For our example, we are separating our main blendshape into left and right blendshapes. Create two joints and name them “left_blendshape” and “right_blendshape”. It doesn’t matter where you place these joints, as we are not going to be using them to deform the mesh. All we care about is getting the weights. Select these two joints and your skinning mesh and then create a smooth bind skin node. Paint your weights for however you want the shapes to be separated. The weights will be normalized so that all influences combined will add up to 1, which means our blendshapes will also add up to 1.

To transfer the weights over to your blendshape, select your skinned mesh and go to Skin > Edit Smooth Skin > Export Skin Weight Maps. Click on the options box. We want to export the luminance. Increase the map size to something large so get as much data transferred as possible. I use 2048×2048. Choose TIFF as the file format. Export the maps to wherever you want, just as long as you remember where you saved them to.

Now, on your mesh that has the blendshape set up, so to Edit Deformers > Paint Blend Shape Weights Tool. Click on the options box to bring up the tools panel. Select your main blendshape that your are wanting to separate into left and right shapes. Go down to Attribute Maps > Import. Make sure Luminance is chosen for Import value and then click on the Import button. Navigate to the folder where you exported your weight maps to from the skin node. Load the “left_blendshape” map and when you set the weight for the main blendshape to 1, it should only enable the blendshape on the left side. Duplicate the mesh, and you now have your blendshape for the left side. Repeat this process to get your right side blendshape as well.

Now that you have both your right and left blendshapes as separate meshes, select them both, select your main, undeformed mesh, and create a new blendshape node. The new blendshape node should now have both your left and right side blendshapes, and if you set both of their weights to 1 in the channel box they should add together perfectly and look exactly like the main blendshape that you started the process with.

There are two levels of encapsulation when working with assets: black boxing and attribute locking. Black boxing basically just hides  any non-published nodes from the Outliner so the animators can’t go getting into trouble with the guts of the rig. The guts of the rig is the proverbial “big red button”: leave a note saying “DO NOT TOUCH”, and it only increases temptation. Attribute locking goes through the entire asset and locks any attributes that have not been published.

There are a few problems with both of these encapsulation types. The biggest problems I have belong to the attribute locking. First off, any attributes you do not publish for the animator to use get locked and hidden. This means that for any attribute you want the animator to use, you actually need to publish. The problem with this is that every published attribute gets added to the asset node. This is a very useful feature, as you can publish your geometry visibility and controls visibility toggles, for example, and have them appear on the master node of the encapsulated rig, but when you have a hundred or so controls in the rig and several attributes per control that need to be published… well, yeah, it becomes cluttered and messy. All of a sudden a great feature has become completely useless.

Second problem with attribute locking is, locking certain attributes on certain nodes can actually break your rig. I wrote a MEL script on a previous production that was to go through all hidden nodes and lock all attributes on those nodes. I found that after doing this it would actually kill my IK handles and/or constraints (I didn’t bother trying to troubleshoot it much since it was obviously having major issues, so not sure exactly which nodes and attributes were having the problem). I thought Autodesk would have been taken into consideration with Maya’s assets, but apparently not. I ran into the same issue where parts of my rig just straight up broke after locking attributes.

The problem with black boxing, luckily, is a very small problem which can be easily fixed. The problem is that, although unpublished nodes are hidden from the Outliner, the animators can still select them when doing a select hierarchy command, so they’re not actually fully “black-boxed”. I fixed this by setting up two script jobs. The first script job is for when a scene is loaded. When the scene is loaded, it collects all asset container nodes, cycles through them, and appends the names of all unpublished nodes in each asset container to a shared array. The other script job is for whenever a new selection is made. When a new selection is made, the script job just quickly deselects the list of unpublished nodes we collected earlier.

One other issue I’ve run into is that when you add nodes to an asset, it essentially makes it impossible to work with it in the hypergraph. All of the nodes are stored in a container, and there is no isolating the nodes. If you select one node and tell it to graph just one level deep for inputs and outputs, it ignores you. You are looking at the entire node graph at all times, whether you like it or not. For this reason, I’ve actually made this entire process automated, and it is performed when the rig gets published. The script assumes you are organizing your rig scene a certain way, and then packages the rig accordingly. To explain further, when I start creating a rig, I have a hierarchy of group nodes set up that looks similar to the following:

• master
• controls
• geo
• highRes
• lowRes
• rig
• joints
• deformers
• misc

The packaging script knows to expect these nodes. It collects all nodes under the master node and adds them into an asset. Then, it collects all nodes under controls prefixed with “CNT_” and publishes them so they will still appear in the Outliner when blackboxed. Once blackboxed, the “CNT_” prefix is kind of redundant since every single node you see will have “CNT_” in front. I like to remove the prefix during packaging so that the animator only sees “LeftArm” or “Neck”, for example. It makes the rig a lot more readable in the Outliner.

Also, the packager expects that all attributes found on the master node found above should be published to the asset. Although I am not using the Lock Attribute feature, publishing attributes still makes it so that those attributes appear on the asset node. There is a setting in the channel box that allows you to have these attributes then be visible whenever you have selected any object belonging to the asset. This can be nice as long as you keep the number of attributes low and they are something that affects the entire rig.

Oh, I almost forgot one other cool thing about using assets. It makes walking the hierarchy a sinch for animators. The up and down arrows do not take you to the shape node, or the group node you have your control parented to. It takes you directly to the next published node and skips everything else in between.

Prime Focus was responsible for the epic bridge collapse sequence in the movie. A lot of hard work went into the sequence, and it featured a lot of gory deaths :)

I was responsible for the digital doubles on the bridge, both background and hero characters. I also wrote some tools for the project including a motion capture importer/mapper, and a tool to help match move easily make adjustments along the camera’s axis, while not changing how it appears to the camera, when stereoscope issues arose.

If you haven’t seen the movie yet, consider checking it out. You pretty much know what you’re going to get from a Final Destination movie, but this installation is a lot of fun, not as predictable with how the deaths play out, and quite funny!

I started out using the simple muscle system with the muscle spline deformer, but at the advice of the documentation I have started exploring the newer “Muscle Creator” system, successor to the “Muscle Builder”. I can see how this new system adds more flexibility and makes things even easier again for setting up and customizing muscles (as stated in the docs).

I am going to continue testing both methods for the time being though. I’d like to decide for myself which workflow I think works best rather than just following what the documentation tells me to do. There have been many “new and improved” features rolled out in software packages in the past few years which never really caught on. Some do succeed admirably, but it seems just as many end up failing. Best thing to do, usually, is listen to general consensus among peers. So far in my searching, however, I have yet to find a consensus out there. Going to have to figure it out on my own.

This is another project I did almost two years ago now. Once again, it was a quick turnaround for Hatch Studio, when I was last working at PEN Productions. Paul Neale Rigged the ears on the bunny in the two commercial spots the bunny character was used in, while I took care of the rest of the character. I think Hatch did a great job on these commercials, as well as the Kid’s Cuisine spots.

Click here to head over to Hatch Studio’s website and watch the ads.

This was a project from close to two years ago now. Time sure does fly. It was a quick turnaround for Hatch Studio when I was last working with PEN Productions. I did all the rigging on the penguin-looking main character, “Kid”.

Click here to visit Hatch Studio’s website and check out the ads.

Three classes are currently being offered: Max/Mudbox Workflow, Intro to Character Rigging, and Max Script for Character Rigging. This is a great opportunity if any of these topics appeal to you, as you are being taught directly by one of the best in the business and unlike DVDs and video tutorials you get the chance to ask questions.

Head over to the PEN Productions website to check out details!

Click here to download the sample file (Made in 3ds Max 2010, and is of a Sackboy-looking teapot since I do not want to be distributing the model seen below, which is not mine, around the internets)

A video of the effect in action. Special thanks to Craig Hobbs for use of the model:

For now I am just going to do a general write-up of some things I am doing in the file and why I am doing them. It might sound like a tutorial at parts, but I’m more just explaining the general process and thoughts behind the setup. This is not intended to actually be a tutorial, and you may still have to figure some things out on your own.

PLEASE NOTE: This has not yet been tested in a production scenario; it is just some RnD work I have been doing. The solution does work and is simple to set up, but it does get slow with heavier meshes. This should only be used in the final render rig, as being in the animation rig will make the animator’s life miserable.

UPDATE 1: I may already have an improved method, thanks to Paul Neale, for doing this that is much better when it comes to speed and also solves the issue of hands and other extremities passing through the volume selected falloff area. I still have to test it.

UPDATE 2: The new method is quite improved, nearly doubling the FPS of the previous method. I am not going to share the new method here, as it basically uses the same ideas listed below. There is only a slight difference, but I will leave that up to you to figure out. I don’t want to give everything away :)

There are a few tricks to this set up. The keys are to have a volume select modifier, a spline with a sweep modifier, a duplicated mesh of your character’s head, and a morpher modifier above your skin modifier. Its thinking outside the box a little bit, and may seem kind of confusing at first, but after doing it once or twice it really is quite simple.

You’ll want to start setting this up after you have the jaw skinned for your character. Once you have the jaw all skinned and looking pretty, you need to duplicate the skinned mesh. The only alterations you need to make on this duplicated mesh is with the skinning around the mouth. Change the skinning of the lips so that they remain sealed when the jaw opens. This is how your lips will look when they stick. If you want to improve performance, you can remove all bones from the skin modifier except for the head and jaw bone (or whatever bones are actually influencing the lip area on your mesh). Un-hide the node “hlp_lips_geo” in the sample scene to see how mine were set up.

On the original mesh, you will notice there is a morpher modifier above the skin modifier. The reason for it being above the skin modifier is that we want the mesh to assume the absolute pose of our sticky lips mesh, so we want it to morph after the skinning has affected it. Having it below the skin modifier just doesn’t produce the same result. So, add the morpher modifier above the skin modifier, and then pick the duplicate “sticky lips” mesh as the target and turn it up to 100.

If you test it out at this point, you’ll notice the mesh just morphs back to whatever pose the duplicate mesh was in at the time it was picked. This isn’t what we want. There is a checkbox in the morpher modifier called “Automatically reload targets”. This needs to be enabled. This checkbox does exactly what it says and automatically reloads our target mesh. What this means is, since our target mesh is skinned, it will always morph to the current skinned state of the mesh. Once this is enabled, things should look a little better.

Now our lips are sticking, but they’re never un-sticking. This is where the volume select and a spline with a sweep come into play. Select the edges of the lower or upper lip, where they would be sticking, from one corner of the mouth to the other, and extract the edges as a shape. You can just go and make your own spline shape if you want, I just find this to be easiest and the most accurate method of getting the shape. Once the spline is created, it needs a sweep modifier so it had some thickness to it. This spline is what will be driving our volume select modifier, which is controlling our morpher modifier.

Up next, we need to add the volume select to the main head mesh, under the morpher modifier. Change the settings to what I have set up in the sample file. The main things to change are selection level to vertex, and select by mesh object, picking your spline. Enabling soft selection here is quite important, and you will have to play with the settings further down the road when you are fine tuning the stickiness.

We need the spline to follow the mouth’s skinning now. We want it to sit in the middle of the lips when opening, so the easiest way to achieve this is to skin wrap it to the duplicate mesh and then convert to skin. I had some errors with Max when leaving the skin wrap on the spline after converting it to skin; I consistently experienced issues with the viewport no longer redrawing, and the odd time Max would crash. The great thing about this method, and using a skin wrap here, is that if you have morph targets set up for your head you can easily extract matching shapes for your spline. You can even write a script to just go and automatically extract all shapes and set up a new morpher on the spline, making all the same connections as on the head’s morpher.

I have given the animator some manual controls for the stickiness. You can find these controls on the attribute holder on the jaw control object. I rigged the spline using a simple affect region modifier, connecting the side to side motion up to the slider labelled “Unstick Point” and then connecting the depth of the affect region (the y-axis of the end point) to the “Unstick” spinner. I also connected up the falloff from the affect region to the “Sticky Range” slider, pinch from the affect region to the “Sticky Pinch” spinner, and the morph target on the main head to the “Sticky Enabled” spinner. There may be other settings that would be useful for the animator to have control of, but this is all I’ve chosen to do in this example. Play around with each to see how it affects the end result. You may also want to play with the soft selection settings on the volume select, or the radius on the sweep modifier.

The reason this solution has speed issues is mostly because of the volume select modifier. It will work best with lower density meshes. Also, since it is generating a selection based on vertices being within a certain range of the spline object, if the character’s hand belongs to the same mesh and goes within this range, it may cause some issues. Just some things to consider. I am already thinking up ways to get around these issues, but I haven’t tested any of them yet.

That’s all for now. I just wanted to get this posted. Hope you’ve found it helpful! If you do not fully understand something I am explaining above, try examining the Max file to figure out what I did. If it still doesn’t make sense, feel free to leave your question in the comments below. Positive feedback is always welcome too :)