EddieOffermann dot com

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.

I don't know where I read that, but it amused me and stuck in my head.

Hi!  I haven't been updating the vfx blog because I've been crazy busy.  Work has me deep in MEL and Python code most of the day, writing software to manage animation data, shuttle it this way and that and process it in interesting ways.  There's also the secret project that everyone isn't talking about but is quietly and excitedly waiting for (assuming they have any idea what it is).   We're on super-special-secret-lockdown at work, I'm guessing for the rest of the month.  I can scarcely go to the bathroom or grab a soda without passing through at least two security doors now.

Ok, I admit it, we've been contracted to create the lost tapes of the lunar landing.  Seems NASA has gotten enough flack about the original landing with people claiming they can prove it wasn't real that they've decided to create more proof to put the concerns to rest.

Or at least that's my amusing cover story until I'm allowed to talk about the other thing.

Between all the other little tasks, I'm in the process of working up a new tool for moving complex animation data around the pipeline.  The idea is to be able to read and write an XML file that contains as much data as anyone would care to put onto a model.  The model can be updated, have new elements added to or removed from it, all sorts of parts of that model can be animated at a whim by the artist and passed along to subsequent versions of the model, low res or high res versions, keeping all of the data intact, allowing for scaling of the animation data if it's transferred to a different model entirely, even passing along worldspace location and orientation of parts of the model (and maybe even eventually the full animation) to other platforms like Houdini and Realflow.

It's a little important for what we're doing on The Curious Case of Benjamin Button, but the existing tools I developed are working ok there (even if they're still a little limited and occasionally awkward - they're getting better on a weekly basis).  There's already a small test of what I'm doing in a broader sense: we have a particular element with a moderately complex rig on it that I'm publishing and subscribing the animation data on.

The Big Goal for this tool will be on T4 which we should be working on soon.  That'll be a huge show and we've got some really epic-scale work on it: most likely we'll be needing the more sophisticated animation tools for managing our data throughout the pipeline - so that's what I constantly keep in the back of my mind as I script the current version of the tools.  They need to serve the current project in the most complete way possible, and they need to be able to expand to do more than I'd currently dream of asking them to do.

It's a lesson that's come up recently because of a little tool I wrote that I've mentioned here before "CurveBaby" - CurveBaby allows me to take a scene with an animated camera and one or more animated objects, preserve the camera's relationship to one of those objects but change that object's animation - or, conversely, reanimate the camera and have the animation of the object automatically adjust to still look the same from the camera.  It's a powerful tool, and one that I can barely imagine how I'd get through half a day without using it at least once.

Big tools make big projects go a lot more smoothly.