Archive for category maya

aimConstraints with no up vector

I’m pretty good about looking at the docs for nodes I use in Maya, because often there’s hidden functionality or switches that make nodes behave completely differently, and these things are often not apparent. A good example is on the extendCurve node– there’s a “join” attribute that’s completely hidden, but I found that setting it to zero was the difference between having a useful node and not.

A few weeks ago I discovered, much to my embarrassment, that I had not done my homework on aimConstraints. It turns out that the aimConstraint node’s up vector type can be set to “none”, which converts the aimConstraint into a quaternion-slerp-based orienter. This means that whatever you’ve picked will still aim at the target, but it won’t twist on the aim axis relative to the parent transform.

This is a lot like the SingleChainIK solver, but it has one important benefit: Not being an IK solver. IK solvers / handles in Maya have some very strange and esoteric bugs that don’t show themselves in every situation or even on every show, but when they hit, they hit hard. The more I use Maya, the more I find that skipping an IK handle wherever possible is the Right Thing.

The SingleChain solver is extremely useful for a variety of setups, but one problem I’ve encountered is that the handle itself doesn’t like to be scaled. I had some rigs where if the character were scaled below 0.5 or above 2.0, Maya would freeze for a few seconds and the SC solver would be broken once that number was passed. I fixed the issue by moving the IK handle into a group outside the hierarchy and pointConstraining it to the IK goal object, but the extra work bugged me. With an up-vectorless aimConstraint, I can remove a few extra transforms.

Another interesting node is that the RPSolver behaves exactly the same as both the SCSolver and the up-vectorless aimConstraint if its poleVector attribute is set to (0,0,0), and the solver is operating on a single bone chain. Not sure what use this is, but it’s in there.

How about an example use?


arm with pole chain
( download example .ma )

Adding an SCsolver chain from the shoulder to the wrist (aimed at the wrist control), then using it to move the pole vector around, can often be a very good way to extend the reach of a character’s IK arms without forcing the animator to constantly move the pole vector control. Give it a go– you’ll see what I mean. This setup doesn’t work on legs, depending on the animator, but for arms it’s not bad and with space switching you can still have the standard pole vector placement behind the chest if so desired.

spline IK overshoots

I’m constantly attempting new setups in rigging. Usually this is out of necessity, such as when current scripted setups don’t behave reliably or deliver the desired result with new models. Other attempts are me exploring things about my setups with which I’m not one hundred percent satisfied. I’ll keep doing research until I find a setup that works as I feel it should in the majority of situations, stably and predictably.

Stretchy Spline IK is something I’ve never liked because of the way its chains overshoot the end of the curve when the spline’s curvature is too great. I’ve never worked in a studio that had its own custom Spline IK solver, where this problem is non-existent, so I research solutions whenever I hit the issues that stretchy splines always bring.

Recently I had a thought about using live sub-curves of a spline (using the Maya subCurve node). I’ve always figured that the overshoots are due to floating point rounding and the fact that measuring a nurbs curve is an inexact science; curves are sub-samples a few thousand times, and the distances between points are summed.

(Before you ask, I use splines because they’re easy and light when you need to be able to lock a chain to a minimum or maximum length, but still allow stretching. I have not found a fast way of doing the same using a nurbs ribbon.)

I wrote a custom node to extract sub-curves by length along the original curve (using MFnNurbsCurve::findParamFromLength), then attached joints to each subCurve with Spline IK. I figured that sub-curves made by length would lock each joint in place, and that somehow this would work around the overshoot issue.

Boy was I wrong.

Turns out the assumption I’ve had for a while– the same assumption I’ve heard from other riggers– was itself incorrect. It’s not that the lengths aren’t being measured accurately enough, but that as the spline curves in on itself, the effective lengths of bones on it should shrink because the bones can’t bend to match. Obvious in hindsight, but it caught me by surprise. It’s like Manhattan Distance: in Euclidean space you may only be two kilometers from that pizzeria you love, but you end up walking three kilometers to get there because Euclidean distance doesn’t take into account the fact that we can’t pass through buildings. (Or: that sewers are winding and not always as easy to traverse as the city streets for your average turtle.)

On the up side I can think of a few good uses for the sub-curve node I made, so the experiment wasn’t a total loss. I also have a few ideas of how to use the curvature of the driving spline to come up with a scale value, meaning I have new experiments to carry out.

