EddieOffermann dot com

It's been a while since I updated here, but I thought I'd throw out a tidbit from something I've been working on.

Part of any vfx pipeline project involves making your different software pieces communicate with each other. Part of that, of course, is being able to write common file formats. Sometimes that's for sharing generic data, such as through XML, or basic channel information that can be written to a tab or space-delimited text file sometimes referred to as a chan file.

Other times, though, you'll want the packages to communicate more intimately, and Maya provides a method to closely integrate different software packages with it as long as the other packages have the ability to do port-level communication. If you haven't written IP protocol software before, this can be a little daunting, so I'm going to share a couple short code tidbits that'll make talking to Maya a little easier. I'm assuming some basic MEL experience, and some background in Python wouldn't hurt either, though you should be able to follow along with any amount of coding background. I'll be skipping the tedious details though, so if you need a programming refresher that's beyond the scope of this post.

First, you'll want to pick the port that Maya is going to listen on. For my example, I'll use 7777 - basically because it's not used by another widely used protocol, and because it'll be easy to identify in the example code.

In Maya, either in the script editor or as part of another MEL script, you'll want to execute:

commandPort -n ":7777";

Now, this will open a port on 7777 which I should give you a little warning about: ANYTHING that is sent to that port will be executed by Maya, as long as it is running, and until that port is closed. This includes quitting maya, saving or deleting your scene, or even executing system commands. So you may want to have the data coming across that port filtered by a MEL procedure first, or passed to a command. In that case, you'll want something like this:

commandPort -n ":7777" -pre listenOnPort;

In the former case, anything you send to port 7777 will be executed by Maya. In the latter case, you'll want a procedure like:

global proc listenOnPort(string $argv)
     {
     string $args[];
     int $argnum=`tokenize $argv $args`;
     // Code to process $args should follow here...
     };

Now of course, you need some way to communicate with Maya. This is where it's actually a little tricky - since you'll need a socket client to issue commands. I'm providing only the most basic example: this one is asynchronous and one-way only. There is no way for this routine to receive any feedback from Maya.

#!/usr/bin/python2.5
import socket
import sys
HOST = '127.0.0.1'
PORT = 7777
CMD=sys.argv[1]
try:
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
except socket.error, msg:
    sys.stderr.write("[ERROR] %s\n" % msg[1])
    sys.exit(1)
try:
    sock.connect((HOST, PORT))
except socket.error, msg:
    sys.stderr.write("[ERROR] %s\n" % msg[1])
    sys.exit(2)
sock.send("%s\n" % (CMD))
sys.exit(0)

By calling:

talktomaya.py "select -all"

You will be able to send the indicated command to Maya to be executed, or in the case of the -pre example, pass the command to the procedure for parsing.

More sophisticated implementations may require sending to machines other than localhost (127.0.0.1) as in the above example, and that's left as an exercise to the reader. It's a simple matter to send commands to a range of machines across a collection of IP addresses. Examples of this might include having individual users register their interest in a particular piece of data - and when that data is released, those users are notified automatically that the data is available, say an updated model or a revised animation, and giving them the ability to then update their scene with the new data. It might also be useful to centrally request an update from all users who are currently working on assets required for a particular shot - and obviously many other options are available when you can communicate directly with the maya instance of each user in a facility.

The tricky bit is that I hadn't seen a clear example of a script to send instructions to Maya - and there it is, in its most basic form.

Installing pyShake on the laptop today.

It's every bit as painful as it was when I installed it on my old desktop machine.  Maybe a liiiiiittle bit better since at there's a configure for it now, but installing prebuilt binaries really spoils you.

If you've never installed a traditional unix/linux/macosx application,  you're in for a treat. It's one thing if it's your own application, as well, since you'll know what's going on: but when it's someone else's...

Well, you never *really* know what any application installer is doing.  Data gets socked away hither and thither, but mostly you don't know about it.

Doing a configure/make/make install sequence usually displays TONS of data.  There will be a thousand lines of successful completions, another thousand of warnings of varying severity (with usually alarming-sounding messages that may or may not be important - and very frequently aren't), and maybe even a few outright failures that *also* may or may not be important.

A truly great build will usually ease your mind a little.  Several of the warnings you get for things like boost::python will reassure you that the error you're seeing happens to nearly everyone and shouldn't alarm you.

Somehow, that doesn't make me feel entirely at ease. It's like your girlfriend telling you, "It's ok, honey. It could happen to anyone."

Then there are errors like this:
Please ensure that LDFLAGS is configured properly, or specify --with-boost-root

Thanks.  I'll do that.

I was talking to a friend today about what I'm doing with regards to managing data through an animation pipeline using XML. The more I work with it and the farther I get into the project, the more flexible and powerful the whole thing seems. Of course the goal to doing the implementation in Python is that virtually every software package in the vfx industry is python-friendly - so once the core routines are written, everything from Nuke and pyShake (the python plugin for Shake - if you haven't seen it yet, check it out here) to Maya, Houdini and RealFlow will be able to make use of them. I think most places are doing that these days, with a few nods to TCL/tk here and there - but broadly supported scripting languages are King and open description formats like XML are Queen.

My friend marveled at how nice it would be if one day, a couple years from now, everything was able to talk that smoothly: that a character animated in Maya could be pulled into Houdini, for instance, as something other than an OBJ sequence or a separately rigged character that you had to tediously (or with a lot of specific coding) link to exported channel data.

I wonder if that interoperability thing will ever extend beyond each individual studio's implementation. Everybody has a way of getting software to talk amongst themselves, some solutions being more elegant than others, but when you invest in creating something as elaborate as this it becomes your own proprietary tool. If you develop a tool that an animator can take an animated character with a complex rig on it, arbitrarily select additional elements that were never *really* meant to be animated and animate them anyway, and the modeling team can modify the model and issue a new version of it - and the animation gets seamlessly transferred over to the new model, even able to be read into RealFlow, substituting a different set of low poly independent objects that are driven by the data in that XML file: you don't put that pipeline tool on the internet for everyone to download for free.

That tool becomes your secret weapon. As a studio with an investment in a powerful and unique proprietary tool, even charging for it may not mean as much to you as the edge you gain during the heat of production.

Being XML based and implemented in Python does put my current project a wee bit closer to being an open standard, though. Even Shake will take Python scripts now - and they're really powerful in it and getting more so as development continues. The readability thing for XML is a gigantic plus, and the way it represents data is great. I can build a module that will write out the translation of a locator in both world and local space, as a baked set (every frame has a value) and as a set of keyframes (values only for those frames where the value was explicitly set by the artist), as well as screenspace UV values - so the same XML file could reconstruct a scene for a lighter to light and render from or another animator to tweak the animation curves, or for RealFlow to drive low-poly proxy objects with to disturb a drifting mist, or for a compositor in Toxic to link an effect to. And it's all one XML file - not a half dozen formats (often multiple versions of each) and a hundred-unit sequence of geometry exports.