“openPipeline: Teaching and Implementing Animation Production Pipelines in an Academic Setting” by O’Neill, Mavroidis and Ho
Conference:
Type(s):
Title:
- openPipeline: Teaching and Implementing Animation Production Pipelines in an Academic Setting
Presenter(s)/Author(s):
Abstract:
Organization and collaboration are key components to creating a successful animated film. Every studio implements a pipeline for how they will complete their film both from the point of view of planning and scheduling, and how they will manage their data across the length of production and across artists. The openPipeline project is an attempt to create a production pipeline framework specification and tool set to both educate and empower student and independent animated film production. Students often overlook issues such as production trees, automatic file naming, revision control, collaborative notes, and scene population. These ideas are all critical components to commercial production studios and valuable to the student and independent production.
A production tree is the organization of assets needed to create the film. This is defined early in the planning stages and lays out the folder hierarchy where assets are stored to eliminate confusion and to define data storage in predictable locations. Automatic file naming is the automation of asset and asset revision naming by the production system. This reliance on the pipeline lessens the chance of misnaming an asset and allows the artist to focus on the work needed to be done. It also automates the flow of data down the pipe. Similarly, revision control is the key to working in a nondestructive manner. Each time an artist saves an asset it does not overwrite the current file, but actually saves a new file with an incremental value. Overwriting a file on disk runs the potential of losing data and corrupting the file if the system crashes while saving. Incremental saving eliminates that possibility at the expense of a larger file space requirement. openPipeline also implements the notion of artists working in a sandbox (called the “workshop”) and only mastering (ie: publishing) an asset when it is ready for the rest of the pipeline. This insulation allows an artist to work independent of the active pipeline. Each asset directory is composed of the published asset file and sub-directories for notes, workshop, version files and asset components. Communication needs to be tied to the asset so that artists may work simultaneously and alternately on components of the project. With this in mind, collaborative notes are associated with every save of an asset in openPipeline. Every save records the user’s login, the date and time of the save, and the type of save (workshop or master), in addition to providing the opportunity for user notes.
The final step is the act of scene population, which is where the artist loads the required assets into the production scenes for animation, lighting, and rendering. In addition to basic asset referencing, we have also implemented a means of getting a scene inventory. Like the asset library list, the scene inventory provides a bird’s eye view on the work in progress without needing to open every file. The openPipeline framework proposes a structure for all of these ideas.