The test proved to me again that it never hurts to pull apart an established method in an attempt to do it better. “White belt mind,” a teacher of mine used to say– try to never lose that initial state we all have when we begin something new and are constantly trying to learn.

Tags: , ,

maya hotkeys for Blender 2.61

Rigging Dojo Link! The interest was in the Maya hotkeys for Blender. It’s funny because earlier in the week I had a discussion with a coworker about how hard learning Blender is for users of other software.

I’ve had a newer version put together by the wonderful and talented Rob Garlington sitting in my inbox for the past few months, but between moving across town, starting a new job, and getting engaged, I’ve been very lax in blog updates. For the interested, I’ve posted his updated file here:

 

Blender2MayaHotkeys_2.61.zip

 

It’s a shame that Rob’s setup can’t be added to the main Blender distribution; I think that having “familiar” hotkeys and navigation would go a long way towards swaying users of other packages to give Blender a try and show them that integrating it into any pipeline has its benefits. (I put quotes around “familiar” because the only software I’ve been using longer than Blender is Lightwave, so Blender’s hotkey setup has always made sense to me.)

The following are Rob’s installation notes.


 

Install (Note this has only been tested on Windows 7)

Full Functionality Install: (to fully take advantage of the keymap changes)

  1. Start Blender and open the ‘startup.blend’ file included in the ‘Blender2MayaHotkeys_2.61.zip\config’ folder. Then go to ‘file/save user settings’ (or press ctrl + U) to save this file as the default scene, then close Blender. (This will setup a special directory under your ‘Users’ folder.)
  2. Go to the folder C:\Users\’your name’\AppData\Roaming\Blender Foundation\Blender\2.61 (note that the ‘AppData’ directory may be hidden, but it is there nonetheless and you’ll need to unhide it). Extract the contents of the Blender2MayaHotkeys_2.61.zip archive into the 2.61 folder (overwrite files as necessary).
  3. Open Blender again and it should all be setup. To ensure it’s working, if you go to the ‘Input’ tab under ‘file/user preferences’ you should see that ‘Maya Advanced’ is loaded into the filter section.

Partial Functionality Install: (Some mouse selection features are missing with this method)

  1. Simply open the startup.blend included in the ‘Blender2MayaHotkeys_2.61.zip\config’ folder. Then go to ‘file/save user settings’ to save the scene as the default.

fun with python modules

New scripters I speak with don’t often know how to easily load code from external folders / modules in Python scripts. Today’s post will give you a few pointers in both Cinema 4D and Maya.

Setting Your Script Paths

Python’s import command should be no stranger to you if this topic interests you– it was probably the second thing most people learn in Python, after writing “Hello, World!” to the console. Import allows you to bring in code from libraries external to the source file in which you’re currently working. For example:

# commonly seen in Cinema 4D
import c4d
from c4d import *

# commonly seen in Maya
import maya
from maya import cmds as mc
import pymel.all as pm

These statements bring whatever module you specify into the current namespace, or bring in functions, classes, and variables. But where are the libraries that the import method references? Where do they live on disk?

The easiest way to find out is to list Python’s sys.path:

import sys
print(sys.path)

In my case, in Maya, it outputs the following:

[
'/Applications/Autodesk/maya2012/Maya.app/Contents/MacOS',
'/Applications/Autodesk/maya2012',
'/Users/Carney/scripts/mayaScripts/scripts',

...

u'/Users/Carney/Library/Preferences/Autodesk/maya/2012-x64/prefs/scripts',
u'/Users/Carney/Library/Preferences/Autodesk/maya/2012-x64/scripts',
u'/Users/Carney/Library/Preferences/Autodesk/maya/scripts'
]

Looking in the folders that are listed, you may find any number of Python source files and Python object files (*.pyc). sys.path is great because it’s just a regular Python list, which means it’s editable. You can append any number of paths that you like to it, and when import is called it will look through each and every path for the name specified.

Let’s try this in Cinema 4D. First, make a folder somewhere on your machine. I’m going to use /Users/Carney/Desktop/scripts for this example (I’m on a Mac.) In that folder, create a new file called util.py and add the following text:

# util.py
# simple utility functions

def ut_log(*args):
    msg =''
    for arg in args:
        msg += ' ' + str(arg)
    print(msg)

Now back in Cinema 4D, open the Console and the Script Manager from the Scripts menu. In the Script Manager, paste the following and hit Execute, replacing the path with the folder you chose above:

