EddieOffermann dot com

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.