I was having trouble finding a solution to the problem when searching the internet. The best solution I found was to pass the wrapped geometry through a blendshape node and then scale that node. This was not a suitable solution for what I needed as the rig I was dealing with had far too many wraps. It would have meant a huge pain to get working and also a much slower rig in the end.

After lots of trial and error, I was able to find a solution to fit my needs. It is fairly simple in the end, and it doesn’t create a huge amount of overhead. Please watch the following video to see how to get it working. Download sample files by clicking here.

This whole time that I was using setAttr, I could not understand why I was not able to just set all weights for a vert rather than having to assign a weight for each influence affecting each vert. This, I knew for certain, was what was slowing me down. I went through the same song and dance when collecting the skin weights: doing a getAttr on weightList[#].weights[#] for every single vert and influence was slow, but doing a getAttr on weightList[#].weights was fast. Made good sense. However, whenever I tried to do a setAttr on weightList[#].weights I would receive an error message telling me they had to be set individually. This is what the simple ma file helped me get around.

It turns out, you can setAttr on weightList[#].weights! Well, sort of. You can do it on a range of influences in one go. There are just a few tricks. Here is an example of the proper syntax in order to do this:

cmds.setAttr('skinCluster1.weightList[0].weights[0:2]', 0.2, 0.2, 0.6)

You must specify the range of influences after weights, and the provide the weight values individually.
If you have weights assigned to another influence object for that same vertex, but it is not sequential to the other influences involved, you must do this in a separate setAttr call.

cmds.setAttr('skinCluster1.weightList[0].weights[0:2]', 0.2, 0.2, 0.2)
cmds.setAttr('skinCluster1.weightList[0].weights[6]', 0.4)

I saw significant speed improvements using this method over the previous method of setting each influence individually. The mesh I was testing on went from a load titime of 67 seconds down to 15 seconds. This offers some definite speed improvements.
In order to do this, of course, you need to be able to sort your data into sequences and then feed it to the setAttr command. Here is a simple method for converting a list of numbers to a nested list of sequences using those numbers:

from itertools import izip
 
def getRangesFromIntegers(integers, flat=False):
	currentRange = [integers[0]]
	offsetInts = integers[1:]
	ranges = [currentRange]
	for currentInt, previousInt in izip(offsetInts, integers):
		if currentInt - previousInt == 1:
			currentRange.append(currentInt)
		else:
			currentRange = [currentInt]
			ranges.append(currentRange)
	if flat:
		return [tuple(rng) for rng in ranges]
	else:
		returnRanges = []
		for rng in ranges:
			if len(rng) > 1:
				returnRanges.append(tuple([min(rng), max(rng)]))
			else:
				returnRanges.append(tuple(rng))
		return returnRanges

What you need to do after getting your sequences is collect your weights in these same groups. Its not difficult, so I am just going to leave that up to you to figure out. It may depend on how you collected your weight data though. If you have any questions, just leave a comment below. Once you have your weight data, you just need to pass everything to the setAttr command. It would look something as follows:

for myRange, myWeights in {(0,2):[0.2, 0.2, 0.5], (8,):[0.1]}.iteritems():
    myStrRange = [str(ind) for ind in myRange]
    cmds.setAttr('skinCluster1.weightList[0].weights[%s]' % ':'.join(myStrRange), *myWeights)

If you are unfamiliar with the * in front of myWeights and what it is doing, this is commonly used when inheriting classes and overriding class methods. It allows us, here, to pass a list of values to the setAttr command and have them be automatically unpacked. The first iteration of this loop will essentially look exactly like this:

cmds.setAttr('skinCluster1.weightList[0].weights[0:2]', 0.2, 0.2, 0.5)

I don’t know if this is what other people have been doing already. Maybe it is. I didn’t see it mentioned anywhere in my searching though, so I hope this ends up being of help to some people!

This wrapper is intended mainly for tools that will connect to Shotgun to retrieve one piece of data and then disconnect. Think tools like frame-range fetchers for when a scene is opened in Maya or Nuke. The wrapper will provide good speed improvements in these scenarios.

I discovered, after using Shotgun’s API for a while, that I was often experiencing slow initialization/connection times. Sometimes I would be waiting 5 seconds or so when creating a Shotgun object. It got me thinking that perhaps I could create a Shotgun object before hand and just pass my Shotgun commands to it, bypassing the initialization and connection process for the Shotgun object. That is basically what this wrapper does. You need to create a DoubleBarrelServer and have that script running on another machine on your network. Then, when you create a DoubleBarrel object, you just need to provide the host and port information that you provided to the DoubleBarrelServer when initializing it, and rather than connecting directly to the Shotgun database you will instead connect to the DoubleBarrelServer and send your requests through it.

Have a look at the README on the GitHub page below, and let me know if there are any questions. I can provide more documentation, if needed. The serverTest and wrapperTest files in the tests package provide an example scenario of how to use. DoubleBarrel is also easily implemented into existing Python tools using the Shotgun API. The structure of DoubleBarrel is identical to that of the regular Shotgun API, so all you need to do is change the line in your code where you are importing the Shotgun class to instead import the DoubleBarrel class as Shotgun, and then provide the host and port information when creating an instance of the Shotgun class.

GitHub page for DoubleBarrel

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.