import sys
sys.path.append('/Users/Carney/Desktop/scripts')

import util
util.ut_log('Fun', 'Bunnies', 'are', 'fun.')

If all’s well, you should get a single sentence printed to the console output. If you made a mistake, you may get an error about not being able to import the util file. Check your path and try again.

With this setup, you can write scripts in your application that reference lengthy libraries of external code or other utility functions that you’ve created. At the moment I’m organizing code into single files with multiple functions for shorter utilities. Any function that’s more complex gets it’s own file and a class to contain it. This leads to funny lines like the following:

import module_generic
mod = module_generic.GenericModule()

But the organization and the ability to quickly update code without having to sift through a monolithic file inside the C4D Script Manager is worth the headache.

Automatically Adding Python Search Paths in Maya

The only thing to remember about this setup is that you have to make sure you add that folder you created to sys.path every time your application starts. In Maya this is a simple and well-known trick, but I had to do some digging to find out the same for Cinema 4D.

In both applications there’s a special Python file that gets loaded every time the Python VM restarts. In Maya, the file is called

Automatically Adding Search Paths in Maya

and it must live in one of three places:

  • ~/Library/Preferences/Autodesk/maya/2012-x64/prefs/scripts
  • ~/Library/Preferences/Autodesk/maya/2012-x64/scripts
  • ~/Library/Preferences/Autodesk/maya/scripts

You may notice that these are listed in the above printout of sys.path. When Maya starts it will execute userSetup.py files it finds. If you put the userSetup.py file in a folder that has the version of Maya specified (for example, in maya/2012-x64/scripts), then only that version will load the userSetup. If you place it in the general scripts folder — the last folder listed above — then it will be loaded by all Maya versions that support Python.

You can also use the MEL command internalVar -usd to find a folder that will work.

The userSetup file can execute any code you like when Maya loads, allowing you to have custom menus auto-created or to modify your sys.path variable so that you can access your code at any time. Try this: save a userSetup.py file into , and make sure it contains the following (after modifying the path to point to where you saved your util.py file):

import sys
sys.path.append('/Users/Carney/Desktop/scripts')

Now in Maya, open the script editor and copy, paste, and run the following:

import util
util.ut_log('Fun', 'Bunnies', 'are', 'funner.')

If all worked, you’ll see a line printed from your userSetup.py file letting you know that the custom setup succeeded on Maya startup, and you’ll see the proper output from this file.

Automatically Adding Python Search Paths in Cinema 4D

The way to do the above in Cinema 4D seems to be less well-known: you have to find the folder that is appropriate for your particular version of Cinema 4D and copy in a file called python_init.py.

The easiest way to find this folder is to go to the Scripts menu and choose User Scripts > Script Folder. This is the folder where scripts you’ve edited and saved through the Script Manager live. Now, go up one folder to Library, then go up again. This is the main folder for your version of Cinema 4D; it may have an oddly long name, but it contains your prefs and libraries. The python_init.py file belongs in prefs/python. As an example, my python_init.py folder is:

  • /Users/Carney/Library/MAXON/Cinema 4D R13/prefs/python/

Final Notes

This is just the start of organizing your code. If you want to know more, I recommend reading the official documentation on Python modules.

Tags: , , ,

maya input mapping for blender

A friend and fellow Blenderhead, Rob Garlington, spent a great deal of time working on an input remapping for Blender 2.5. What’s neat about his solution is that he’s also gone in and remapped the mouse inputs with the keyboard, so users coming over from Maya will really have a much easier time selecting objects or components and getting around the scene in general.

He doesn’t have a website set up yet, so I’ve offered to host his file here. It requires and has been updated for Blender 2.59.

After the download link, I’ve posted notes on usage from his email.

Download: Maya Input Remapping for Blender 2.59 (724kb)


Install:

The easiest way to install is to open this startup file in Blender 2.59, then go to ‘file\user preferences’ go to the bottom of the preferences screen and click the ‘save as default’ at the bottom. And that’s it, all the keys have been loaded into blender so that when you open any new scene it will use my key setup. If you ever want to go back to blender default simply click ‘file\load factory settings’.

