Scripting

And here I was feeling so good about my bindPose tool. I had added some functionality that Maya’s dagPose command doesn’t seem to have. I pat myself on the back, job well done. Except it turns out the dagPose command is a little more complicated than I originally thought. It still doesn’t do what I need want it to do, but what it does do can be a bit… odd, depending on how you’re interacting with it.

One of the procedures I wrote over the weekend is meant to save out the member, parent, and worldMatrix values from a dagPose node to a mel file, so the node can be recreated in another file. But while testing it on Rose’s bindPose, I noticed that the values didn’t match up – some of the members would have no worldMatrix values, for example. Looking into this, things got weirder and more frustrating.

If I used `getAttr -size bindPose.members`, I would get a value of 302. Using `dagPose -q -members bindPose` would return a value of 246. A more brute-force method returned a value of 217. But if I loaded the node in the connection editor, there were 305 member slots, and they all appeared to have incoming connections. Even more confusing was that, while the getAttr command said there were only 302 members and parents, it said their were 305 worldMatrix entries.

What I’ve found out, is that even if you tell the dagPose command to store only specific objects, it appears to also store any objects above those, as well as their parents and worldMatrix values. But when queried via the dagPose command, these extra members are not returned. If at some point you reparent an object, and then delete the groups that were once above it, those objects’ connection to the dagPose node will obviously be removed, but their worldMatrix values remain.

For now, what appears to work is to use the `getAttr -size` command on all three attributes, then using the highest value to limit the loop that processes the objects. It’s a hack solution that I have a feeling will cause problems later, but for now it appears to work.

I was hoping I’d be done with scripting for a while, but then necessity reared its head – After running into the old “skin was bound at a different pose” error, and the “Go To BindPose” screwing up character’s rig, I decided to write my own bindPose tool. There’s no reason “restoring” a bindPose should shoot a character’s jaw up through their head…

When the UI is loaded/refreshed, every dagPose node in the scene is selectable from a drop-down menu. If a skinned object is selected with the UI is loaded, its bindPose node is automatically selected.

Selections between the member and parent lists are synced up – select a member object will also highlight the stored parent. The pose can be restored for all nodes, or just those that are selected (something the dagPose command doesn’t appear to do). Poses can be restored globally or locally. And just to be extra careful, the current pose can be saved to a new node, so it can be restored later.

 

With the ability to copy and paste poses, this script could be a useful animation tool… but that’s not its intended purpose. Instead, I’ve started to write a separate script, modeled after 3DSMax’s copy/paste tool for Biped –

For now it’s just a UI, but getting it to work should only be a matter of time… preferably after I finish Rose.

For years now, I’ve been trying to automate as much of the rigging process as possible, particularly the limbs. Two problem that’s dogged me the whole time was a lack of customization, and code that was needlessly complex and difficult to maintain. My latest tool at least comes closer to solving both issues – rather than attempting to set up a full rig with single click, I’ve opted to set up each portion of the rig separately, while also including a one-click option.

For a quick, basic rig, the all I need to do is enter in the start, middle, and end joints, check ‘Use Default Settings’, and hit the Auto-Rig button. For a more customized rig, ‘Use Default Settings’ can be left unchecked… though I’ve yet to document which options can be set.

In the FK section, either a new chain can be created based on the input joints, or an existing chain can be specified. By default these joints will be parented to controls, but there’s an option to apply control shapes directly to the joints instead. Gimbal controls can also be created, for an extra layer of rotation. The results are then output to the their respective lists, making it easier to select and keep track of each component.

Like with FK, the IK section can also prepare a new chain, but has the added option of an orient control. This is mostly useful if, say, I want the IK chain to have a different default pose than the FK. Without any other options checked, the “Apply IK” button will build a no-frills IK setup – an IK handle, a pole vector, and nothing else. Stretching can be set up with either an expression or utilities, and as a bonus, can also be applied to the FK joints. “Apply Stretching to Selection” will do just that – if an IK handle is selected, stretching will be added to its joints.

 

Blending is fairly straight-forward – enter a control, specify a blending attribute (either a new name or an existing one), then hit the setup button. If there are no twist joints, the original input joints will be used. Otherwise, a new chain will be created.

 

The twisting section – if there are twist joints – is where the rig really comes together. Hitting the detect button will fill out the upper and lower joint lists. Three types of twisting are offered – simple, spline, and ribbon – although only simple and spline are currently implemented. Simple and spline both use spline-IK, the only difference is that simple uses 2-point linear curves.

Since spline uses cubic curves, it allows for rubber-hose effects even with the minimum amount of controls.

 

One thing I haven’t quite figured out yet, is how to easily rename all the nodes. Currently generic names are used, which is hardly ideal. Reverse-foot rigging is also something I need to implement, but for now the script is at least functional.