One Student at a Time
An underground, open-source project gives students experience before entering the studio.
Animation students face many challenges as they prepare to enter the workforce—one of the most obvious is the lack of experience working in a studio production pipeline. For studios juggling tight deadlines and even tighter budgets, this issue can oftentimes be a deal breaker when it comes to landing the job. Time spent training an artist or an animator is essentially money left on the table, and in these trying economic times, few studios are willing to make the sacrifice.
However, an underground, open-source project, which began in 2006 and has been consistently gaining momentum over the years, is providing students with the tools they need to work in a production pipeline long before they ever set foot in a studio.
Pratt students have used the school’s production pipeline tools to create their projects, including George Smaragdis’ “Scrimshander,” shown here.
If You Build It, They Will Learn
Several robust production pipeline applications, such as Temerity Software’s Temerity Pipeline or Avid’s Alienbrain, are commercially available, but unfortunately, many schools do not have the means to acquire, maintain, and support these types of software programs. Necessity spurs invention, and the concept for OpenPipeline, an open-source framework for the management of animation production data and workflow, was born.
Conceived at Eyebeam Art and Technology Center, a majority of the OpenPipeline development took place at the Pratt Institute Digital Arts Research Lab and is currently being maintained and updated at Kickstand, an animation research and development studio in New York City.
The OpenPipeline project was essentially developed to emulate the production pipeline found in a studio environment. To implement and test the software specification, a working prototype was developed for Autodesk’s Maya. The development guidelines were straightforward: create a code base in MEL (before Python was available), eliminate the use of external databases, applications, executables, or libraries, and provide cross-platform compatibility. While OpenPipeline was primarily developed at the Pratt Institute, many individual users and studios have made invaluable contributions to the evolution of the program by providing feedback, suggestions, and, in many cases, code.
OpenPipeline begins with concept development and ends with project output. The students at the Pratt Institute Department of Digital Arts also use PipelineFX’s Qube render management solution in their production pipeline. Student projects at Pratt, such as Vadim Kiyaev’s senior Capstone Project, and MFA thesis films by graduate students Paris Mavroidis, Alek Vacura, and George Smaragdis, have all benefitted from access to production pipeline tools and the added flexibility to make creative decisions and enhance the project at a late stage.
Features Deliver Results
OpenPipeline offers asset management, revision control, user notes, and scene population and management capability. The asset management feature allows you to name, store, retrieve, and associate information with data. If, for example, you create an asset called “bob” of type “character,” it will automatically be saved to /lib/character/bob. This file structure easily archives and delivers the asset, removing the guesswork of where it should be saved in the directory structure. Revision control keeps track of the edits to a file and incrementally saves the file, instead of overwriting it with each save.
User notes and information are associated with the file, including who saved the file, and the interface allows a person to browse through previous versions and revert to a file if necessary. Scene population and management features offer an overview of sequences, shots, shot components, and the ability to import or reference assets or shots. Scenes are also handled like assets with an automatic naming and storage path.
Users have the ability to define assets, asset types, and asset components, along with sequences, shots, and components in OpenPipeline. As these are created, a logical director structure is built. Once everything is in place, users rarely have to use the standard “open” or “save” functions—OpenPipeline automatically manages, saves, and correctly names files. A centrally defined script path allows users to share project data and interact with the same production tree using shared OpenPipeline source code; any changes or updates made in the system propagate to the users instantly. Users can see a bird’s-eye view of the project’s assets by using thumbnails and playblasts. A large amount of data is stored externally to Maya in XML files, which allows for easier integration with other visualization packages.
A “sandbox” structure forces users to publish assets into the production pipeline—referencing allows users to work with a file that resides outside any live connections to the production, and when ready, a new master file is published with updated information. Every asset or shot in OpenPipeline follows this model, which is common protocol in production studios, thereby protecting unwanted changes from propagating down the pipeline. Group projects benefit from a system that manages assets as they are created and edited by disparate users at different intervals. An added benefit is that users have a neatly organized directory structure that can be easily archived or delivered.
Over time, high-level tools have been added to OpenPipeline that are designed to appeal to producers and directors who want to see the current state of the output. The recent addition of “add-on” support to OpenPipeline allows users to create Maya plug-ins that test and complement OpenPipeline’s functionality and existing code base. Another recent feature, which was suggested by multiple users, is the addition of automatic playblasts as a preview format. This allows users to take a snapshot of a shot’s status without having to open the file.
Code that Keeps On Giving
OpenPipeline is an ongoing project, with a 1.0 version scheduled for release this month. Future plans call for more integration with the texturing and rendering pipeline, and more add-ons to support user- or studio-based preference operations in Maya using OpenPipeline.
Several studios currently use OpenPipeline with Maya—either straight out of the box by downloading the free MEL scripts, or modifying it to suit their particular needs. Kickstand is also creating customized versions of the tools for animation and visual effects studios, and whenever possible, is adding customer-requested features back into the public source code.
OpenPipeline began as an experiment to produce an easy-to-use production pipeline. It has since evolved into a serious tool for managing the production pipeline and teaching production asset management in the classroom.
OpenPipeline currently supports Autodesk Maya. To download the OpenPipeline source tree, visit the SourceForge Web site at
http://www.openpipeline.sourceforge.net/.
Rob O’Neill has been involved in many professional production pipelines throughout his career, including that for DreamWorks Animation’s Shrek 2 and Madagascar. He is currently executive producer at Kickstand in New York City, and serves as director of research for Digital Arts Research Lab at the Pratt Institute.