Notes:

  • One thing to note despite my many changes to animation there was no option to deselect keys by simply clicking on blank space in the f-curve editor. So just press ‘A’ to deselect everything that way.
  • Most default blender settings that have been changed to accommodate this new setup usually require a ‘shift’ to work now. For instance to extrude a face press ‘shift e’ to work now.
  • Animation Changes:

  • ‘left click drag’ to marquee select keys
  • ‘middle mouse button’ moves the keys
  • ‘right click mouse’ will scrub the dope sheet and f-curve editor.
  • ‘s’ set to insert keyframe
  • ‘ctrl + alt + left mouse’ button for border zoom
  • ‘f’ will view all
  • ‘alt + right mouse drag’ for view zooming
  • ‘alt + middle mouse’ to move all 2d screens
  • ‘k + left mouse’ to scrub timeline in 2d screens
  • ‘, .’ goes to next or previous keyframe
  • ‘alt , or .’ goes to next or previous frame
  • 3D View Changes:

  • ‘left click drag’ select
  • ‘middle mouse button’ moves everything
  • ‘f’ will view selected
  • ‘left click’ outside of the object, deselects in object, edit mesh and pose mode
  • ‘spacebar’ brings up the dynamic spacebar menu
  • ‘right click’ (in edit mesh mode) brings up the mesh selection of faces/verts/edges
  • ‘4,5,6’ are mapped to the corresponding shading modes
  • ‘ctrl d ‘ duplicates objects/faces and everything else in Blender that can be duplicated
  • ‘g’ for repeat action
  • ‘shift + LMB’ will add more objects/verts/faces/edges to your selection
  • ‘ctrl + LMB’ will deselect objects/verts/faces/edges
  • ‘shift right click’ for 3d cursor placement
  • ‘shift space’ for search
  • ‘z’ also does an undo function in addition to the standard ‘ctrl z’
  • ‘ctrl + right click’ will enable lasso mode.
  • ‘alt + s and r’ go into scale and rotation mode
  • ‘ctrl + alt + s,r or g’ have been changed to clear the scale rotation or translation on any given object.
  • ‘y’ will bring up a special material selection toolbox.
  • Timeline:

  • ‘left click drag’ to scrub the main timeline
  • Things that remain the Blender default:

    Get used to using ‘a’ to either select or deselect everything as it is Blender’s default. UV view remains mostly the same as before.

    Tags: ,

    batch wrangling part 2 – Maya 2012 Human IK

    The second half of the work I did was to automate the process of moving data around between Motion Builder and Maya, and to make tools for the animators that lightened their loads when it came to exporting and retargeting animations. I was also responsible for a batch conversion pipeline.

    On the project there were animations in Motion Builder FBX files that were intended for reuse, which meant loading and retargeting multiple animations across multiple characters. This is a case (if only minimal edits are required) where the HIK system in Maya can be used to blast through conversions and free up animators for other work. Also, as many of the original animations were in single FBX files as Takes and the new decision was to have one file per animation (allowing multiple animators to work on the same character without file collisions in the version repository), the multi-take Motion Builder FBX files would need to be split in batch.

    The Maya Human IK system as of Maya 2012 is usable and has a lot of good benefits. Much of what they say works out of the box really does, provided you stick within the system: the ability to retarget animations between characters of differing sizes and joint placements works very well, and the fidelity of those animations stays high. If you rename or reorient bones but still have a Characterization in place for both characters, the transfer will still work out. However, there were also significant downsides:

  • The Motion Builder to Maya one-click scene send did not work as expected 100% of the time. When transferring from Motion Builder to Maya, I often found that while the Characterization would transfer over the rig itself would not be properly connected, and many times did not even come in at the right position in the Maya scene. Baking the keys down to the skeleton, transferring, and regenerating the rig on the Maya side does work. You lose the editability of having less keys, but you get a one-to-one transfer between the two programs this way and the Characterization makes rebuilding and rebaking the keys to the rig a one-click process.

  • On the Maya side you lose a lot of the features you’d expect. For example, the animators complained about not having foot roll controls. Regular Maya constraints don’t behave the same way you’d expect, and adding onto an HIK rig can be trickier than building on top of a regular Maya rig. The strangest thing was that you can’t zero controls. If you want to return to the “stance” pose, you have to change the input to the skeleton, then key the rig at the frame you want to have zero’d, and finally go back to having the rig control the skeleton. Editing curves on the HIK rig can be frustrating, as both the FK and IK objects are used to control the final position of joints and the different Human IK modes for posing and interaction pull at the body parts in different ways; often animators were baffled about which controls were causing jitters or other issues, and it was usually a control for a body part much higher up the hierarchy. Lastly, the HIK controls and skeleton don’t have the same orientations as the bones they’re based upon. If you’ve set up your skeleton in Maya properly with behaviour-mirrored arms and legs, you’ll find that you have to pose HIK-rigged characters’ limbs separately anyway. (I only had time to look into these issues for a moment, as I had a lot on my plate; if there are easy solutions that were overlooked I’d love to know what they are.)

  • I had a look at the system and the commands it used when I walked through the Characterization and retargeting processes, and determined at the time that Python was not the way to go for the retargeting pipeline itself. I found in tests that it was more work to get the MEL functions behind the HIK system working from Python than it was to write MEL wrapper functions and call out to them from Python when necessary. It was also more efficient to use the MEL functions as they were, as opposed to pulling them apart to find the necessary node connections to set up the system on my own.

    There’re a few lists of functions available online already (as I discovered on [insert blog link]). Here’re the ones I ended up using.

  • HIKCharacterizationTool, HIKCharacterControlsTool — These bring up their respective windows / docked panels. I found that not having the relevant window open made the functions that depended on the window being open fail, so keep that in mind when running HIK commands in batch.

  • getCurrentCharacter() — Returns the name of the current character as a string.

  • hikBakeToSkeleton — Bakes the keys from the rig or from another character being used as a retargeting source to the skeleton. I used this function when exporting from Maya to the game engine.

  • characterizationControlRigDelete() — Completely removes the control rig from the scene and sets the source for the character back to its skeleton.

  • setRigLookAndFeel(name, look number) — There are a few different looks for HIK rigs. In batch I found it nice to set the one I preferred before saving files out for animation fixes.

  • mayaHIKgetInputType — Returns 0 if input type is Stance Pose, 1 if input type is skeleton or control rig (I guess this means “self”), and 2 if input is another character.

  • mayaHIKsetCharacterInput(character, input character) — For retargeting, allows you to set the input of one character to be another in the scene.

  • characterizationCreate() — Creates a new Characterization node. You can rename the node and then make the UI recognize the new name with the following command.

  • characterizationToolUICmd — Useful for setting the current character name: characterizationToolUICmd -edit -setcurrentcharname [name]

  • setCharacterObject(object name, character name, characterization number, 0) — I don’t think I’ve seen this documented elsewhere, but this does the connecting during the Characterization phase from your joints into the character node. It appears the connections are specific and need to be fit into particular indices in a message attribute array, so the “characterization number” is something you need to figure out ahead of time if you’re doing a large number of these in batch. Some important numbers:

    Ground 0
    Left Thigh 2
    Left Calf 3
    Left Foot 4
    Left Toe 118
    Right Foot 7
    Right Toe 142
    Right Calf 6
    Right Thigh 5
    Pelvis / Center of Motion 1
    Left Clavicle 18
    Right Clavicle 19
    Left UpperArm 9
    Left Forearm 10
    Left Hand 11
    Right UpperArm 12
    Right Forearm 13
    Right Hand 14
    Neck Base 20
    Head 15

    The nice thing about this is that once you know all the numbers, you can slide them into attributes on the joints in your skeleton and use that data to apply characterizations later on.

  • Going forwards, if I were to use the same tools again in another production (and in cases where animation needs to be transferred between two differing skeletal hierarchies, it would make sense), I think I’d pull the code apart a bit more and have a look at how the connections are made at the lowest level, then rewrite a chunk of this code in Python.

    One more thing: using the standard functions, sometimes the UI will take a bit to catch up. Unfortunately, this means that functions which take inputs from the relevant UI will fail in situations where running them manually will work fine. EvalDeferred didn’t fix this issue for me every time, possibly because of how Qt and Maya are connected together and how they both do lazy updates at different times. I haven’t delved much into PyQt and Maya’s Qt underpinnings just yet, but the updating behavior is something for further study. In the interim, I found that using the maya.utils.processIdleEvents function to make sure all events were taken care of after doing major steps in the characterization or baking processes helped the UI catch up.

    Tags: , , , , ,

    quick tip #1

    It’s been a while since I’ve done anything in MEL. I try to avoid MEL when I can; after two years of doing the majority of my Maya tools and scripts in Python (with the last year being pure Python), switching gears to work in MEL and losing the object-oriented nature of Python (along with its wonderful string and array manipulation tools) makes me feel like I’ve got a hand tied behind my back.

    Still, MEL’s importance will continue for some time and there will be times when it’s necessary to hack out a bit MEL code. I wanted to make a quick tip note about something I’m embarrassed to say I didn’t know until a few days ago that might help you with your MEL scripts.

    I use the whatIs command often to track down the source of built-in scripted functionality. Calling it on a function that exists in default MEL scripts will tell you in which script that function lives and where to find it; afterwards, you can break it apart and use the pertinent parts in your own script.

    However, what I did not know is that whatIs can also tell you about in-memory variables. Here’s an example:

    string $value = "Bunnies";
    int $intArray[] = { 1,2,3,4,5 };

    whatIs "$value"; // Result: string variable //
    whatIs "$intArray"; // Result: int[] variable //

    If you run the code you’ll see that it returns a string with the type of the variable you checked. Quite handy, since you can use it to check types of default global variables. But even handier is what happens when you use it on a variable that has not yet been created:

    whatIs "$someWonderfulVariable";

    This will return the string “Unknown”. If you, not unlike my recent self, are trying to determine in your or someone else’s code whether a required variable has been created, this is the way to check.

    In other news, my new job begins on Tuesday. I’m extremely excited and I’ll post more about it once I’ve gotten situated there.

    Also, if you’re Canadian, elections are happening on Monday! An interesting notion is the thought of voting for a non-Reform party candidate in your riding whose projections are highest instead of voting for the party or a leader you’re usually inclined to do, with an eye towards unseating the current Reform government and getting Harper out of there. Two websites on this very thing:

    http://www.whipharper.ca/
    http://www.projectdemocracy.ca/

    Don’t worry– I won’t be mixing political messages with code tips in the future.

    Tags: , ,

    new yaaaawk, baybee!

    Dimos and I headed out over the weekend to see Mike in New York. The title of this post is what Dimos screamed, cheerleader-on-prom-night-in-the-back-of-a-volkswagen style, every five minutes. Somehow it never got old.

    There are amazing pictures taken by Mike of both Dimos and myself on Facebook; hopefully I’ll find some time this weekend to get the pics of my own camera and Flickrize them.

    I might talk a bit more about the trip in a few days, but what I actually wanted to write is this:

    To project a worldspace point into camera space, you need to multiply the camera’s view matrix by its projection matrix. The projection matrix is grabbable through the OpenMaya API (there’s a function for it on MFnCamera). The view matrix is simply the inverse of the worldspace transform matrix.

    Needed to get that out of my head and into a place I wouldn’t lose it. If that makes no sense to you, just pretend it wasn’t there. 🙂

    good news everyone

    I’ve been meaning to post what’s below for about a week. I suppose it’s only going up now because at this moment I’m in the waiting room at the doctor’s office; took a bad spill down some stairs yesterday and everyone keeps telling me to go in and get checked out.

    I don’t quote Dr. Farnsworth just any day: Mac users will be pleased to note that Snow Leopard 10.6.2 fixes almost all compatibility issues with Maya. And the graph editor no longer corrupts! So if you were waiting on Maya before upgrading, your wait is over. I haven’t tried 2010 (haven’t upgraded since there’s nothing new in it) but 2009 now works better than it did under Leopard. I think Dimos tried 2010, though, and dubbed it good.

    But today I want to talk about music. Specifically: I finally bought an Axiom 49.

    I bought one of M-Audio’s Oxygen 25-key keyboards years back. It was a solid piece of hardware despite being the entry-level unit, and traveled with me to and from Japan. I recently gave it to a friend who wants to start producing her own music with Garage Band. I’d like to say it was for wholly selfless reasons, but the truth is I wanted an excuse to get a keyboard with more octaves.

    The Axiom 49 doesn’t disappoint. It’s not a keyboard you want to lug to a gig; it’s heavy as sin. However, it’s well-constructed and sturdy. I feel like I could fight off a zombie with it and still play a round of lounge jazz afterwards. Also, I dig how the drum pads feel and control. They’re pressure sensitive like the piano keys, and they’re lovely for hammering out tom hits or even for a quick lead pattern.

    The best part is that it came with Ableton Live Lite 6, which was upgradeable to Live Lite 8 for free with their current ten-year promotion. I’d been thinking of getting the recently-released Intro version of Live 8, but this was close enough to help me decide if I needed the full version or not, saving me a hundred bucks.

    I think that a lot of people out there would be fine with Live Lite. The one feature that I found a dealbreaker is that a single song can only have up to 6 effects in total across all instruments. (In Live Intro it’s 12.) The way I design my sounds, I hit that limit playing around on a single loop a few nights ago. It wouldn’t be a problem if I could freeze tracks or if the limit were for simultaneous effects in use, but even effects on tracks currently producing no sound count.

    So I’ll be picking up the full version of Live pretty soon. I had a look at the Studio package but I’m dithering on whether pay the extra cost for a lot of samples I might not need at the moment, and I’m only interested in two of their custom software instruments.

    The bonus of using Live: PureMagnetik has really cheap sample packs, and their guitar rig kits sound fricken’ awesome. I also can’t wait to use Sampler to make kits from sounds around town.

    Tags: ,

    Weak References

    Last year while I was working at Red Rover, I heard the term “weak reference” in reference to a technique for referencing objects in 3DS Max. The Max TD used them for a variety of things. I didn’t quite understand what he was talking about at the time, since the last version of Max I used was 2.5 and I never did rigging or coding for it then.

    More recently I’ve come to the same technique on my own both in Maya and in Cinema 4D, and was reminded of the name for it by that same TD over beers a few weeks back.

    Essentially, weak references are variables on objects that contain a pointer to an object, and not a reference to it’s name. In Maya, for example, you may see rigging scripts written by TDs referencing specific objects by name or saving names of objects as they’re created and using those names to connect attributes or add constraints. In a clean scene this works fine, as long as the rigger is meticulous in their naming scheme and runs different stages of the rigging script in proper order.

    But what happens when Maya namespaces become involved? As soon as you reference in an asset, every object that makes up that asset gets a namespace prefixed onto it’s name. If you’ve written scripts that require specific names, they break. If your layout files aren’t perfect and the namespace is different between two or more shots (as Maya is wont to append a number, regardless of what you specify), useful tools like character GUIs and the like break and you’re left doing namespace surgery in a text editor.

    Weak references sidestep all this by giving you a permanent connection to an object regardless of name changes or namespace prefixes.

    A good example is how I’m currently handling cameras in scenes. A decision was made early on, on the current project at work, to name cameras in layout files by the name of the shot / sequence. Normally this isnt a problem, but we’re using a renderer that’s not linked into Maya directly and therefore needs a command line batch exporter written. If all the cameras are named differently, and the camera’s animation has to be baked and exported as well, how do you go about picking the right object?

    Using weak references, the problem becomes trivial. You create them as follows:

    addAttr -ln "cameraObj" -at "message";

    You’ve probably seen attribute connections of type message into IK handles and other things. The message attribute carries no data– that is, it never changes and causes no DAG recalculations. (This is doubly useful because you can connect the message attributes of two objects to message-typed user attributes in a cycle without causing a cycle error– more on that later.) However, the attribute can be used to get the name of the connected object like so:

    listConnections object.messageAttribute;

    It will return an array of strings. If you rename an object, you can get the object’s current name through the above command.

    So where do you store these attributes? For the moment I’m using a trick I saw on the Siggraph ’08 talk by Blue Sky on procedural rigging: I create non-executing script nodes and store connections on them. In the camera example above, every scene has a master script node. On that node are a few attributes, including its “type” and a .message connection to the render camera. It’s them trivial to find the camera’s name:

    string $sel[] = `ls -type "script"`;
    for ($s in $sel) {
    	if (`attributeQuery -node $s -ex "snCamera"`) {
    		// this should be the one you need
    		// normally I search for the type, but this is an example
    		string $conn[] = `listConnections ($s + ".snCamera")`;
    		// if it's only one connection incoming, then you're done.
    		print("Camera is named " + ($conn[0]) + "\n");
    	}
    }

    This technique can be extended to include all kinds of objects. It can also be very helpful for scripts like character GUIs that need to know what characters are present in a scene, and be able to change the positions of all those controls.

    One final note on this for now: In Cinema 4D, every object and tag in a scene can be named the same. Searches for objects or tags by name are often fruitless because of this; if two objects or tags have the same name there’s really no easy way to tell which is which in a COFFEE script. What you can do, however, is create a user data variable that is of the Link type. This allows you to drag and drop an object into that variable’s edit field, and provides a permanent pointer to that object regardless of name. This is very useful in rigging; for example, you can always tell which joints in a leg are control joints, and which are bind joints, by creating links. You can also expose the links in XPresso and use the pointers as if you’d dragged an object onto the XPresso node window.