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.

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:

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.

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.

I have Maya Creation Suite 2012 on my work machine, which is touted as being able to seamlessly transfer data between the included apps– Maya, MotionBuilder, and Mudbox. I haven’t had need to open Mudbox yet, but in my limited testing so far the Human IK rigs never come through properly from MB to Maya and on the Maya side the HIK characterization gets broken. This means that to do any animation fixes or retargeting inside Maya, the characterization needs to be deleted and rebuilt. Also funny: the automatic naming templates in Maya don’t always work, making recharacterization a tedious manual process. Keyed transforms (joints, etc.) and meshes come through just fine, however, with all skinning and materials in tact. Updating previously-sent objects did not.

Apart from all that, the first file I’ve been working on has 50 animations in it. I didn’t relish the idea of converting all of them by hand, so I set about seeing what’s possible on the scripting side.

The FBX import/export plugin comes with a number of commands for massaging how files are read in. A full list of the commands is on Autodesk’s site. Note that the Python versions of these functions fail; I think they’re being generated improperly at plugin load. Could be that I’m just not calling them properly; I didn’t bug-hunt because I found doing the HIK post-import steps didn’t work in Python, either.

I’ve written more MEL in the last two days than I have in the last four years, not that it’s a lot of code!

The important commands for what I needed are:

FBXRead -f [filename] — Doesn’t do any loading. Instead, it sets the specified file as the source for all queries.

FBXGetTakeCount — Self-explanatory; on the file I was editing it returned 50.

FBXGetTakeName [index]: returns the name of the take for a specified index. The indices are 1-based. I saved all of these in a string array.

FBXImportSetMayaFrameRate -v [true|false] — Important in my case because the animation was all at 30 frames per second, while Maya is usually set to 24.

FBXImportFillTimeline -v [true|false] — Makes sure the timeline length matches the length of the imported animation (although see below for a gotcha)

FBXImport -file "c:/myfile.fbx" -t [take index] — Does the actual loading of the scene. By specifying a take index, you can be sure to get only the animation you want.

With this information, I was able to loop through the animations in the FBX and, after a bit of post-import processing, spit out a series of .ma files.

There were few gotchas. One problem was that while the script was running, sometimes the setting for having the FBX file’s time length override the same in Maya would get truncated– the animation length got set but the [bar that shortens the animation] would get set to half the length. I couldn’t replicate the issue running the MEL script in small chunks. A call to playbackOptions in my loop fixed this, but it’s still weird.

Part two of this discussion will be about man-handling Maya’s Human IK in a batch process.

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.

A conversation at work got me interested enough in GPGPU calculations to start doing a bit of research into the topic. Seems that at a base level both the ATI and NVidia APIs behave similarly, and that OpenCL is a nice, understandable alternative if you don’t want to be locked in to a single vendor. (Not that I use ATI cards.) I tried getting CUDA working on my Mac, but between weirdness caused by the drivers and the fact that it doesn’t support 64-bit on OSX, I’ve decided to go with OpenCL instead for my tests. Functionally everything will be the same, and after a nice tutorial on ATI’s site detailing some introductory points I have code that compiles and does what I want it to do, which is more than I can say for CUDA.

Anyway, here’s my first test. I wanted something simple for getting device information off my laptop.

(Hope that copy-and-pasted correctly.) To compile it on your Mac:

Here are the results on my laptop, a 2010 Core i7 MacBook Pro 15″:

Number of CPU devices: 1
Device Name: Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
Vendor: Intel
Driver Version: 1.0
Device Version: OpenCL 1.0
Device Profile: FULL_PROFILE
Device Platform: 0
Device Vendor ID: 16909312
Max Compute Units: 4
Max Work Item Dimensions: 3
Max Work Item Sizes: 1, 1, 1
Max Work Group Size: 1

Number of GPU devices: 1
Device Name: GeForce GT 330M
Vendor: NVIDIA
Driver Version: CLH 1.0
Device Version: OpenCL 1.0
Device Profile: FULL_PROFILE
Device Platform: 0
Device Vendor ID: 16918016
Max Compute Units: 6
Max Work Item Dimensions: 3
Max Work Item Sizes: 512, 512, 64
Max Work Group Size: 512

Next step: getting the GPU to do some calculations.

It’s been an interesting week. I’ve been tasked with doing research on cloth simming, or rather not simming, which is about all I can say. However, I can say that it’s been an interesting challenge and has helped me to better understand some of the more esoteric corners of Maya Dynamics.

Work aside, the G20 meet up has the entire city by the balls. The trains are shutting down due to bomb threats, and a number of people at the office have been ID’d on the way in by the some of the hundreds of cops patrolling the downtown core. The whole thing is a mess. Lots of downtown businesses are losing money because of forced shutdowns. Even my office is shutting for friday because the building is getting boarded up.

It’s strange to me… I can’t quite follow the logic on violent protests for something like this. Regardless of what’s being discussed, I can’t imagine any topics are worthy of that kind of response.

Anyway, to work with us!

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.

var op = doc->GetActiveObject();
var curTime = doc->GetTime();

println("\nKey dump for ", op->GetName(), ":\n");

var t = op->GetFirstCTrack();
if (t == NULL)
	println("Error.");

var i = 0;
var j = 0;
var k;
var c;

while (t != NULL) {
	i++;
	c = t->GetCurve();
	println("\tTrack ", i, ": ", t->GetName(), " -- ",
	c->GetKeyCount(), " keys.");

	for (j = 0; j < c->GetKeyCount(); j++) {
		k = c->GetKey(j);
		var bt = k->GetTime();
		println("\t\t", j, ": v", k->GetValue(), ", t:", bt->GetFrame(30));
	}

	t = t->GetNext();
}

println("Number of tracks: ", i);

The sad part is this: you can’t add new keys to curves in COFFEE; you can only read what’s there. (EPIC FAIL, Maxon.) At least now I know how to get keys and how the BaseTime class works.

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.

It all started with this link (which you’ve already seen if you follow me on Twitter): the The Eco Zoo. If you haven’t seen it, please clicky! It’s fantastic.

PaperVision’s been used for a number of neat projects, but the Eco Zoo is a work of art. So I started searching for stuff on the train in the morning (thank you, iPhone) and turned up a bunch of great links:

• A Whiter Shade of Paper: really in-depth site with technical articles and example code on a PaperVision-based game the author is working on.
• Installing PaperVision in Flex or Flash: good notes on the basic getting started.
• ActionScript class exporter for Blender.
• The PaperVision3D Dev Blog
• Meta4orce notes by Iann Lobb — some really good notes on doing commercial work with PV3D. Oh, and if you want to play the games he made, the site is still up at the BBC.
• Seb Lee-Delise – Changing the materials on a cube dynamically.
• Everyday Flash – Pixel precision in Papervision 3D

For those who didn’t know, you can either use the open source Flex SDK or, if you’re a student, you can get a free copy of Flex Builder 3 by sending them proof of enrollment. I did it; I got a serial in about an hour later, although YMMV.

Not that I have time to sit down and actually play with any of this… But it’s fun to learn about. Oh, and I like PaperVision3D because the API is very well thought out and very Flash AS3-like; if you don’t like it there are other options. There’s a nice comparsion on the four major 3D engines for Flash here (warning: it’s in French). Lots of talk about speed of object creation, memory requirements, and so on. It’s always good to be informed of options before starting a project.