Article
Article
Article

Shotgun for Production Management in LAIKA’s Animated Features

Share this Article

LAIKA is a stop-motion feature animation studio located near Portland, Oregon. Autodesk’s Shotgun project management software has been used to organize and automate aspects of the production of all its feature films over the past 10 years, from Coraline to the forthcoming Missing Link. In this article, I will present how LAIKA tackles the design and manufacturing of the assets that show up on the big screen, how we use Shotgun software to track our production data (from scheduling to final delivery and beyond), and how we have built an efficient production pipeline using Shotgun as a platform. LAIKA exists at an interesting junction between visual effects and manufacturing, producing physical assets for a digital final product. As we go through our workflows, we will also reflect on the commonalities we have seen in how to create both physical and digital assets efficiently.

Introduction

Fueled by the vision of its President & CEO Travis Knight, the animation studio LAIKA was founded in 2005. Located just outside of Portland, Oregon, LAIKA was awarded a Scientific and Technology Oscar® plaque in 2016 for its innovation in 3D printing. All of LAIKA’s four films—Coraline (2009), ParaNorman (2012), The Boxtrolls (2014) and Kubo and the Two Strings (2016)—were nominated for an Academy Award® for Outstanding Animated Feature. Kubo and the Two Strings also won the BAFTA for Best Animated Film and received an Oscar® nomination for Visual Effects.

LAIKA’s next film, Missing Link, will be released April 12, 2019 by Annapurna Pictures. The film boasts a roster of international stars including Hugh Jackman, Zoe Saldana, and Zach Galifianakis. LAIKA combines the best traditional stop-motion artistry with cutting edge technology like 3D printing, robotics, and computer graphics to tell original stories in a way people have never seen before. This results in hybrid processes and a unique style.

LAIKA tries to capture as much imagery in-camera as possible, which means that we’re physically constructing much of what you finally see on screen, but nor do we shy away from making our movies as compelling as possible through digital artistry. Tracking both the digital as well as physical production of thousands of items from as small as a miniature button to as large as a 50-foot-square samurai castle set, and coordinating the efforts of all those people responsible, over the course of three to four years, is an enormously complex logistical operation for which there is no blueprint. To meet that challenge, LAIKA deployed and began investing in Shotgun in early January 2008:

EVENTLOGENTRY #2
Figure 1. EventLogEntry #2.

Now more than a decade later, LAIKA’s current production Shotgun site hit its 100 millionth EventLogEntry:

EVENTLOGENTRY #100,000,000
Figure 2. EventLogEntry #100,000,000.

Shotgun provides a customizable user interface on top of a powerful and scalable data storage back-end, with capabilities for integration into other systems. This allows Shotgun to appear as a collaborative media wrangling tool to artists, while also a task and resource scheduling system to coordinators and managers, and yet again as a tracking dashboard for department heads and executives, all in one. Over the years and the movies, our use of Shotgun’s features has continued to expand into more and more of LAIKA’s workflows.

So, “how do we make a movie?” In the beginning, there’s just a concept: of some characters, in some locations, and something happens. Developing and producing a stop-motion feature film is like the oft-repeated joke: “how do you eat an elephant? One bite at a time.” Let’s start by looking at the elephant-eaters, who are all represented in our Shotgun install.

The Players

There are top-level Departments, such as Art, Puppets, Rapid, VFX, Animation, and more. Within these Departments are the sub-departments, what we call Shops. These include the Set Shop, Model Shop, Scenic and Paint within Art; Armatures and Molds and Hands in Puppets, and many more. We use Shotgun’s Home Department entity for the top-level departments, and its Group entity to represent the shops within:

LAIKA DEPARTMENTS IN SHOTGUN
Figure 3. LAIKA departments in Shotgun.

 

SHOPS WITHIN DEPARTMENTS
Figure 4. Shops within departments. 

Departments and Shops Workflow

Like any large-scale construction effort, our production process is simply that each Department takes a chunk and iteratively breaks it down into smaller pieces, with increasingly specialized teams taking the pieces further, until the final product is assembled. That flow looks like this:

Departments and shops workflow, color-coordinated with Shotgun
Figure 5. Departments and shops workflow, color-coordinated with Shotgun.

Generally speaking, every arrow in the diagram represents Shotgun “workflow” entities like Tasks and Notes, while the ovals are “products”, represented by other Shotgun entities such as Sequences, Shots, Assets, and Versions. Every Department follows the same basic flow:

Concept  Look Dev + Design → Prototype + Previz → Build → Deliver + Maintain

You could think of the data in Shotgun as a giant web of connected things. The connections in the web are “fields” that point to other types of things or data. Sometimes the connection only goes one way → and can only link to a single thing (a Shot can only be in one Sequence for example), while other times, the connection is two way ↔ and can link to multiple things (a Version can be in as many Playlists as you want). We make pages in Shotgun to see pieces of that web. The pieces of the web are the things each workflow produces and the schedule of resources required to produce those things. Each Department, and often each Shop within a Department, has pages that model their workflows and represents how they connect to others.

Asset hierarchy - sets

 

Asset hierarchy - characters

We need to track the resources and schedule the activities to produce them, which are then required by other scheduled activities – ultimately to produce the approximately 150,000 images that make up the movie. Those activities are represented by Shotgun Tasks. Let’s start talking about Tasks with the most basic ways we group and create them.

Shotgun Pipeline Steps

A Pipeline Step in Shotgun is a grouping mechanism – it’s a way to collect and relate a bunch of Tasks and ask questions about them as a group, like what’s the earliest one, what’s the latest, what percentage are complete, etc. In most primarily-VFX studios, a Shotgun Pipeline Step is often used to correspond to what we call a Shop – so they might have a Modeling Step, a Layout Step, a Rigging Step, a Surfacing Step, etc. With the number of Departments and Shops we have at LAIKA, we felt per-Shop-steps was a bit too granular. So, we correspond a Department to a Pipeline Step, then delineate Shop-level Tasks using the Task ‘Type’ field or a custom field “Assigned To Shop.”

Shotgun Task Templates

Shotgun supports creating Task Templates, which create a set of default Tasks when a Task Template is applied to a product-type entity. We make extensive use of Task Templates for creating Tasks that get automatically linked to Shots and build Assets.

Pipeline steps and task templates
Figure 6 (left). Pipeline steps. Figure 7 (right). Task templates.

The Process

Every movie starts with a concept. That concept gets refined over what can be a long time – months or even years – during which preliminary designs are developed and a script gets written. While LAIKA tracks a certain amount of that early development process in Shotgun, herein we’ll skip ahead to green-light: the point at which the production departments are told to get started and make the movie. The process after green-light can be summarized as:

Scoping → Bidding ↔ Scheduling ↔ Producing ↔ Tracking

Scoping

Some initial assumptions have to be made and some analysis performed. Typically, this starts with the script. Scripts at LAIKA have been both sourced externally and developed internally.

Basic Assumptions

90 minutes of screen-time (movie length)
Approximate pace of 4 seconds of screen-time by one animator per week. So let’s do some quick math: 90 minutes = 5,400 seconds / 4-per-week = 1,350 person-weeks!
Approximately 2 dozen animators
Approximately 2 to 3 shooting stages per animator
90 weeks of animation and shooting, also known as Production
“Some” number of weeks of pre-production: building physical and digital components that must be ready for animation and shooting to begin
“Some” number of weeks of post-production: finishing CG work and marketing

Script Analysis

We require scripts in Final Draft format and with a certain set of naming conventions for scenes and characters and locations. The conventions and open XML format enable integration with Shotgun right away, with a tool we’ve written called script_splitter. script_splitter is written in Python and relies on Shotgun’s API.

SCRIPT_SPLITTER IS COMMAND-LINE ONLY, NO GUI
Figure 8. Script_splitter is command-line only; no GUI.

