The Digital Eye: MPC's R&D Confronts a Changing Industry

In this month's issue of "The Digital Eye," Rob Pieké explores the inner workings of R&D at London-based MPC, where ALICE, Furtility, PAPI and Tickle reign.
Posted In | Magazines: VFXWorld

The R&D team at MPC, which has achieved great success in recent years with its technologies for crowds (ALICE), fur (Furtility), dynamics (PAPI) and lighting (Tickle), is now confronted with a whole new set of industry challenges, ranging from shrinking schedules and budgets to globalization.

First formed in 2001, when the company had roughly 50 employees in the film department, the R&D team reached a peak size of 40 in 2007, servicing MPC's 680 staff on everything from project setup to pipeline to artist tools and support. The company has now roughly leveled off at a total head-count of 450, and is in the process of restructuring our previously monolithic development department into more manageable and versatile pipeline and R&D teams.

Core Technologies
The R&D team develops and supports software at three levels. At the lowest level is a core set of C++ libraries designed to consolidate as much reusable technology as possible. Three years ago a significant amount of the source code in our Maya plug-ins dealt with generic geometry processing routines. Centralizing this technology has resulted in a single maintainable geometry processing library that all tools can use, and has greatly reduced the amount of duplicated code throughout our plug-ins.

We use a number of third-party and open-source technologies, where appropriate to our development, but try to integrate them at a very low level in our core. This enables us to provide an interface such as mpc::Thread to a developer working on an artist tool without them having to worry about whether they're ultimately using Intel's Threading Blocks, NVIDIA's CUDA or an in-house technology. Furthermore, it allows the developers working on the core to swap out one low-level technology for another without the entire R&D team having to perform a major overhaul on every higher-level tool. We have successfully exploited this capability both ways in the recent past: swapping out in-house technology for an open-source project which had recently matured significantly, and swapping out a third-party project for in-house technology when we realized we were pushing the technology in a direction it wasn't designed to go.

Compiled Artist Tool
Our second level of technology is the suite of compiled artist tools. These make use of the core libraries and account for the majority of our technology where speed is a chief concern or there is no other interface to one of the dependencies. Technology at this level is often both directly accessible and wrapped so that it can be used by even higher-level tools.

While the majority of our technology is able to operate in isolation, we continue to use Maya as a framework which we can hook our tools onto. This provides the artists with a familiar interface and allows us to use Maya's technology to supplement our own when needed. One of our core libraries allows for the seamless translation of data in Maya's format to and from our own native format. We can then focus our efforts on achieving the required functionality of our artist tools without having to worry as much about whether they will end up interacting with Maya or not.

An example is our crowd technology, ALICE, which was originally developed for Troy. In recent years, ALICE has moved away from its dependence on Maya, but still provides a MEL binding to all the functionality and a MEL event framework to specify procedures which will execute at key points in a simulation. Using PyQt, we have built an interface that runs both inside and outside of Maya and allows TDs to build complex behavioral state machines by connecting "agent operators" in a node graph. These operators take ALICE beyond simply blending motion clips and allowing it to synthesize completely new motions to handle footfalls on uneven terrain, aiming heads, transitioning to and from physics simulations, etc. We still prefer to rely on motion clips where possible, but the result of an operator graph may be the blending of many clips, not just two. Our "additive" operator, for example, can isolate animation such as walking or clapping from a set of motion clips and combine these bits to generate the output. At the time ALICE was first developed, there was no viable off-the-shelf alternative (to serve our particular needs), and given how far ALICE has grown, we feel it is still a better solution for MPC than anything we could buy today. It has worked remarkably well for simulating crowds of elves, medieval armies, birds, bats, drowning people and mammoths to name a few, and plugs seamlessly into our pipeline.

Scripted Artist Tools
The third level of technology is our suite of scripted artist tools. We have made it very easy to wrap our compiled tools using Giggle, our language-independent script binding technology, so that they are accessible from Lua and Python. This allows for a very rapid development cycle for new tools at the possible expense of reduced execution speed. We routinely develop new technology using script first and re-implement in C++ only if necessary. With full access to all our lower-level tools, the scripting interfaces are sufficiently appealing and accessible to the point where a number of TDs are developing their own tools this way.







Comments


KnZGMZ (not verified) | Mon, 08/29/2011 - 03:46 | Permalink

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Use <!--pagebreak--> to create page breaks.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.