LAIKA is a hybrid stop motion/CG animation studio located near Portland, OR. Fueled by the vision of our President and CEO Travis Knight, we create original feature films that push the boundaries of animated filmmaking. Our five releases so far are:
Missing Link (2019) Kubo and the Two Strings (2016) The BoxTrolls (2014) ParaNorman (2012) Coraline (2009)
In addition to critical and popular acclaim, every one of our films has been nominated for the Academy Award for Outstanding Animated Feature. Our most recent film, Missing Link, also earned a Golden Globe for Best Animated Motion Picture.
Creating our films is a massive undertaking. Stop motion animation requires the creation of thousands of sets, props, puppets, and costumes that must both express the creative language of the film and be able to be rigged and animated in painstaking frame-by-frame detail. Perhaps even more daunting is the challenge of coordinating work between our fabrication groups to ensure all our assets fit into the same world and are delivered to the appropriate stages in time for their moment in the spotlight.
Now, on to the part where we talk about scheduling.
LAIKA’s Scheduling Needs
To manage the ever-increasing complexity and collaboration in the creation of physical assets for our hybrid stop-motion/CG feature films, an integrated browser workflow was developed that enables automated resource leveling and scheduling in a centralized system accessible to the entire studio. Highlights include a new custom charting application that integrates with the existing ShotGrid (formerly Shotgun) creative project management software infrastructure, as well as the use of ShotGrid's generative scheduling, an automated resource-leveling system that effectively balances and assigns resources. Together, they turn a time-consuming and error-prone manual leveling process into a fast and automated procedure that generates an accurate, adjustable, easy-to-communicate schedule.
The schedule is an essential part of enabling LAIKA’s intricate filmmaking machine, involved in:
1. Getting the right resources for the work—First, it helps us get the right resources for the production, and ensure we’re hiring an appropriate number of people with the right skills.
2. Prioritizing work—Second, it provides prioritization for our work. Knowing what is due when, and who should be working on what, lets us make a movie as efficiently as possible.
3. Communicating effectively—Third, the schedule is an important communication tool. As our films have grown in complexity and scale, communicating work within and between departments has become more of a challenge. An effective schedule can help departments (and shops within the departments) know how their work integrates with LAIKA as a whole.
The Ideal Schedule
1. (Reasonably) accurate, with room to accommodate the unexpected—The schedule should contain all the required work for creating assets, with a bit of wiggle room for when estimates prove to be incorrect.
2. Encompasses all important information—The schedule needs to include all relevant information for decision-making. If important variables for making scheduling decisions exist only in certain people’s heads, or only in spreadsheets, the tools can’t be effective.
3. Easy to adjust—It should be easy to make adjustments to the schedule, both for recording actuals, and for making broader changes as processes change, or new creative choices alter build schedules.
4. Easy to communicate—The storage format must make it easy for users to slice and dice the schedule to see just the parts they’re interested in, whether that’s a PM summarizing schedules for a company-wide overview, or an artist looking for just their Tasks.
In short, what we’re aiming for is a much less sinister version of the Standard Oil Octopus (but like...a friendly octopus?)—one centralized brain providing information to every department at the studio.
Our previous scheduling solution utilized Microsoft Project to create task templates (lists of tasks and relationships between them) that defined the work plan for different types of assets.
For example, the first puppet we build for a character will typically include some research and development tasks, like creating costume patterns and defining fur and hair structures, so we'll create a "First Build" template for that work. After we complete the initial build, we often build duplicates of the puppet so that it can be used in multiple shots simultaneously.
For the duplicates, we don't need to include research and development tasks. We know what the puppet will look like and how to build it, so the list of tasks can be significantly shorter, and for that we make another template called "Dupe Build."
Once we've designed the different types of task templates required, we assign the task templates to builds.
For example, say we need to build three puppets of Sir Lionel, from Missing Link.
The first one we build will be assigned the "First Up Build" task template, and the other two are assigned the "Dupe Build" template.
Sir Lionel (1) - First Up Build
Sir Lionel (2) - Dupe Build
Sir Lionel (3) - Dupe Build
In addition to varying task lists based on build type, we also required users to mark a 'complexity,' which defined the duration of each task in the task list. This extra flexibility gave users a systematized way to vary durations for assets that should share the same task list, but might need more or less time to complete each task.
These templates were then combined with custom per-asset durations from an Excel spreadsheet, put back into the project to be auto-scheduled, then finally exported via a custom app to ShotGrid.
Bid workflow in steps:
Determine asset quantities and delivery dates
Make MS Project Task Templates
Make a 'complexity doc' in Excel
Bid assets in Excel
Combine Task Templates and Excel bids, and import into MS Project
Open MS Project, run the auto-scheduling
Export from MS Project => ShotGrid
There were some major limitations to this process, including:
1. Cumbersome roundtrip—First, the roundtrip process was cumbersome. Initial bidding often took weeks, and data in project and ShotGrid could easily get out of sync when doing updates.
2. Limited modeling capabilities—ShotGrid's auto-scheduling features were limited, with no support for the complex dependencies needed to accurately model a detailed production schedule (significant strides have been made in the latest releases of ShotGrid, so keeping all the dependency info no longer requires a custom table).
3. Visualization—ShotGrid also didn't have sufficient resource visualization tools - users struggled to see what resources were overbooked, and what wouldn't deliver on time.
4. Manual resource leveling—The resource leveling process was entirely manual. Hand-leveling such an enormous dataset lies somewhere between laborious and impossible; every push or pull in the order of tasks to benefit one group tends to come at the expense of every other group, with few easy solutions.
Perhaps even worse, the moment a hand-adjusted schedule was completed, anything from daily changes in the shooting schedule to R&D taking longer than expected to story changes could make it obsolete.
5. Actuals—All of the above issues led to situations where no one trusted the schedule from ShotGrid, so no one maintained it, which meant the data is never right and we have no useful data to use for forecasting future shows.
Without effective tools to evaluate and adjust the schedule to accommodate changes, craftspeople ended up overworked or assets delivered late, which slowed the pace of shooting and made it harder for downstream departments (rigging, camera, animation, and visual effects, e.g.) to meet their deadlines.
Design and Development
The goal of this project was to develop a new scheduling system that would work studio-wide and enable faster iteration, as well as better resource visualization and leveling.
The first part of our process was developing data modeling tools so we could capture all the information our users needed to build an effective schedule.
Data Storage: ShotGrid as Backend
We were already heavily invested in tracking, reporting, and distributing scheduling information with Autodesk ShotGrid, so we decided to follow a progressive enhancement strategy, building new features and workflows on top of our existing database and UI.
This had several advantages:
1. Existing tracking / reporting tools still worked
2. Filtering / statuses / assignments / adjustments can be performed in familiar UI
3. Minimized scope creep
We wanted users who were familiar with the ShotGrid UI to still be able to use it when it was effective, then switch to our custom tools when they needed extra features like auto-scheduling and leveling. This also minimized scope creep: we weren't trying to reinvent ShotGrid, just improve its scheduling features.
The first step was building an app that would enable users to capture all the complexities of a production schedule. ShotGrid’s built-in data models weren't sufficient for this, so we created a new database schema on top of ShotGrid's existing scheduling infrastructure, then customized a third-party Gantt component from Bryntum to be able to edit, auto-schedule, and save task information back to the new schema.
With the new Gantt component, users can select one or more entities and launch into a custom schedule editor, with just the feature set required for editing and syncing tasks directly to ShotGrid.
All the standard project dependency types (FS, FF, SS, SF) are available, as are typical scheduling constraints and offsets.
To ensure correct auto-scheduling without giant data payloads, we parse the dependency trees for the selected entities at runtime, and load just the data required to correctly schedule the user's selection.
With the Gantt component and custom schema in place, users can edit their templates and production schedules in the same application, with full access to auto-scheduling features like dependencies and constraints.
Even better, this data is synced directly with ShotGrid, so all of our existing infrastructure for task assignments, navigation, and reporting is still usable.
Custom Data Model
* Indicates a non-ShotGrid-native field / table
Tasks: A Unit of Work
Duration - duration of task in calendar working days
Headcount* - utilization of a resource assigned to this task (0.5 = 50% utilization)
Working Days* - total resource utilization (Headcount * duration)
Assigned to Shop*
Link (which Asset, Shot, or Task Template they’re associated with)
Defines a relationship between two tasks.
Destination Task (predecessor)
Dependency Type (FF, FS, SS, and SF...“the useless one”)
Holds a set of Tasks and dependencies to “stamp” onto another entity.
A physical or digital asset. For each department, we’ve developed a unique hierarchy of assets to help organize the work to be done.
Art Hierarchy: Location / Set / Set Build / Set Parts
Puppets Hierarchy: Character / Puppet (Design) / Puppet Build / Puppet Subasset
Rapid: Character / Rapid Character / Variant
Fields (if used as resources like positions)
Delivery Date (“Earliest Oneline Block” in LAIKA parlance)
Consilium Scale In*
Consilium Scale Out*
A shot for the film.
An employee’s job at LAIKA; defines what work will be assigned. This data is ingested from Production Accounting so that the list of positions matches up to the list of LAIKAns available.
Consilium Scale In
Consilium Scale Out
Max Workload - maximum utilization (may be less than / greater than 1)
Assignment Positions - indicates other equivalent positions that can be used when distributing work after leveling
A space on our stages that can be used for filming a scene.
A record of a person.
The Bid Process
With the schema and Gantt app ready for use, it was time to move on to updating the bidding process. We felt our bidding approach, where users defined task templates and complexities for assets, was still effective so we worked to maintain those conceptual models while streamlining the bid process.
In our new workflow, users create task templates directly in ShotGrid, and can assign and edit task template and complexity assignments in a new bidding app, which updates production schedules directly. This new bid process is entirely in-browser, with all data stored in our custom ShotGrid schema.
Want more? Download the full class handout to read on.
Michael Nowakowski is a pipeline technical director at LAIKA. He focuses on studio workflows related to scheduling, fabrication, and asset organization.
To manage the ever-increasing complexity and collaboration in the creation of physical assets for LAIKA's hybrid stop-motion/CG features, a Shotgun-based integrated browser workflow was developed that enables automated resource leveling and scheduling in a centralized system accessible to the entire studio. Highlights include a new custom charting application that integrates with the existing Shotgun infrastructure, as well as the use of Consilium Technology (recently acquired by Autodesk), a...