Functionally, script_splitter is very important, because what it does is extract all the Sequences, Scenes, Characters, Locations and Sets, and even DialogLines, from the Final Draft script and create all those entities in Shotgun, relying on those established naming and typing and link conventions. Before running script_splitter, the Production Technology department simply creates a Project entity in Shotgun, to which everything else will get attached.

The characters and sets at this point are Shotgun Assets, and are considered the “conceptual” entities – database entries to which we’ll publish concept, design, and reference artwork.

Broad Strokes Schedule Estimate: “The Oneline”

With these initial conceptual entities now in Shotgun, we can start planning the work. In this estimation phase, we use the script’s Scenes as a measurement entity. We create essentially a single start-and-stop schedule for each Scene, which we represent in Shotgun with one Task per Scene. We call these Tasks, and set their Shotgun Type to, “Oneline” Tasks, simply because each Scene gets represented on one line. These Oneline Tasks are created with another command-line tool, named cleverly enough create_oneline_tasks. The essential features of Oneline Tasks are as follows:

1. Schedulable – they have start dates and durations and end dates;
2. Required resources can be attached to them – “this scene requires Kubo and Monkey in a cave, that scene requires the evil sisters on a boat," etc. 
3. Support the other resources required, such as “generic” scheduling animators (“bot” HumanUsers) and the shooting stages, called Units, which we represent with a Shotgun CustomNonProjectEntity.

The duration of a Oneline Task is calculated as a proportion of the length of the scene in the script using the animation pace assumption. In other words, we calculate a simple ratio: ”this scene covering 1 page in the script will take 12 weeks to animate and shoot.” script_splitter uploads the page length of a scene to its Scene entity in Shotgun, then create_oneline_tasks calculates each Oneline Task Duration from its correspondingly-linked Scene’s page length. Oneline Tasks are Linked to their Scenes with Shotgun’s default entity field.

Production Management’s job then is to distribute these Oneline Tasks over the estimated 90-week shoot onto our available shooting stages, in such a way that the animators are kept fully busy and yet the number of instances where we would have to duplicate a physical character or set or prop or RP face-kit are minimized. The outcome of this Oneline creation process gives the other departments the deadlines they need to hit – the dates on which the first build of each physical asset must be ready. In this way, we’re creating an estimated shooting schedule so as to employ Just-In-Time planning for the assets to be constructed.

ONELINE TASKS FOR KUBO AND THE TWO STRINGS
Figure 9. Oneline tasks for Kubo and the Two Strings. 

The Oneline also shows how many actual Builds of any given Character or Set will be required. Unlike a CG asset, a physical asset can’t be in two places at once. So, viewing the Oneline in a Gantt view and doing overload-analysis on the resources connected to those Tasks tells us the number of physical first-builds and duplicates we’ll need to make, which become the required resources for finer-grained scheduling later. In Kubo and the Two Strings, because Kubo is the hero and thus in almost every scene of the movie, we had to build nearly 30 Kubo puppets! We represent the physical products with Shotgun Assets, with yet more Asset Types: “Puppet Builds,” “Set Builds,” “Rapid Cores,” and “Rapid Faces / Face Kits.” In fact, everything we build, practical or digital, is represented in Shotgun by an Asset entity and distinguished by its Type field. Thus, we make extensive use of Shotgun’s Detail-Pageper- Asset-Type feature.

DETAIL PAGES FOR THE 'SET' AND ‘CHARACTER’ ASSET TYPES
Figure 10. Detail pages for the 'set' and 'character' asset types.

Now the builders need to estimate their workloads to meet those deliveries and dates.

Tony Aiello's career has centered around hardware and software systems development and integration, with a particular focus on human factors and usability. Having previously applied these skills in defense R&D, then machine vision and industrial automation, for the last decade he’s been living the dream in feature films, with production technology credits on Coraline, The Boxtrolls, and Kubo and the Two Strings. As a senior engineer in LAIKA’s Production Technology department, he’s been building production management systems, many of which have involved pushing Autodesk’s Shotgun to new extremes.