Shotgun for Production Management in LAIKA's Animated Features

TONY AILELO: OK. Hey, everybody. I think we're going to get started if that's all right with you. How's it going?

Everybody have a good AU so far? Great. Any of you seen any LAIKA movies before? Few of you-- very cool.

So by show of hands, who here has used Shotgun before? All right, good half of folk hopefully there who's here to just learn about it? Good, good, good, good.

And who's here just because movies? Now, I know-- everybody. That's why I'm here too. OK, so let's go on.

So I'm Tony Aiello, and you can read my bio up there if you like, but I want to tell you more about why I'm here. Before LAIKA, I spent years and years and years building automation systems for factories-- hardcore industrial automation. That was from semiconductor chips to potato chips, from cars and trucks to cookies and beer. But after a while, I really wanted to be part of a different type of creative project.

And so when I first heard about LAIKA, I spent six months begging them for a job pretty much. And I wanted to start actually at entry level, but they hired me as a software manager for some reason. I didn't even know that movie studios had software managers. So I was surprised when it turned out that many of the best practices and processes from factory automation actually carry right over into movie production-- even though the movie folks didn't realize it. Then when I got into Shotgun development at LAIKA, I realized that here was a tool with which you could model process much like you might use another Autodesk software package to model a car or a building or something.

So that overlap between processes and Shotgun's role in it is really why I'm here today. And what I want to talk to you about. I do have a lot to show you.

So let's try to save questions until the end I'm also going to be here after the talk as well. I got nothing going on afterwards-- so plenty of time.

But first, a bit about LAIKA. We are an animation studio located in Portland, Oregon, founded in 2005. Excuse me. We've released four films so far, with a fifth one coming soon. All of our films have been nominated for Academy Awards for Best Picture-- Best Animated feature, I should say.

In our last film, Kubo and the Two Strings, also got a nod for best visual effects and won England's equivalent of an Oscar, the BAFTA. LAIKA combines the best traditional stop motion animation artistry with cutting-edge technology like rapid 3D printing, robotics, computer graphics all to tell original stories in a way that we hope people have never seen before. This results in hybrid processes and a unique style.

LAIKA tries to capture as much imagery as we can in camera as possible, which means that we are physically constructing almost all of what you see on the screen but normally shy away from using digital artistry to make our movies as compelling as possible. Tracking both the digital and the physical production of items from as small as a miniature button to as large as a 50 square samurai castle set is an enormously complex logistical operation, taking over three to four years and hundreds and hundreds of people.

To meet that challenge, LAIKA deployed Shotgun in early January of 2008. And there's event log entry number two and now, more than a decade later and a year-- almost exactly a decade later, where this is our primary production site. We actually have multiple Shotgun servers, but this is the primary production server that has most of the movies on it now.

100 million event log entries-- so we've used it a bit. In this talk, I'm going to cover a wide range of aspects of Shotgun of LAIKA that Shotgun has touched. And we're going to dive deeply into a few areas.

So how do we make a movie? Maybe that's what you're all wondering. In the beginning, it's really simple. It's just a bunch of characters, and they're a bunch of places, bunch of locations, and something happens. And that's it.

Producing a feature-length movie in stop motion is an entirely different story. It's like the joke that-- if any of you have been at Autodesk, you probably pretty heard it-- how do you eat an elephant? One bite at a time. Ha, ha, ha-- OK. Let's look at the people that eat the elephant who are all represented in Shotgun at length.

These are our top-level departments, and you've got stuff like art, animation, puppets, VFX, rapid, editorial, all that stuff. We use Shotgun's home department entity for these. And I'm way down here in production technology-- prod tech for short. So if you hear me say prod tech, that's what I mean. I'm talking about my department.

Within the departments are what we call shops. These include things like the set shop, the scenic shop. Over in puppets, you've got costumes and hair and mold-- all these.

Many, many more shops-- you can see all this stuff. So we use Shotgun's group entity to represent the shops. So you get department entity and group entity within the departments.

That's the laser pointer. That's not the clicker. Like any large scale construction effort, the process is simply that each department takes a big chunk and breaks it down into smaller and smaller pieces with increasingly specialized shops taking the pieces further until the final product is all assembled. And that flow looks like that.

The important thing on this is to realize that the arrows represent, in every case, a Shotgun and workflow entity like a note or a task. Anything that you see is an oval is represented by a Shotgun product type entity like a sequence or a version or an asset. And I know that was pretty complicated.

But really, every fabrication department follows this same basic flow. We simply connect Shotgun, database entries, and make pages to visualize this flow, visualize a schedule and the products that come out of each workflow. The physical products again are represented by, like I said, primarily Shotgun assets.

We categorize the assets by types. The asset entity has a simple type field on it. So we have Puppet builds, set builds, rapid cores, face kits, et cetera, et cetera. And, in fact, everything we build-- practical or digital-- is a Shotgun asset with just a distinct type. As a result, again, if you've used Shotgun, you get to design custom pages on different asset types.

So you see here this is the asset type for a character, and it's got a completely different page design than the type for a set-- even though they're both still assets. So that's a really cool feature. We need to track the resources and schedule the activities to produce these assets, which are then required by shot activities, ultimately, to produce the hundreds of thousands of pictures that make the movie.

All of these activities are represented in Shotgun by a Shotgun task or many tasks. Let's start talking about tasks with the basic ways that we group and create them. [INAUDIBLE]

So a pipeline step in Shotgun-- it's simply a way just a group a bunch of tasks together. It's really all it is. What's cool is that you then get to ask questions about that group of tasks as a group. Like you could say, what's the earliest start date of all these tasks? What are all the resources required by this group of tasks? What percentage of those tasks are complete?

In most pure CGI studios, Shotgun and pipeline step is often used to correspond to what I talked about as shops. So they might have a modeling step and a layout pipeline step and a lighting pipeline step. But if you remember that slide a few slides ago, with all the shops and departments that we have at LAIKA, that was getting a little too granular for us.

So we map pipeline steps to departments-- one-to-one pipeline step to department. And then we make shop-level subtasks using the task type and assignee fields. Shotgun also provides task templates, which are really cool because you can create a set of default tasks with default durations when a template is applied to a product type entity like an asset.

Now as I said, this whole process starts with a very simple concept. That concept gets refined over what can be a period of months or even years. And we call this early development.

And that's when designs are getting developed, and the script is getting written. We do track a lot of that information in Shotgun as well. But in this talk, I'm going to skip right ahead to what happens at green light, and green light is simply the point at which all the departments are told, get started go make the movie. That's it.

The process looks a lot like this. We start with scoping. Scoping is where these initial assumptions about what we're going to make are made, and the content of the script gets analyzed. These are our basic assumptions. So let's go take a look at these.

We assume that we're going to be on screen for about 90 minutes-- 90 minutes. We're going to produce 4 seconds of screen time per animator per week of calendar time. We make an assumption that we're going to have about 24 animators, and we're going to have about 70 different units on which they are going to work. And we're going to do all that in 90 weeks of shooting.

Now, what's interesting-- let's do a little bit of math here. 90 minutes-- all right, four seconds per week is how many? 1,350 weeks for one animator.

And that's just animation and shooting. That doesn't include the years of the preproduction, building the assets and everything that has to be ready before you can animate and shoot them. It also doesn't include post-production, which is when we're finishing visual effects that started all the way back during production.

Now, we apply those assumptions when we analyze the script, which we require in final draft format and with some very specific naming conventions. And those conventions are really kind of important because what they let us do is integrate the script directly into Shotgun with the tool that we've written called Script Splitter. It's written in Python, relies on Shotgun's Python API, and again, it's extremely important because what it does is it takes all the sequences, the scenes, and the characters and locations and the sets and even the dialogue lines directly out of the script and pump them all straight into Shotgun, creating and linking them all together. For running scripts but are all we have to do in production technology is create the topmost level project entity in Shotgun. Then we point Script Splitter at the script and at the Shotgun project, and everything starts appearing magically.

Now, with all that in Shotgun, we can start planning the work. For estimating, we measure using the script scenes. There's about 130 scenes or so in a script. We create a single Shotgun task for each scene 1 to 1.

We call this oneline tasks just because it shows up on one line. I know very clever. So you're going to love out naming conventions. We do this oneline task creation with another project tool named cleverly enough create_one_line tasks.

And you've got very simple UI for this-- largely, because this is done by project. And we don't care about pretty UIs because we're not artists. Some of us are.

Oneline tasks are tasks. They have start dates, durations, and end dates. Our tools link the resources to the tasks.

This scene requires Kubo and monkey in a cave. You got your characters. You got your set. That scene requires the two evil sisters on a boat with a kusarigama for that insane-- fully hand animated battle scene that was insane. But the point is you've got all these resources that get hooked up to the oneline tasks like Script Splitter.

The oneline tasks also get other generic resources hooked up to them, such as to be determined animators-- again, representing those 24 animators that we were assuming that we're going to have-- as well as shooting units began because we have a plan that's worked out over where it's actually going to happen. We represent our shooting units by a custom nonproject entity in Shotgun. There's a lot of additional tables we get to create for ourselves.

Now, the duration of each oneline task is calculated directly proportional to the length of the scene in the script using the animation pace assumption. That sounds much more complicated than it really is. It's just this. You've got 130-page long script. It's supposed to be on screen for 90 minutes.

So you can do that. You can do that ratio of pages to screen time. You know you've got four seconds per animator, so you can figure out very quickly, very simple math. One page in the script is going to be 12 weeks of calendar time. It's that simple.

Script Splitter goes through that. It had already uploaded all those page durations into the Shotgun scenes. And so create_one_line tasks can just use that ratio for each one of those 100 or 30 or so scenes and create the appropriate calendar time duration task.

Production management's job is then to distribute these oneline tasks over the 90-week shoot schedule onto our available shooting stages in such a way that the animators and the crew are kept fully busy, but not overloading. That activity put start dates on the beginning of each one of these tasks. And what that does is basically that fulfills the first critical purpose of the oneline, which is to give the upstream fabrication departments the deadlines they need to hit. And as any of you familiar with factory automation, this is classic just in time production scheduling.

The second critical purpose of the one line is to help us minimize the number of physical builds of any given character asset that we have to make. Unlike a CGI asset, a physical asset puppet can't be in two places at once. So looking at the number of overlaps of any given character or resource on the oneline tasks tells us the number of duplicates that we have to make.

For example, in Kubo and The Two Strings, our last movie, Kubo is a hero, so he's in almost every scene of the movie. We had to build 30 Kubo puppets. I have a cool t-shirt with all 30 of them.

Now the builders need to estimate their workloads to meet those delivery dates we talked about. Every fabrication department like us needs to negotiate with the producer of the movie the time and the cost. So we've combined a lot of other tools with Shotgun to help them do that. Project provides every department with an Excel spreadsheet exported from Shotgun with all of the builds that they have to make listed down the side.

And I can't tell you any of the names of these people because they're all in the next movie. Across the top, there are columns for each shop involved with a complexity rating for each shop per build. So that's this collection the numbers here. So redacted one standard has these different complexity ratings for each shop.

Again, it's just a number from 1 to 5. That feeds into a subsheet and Excel file for each shop, mapping the complexity bid number to a set of bid durations for each task within the shop. So, for example, complexity one might mean two days of molding and three days of casting while the complexity of 5 might being weeks of that time in those shops. That Excel template just rolls all these duration values up into the shop tasks just by entering the complexity values.

This is a lot faster for the department heads than having to type all these day numbers over and over again. All they have to do is fill in complexity numbers. That's the wrong thing.

What did I just do? Here we go. All they have to do is fill in these complexity numbers. And then on a subsheet for each one of these-- what do we got, eight tabs here or so-- they fill in the default durations on that spreadsheet. Very quick operation.

Now for task templates-- as I mentioned earlier, the promise of the Shotgun and task templates is that when it comes time to create the actual tasks for the builds in Shotgun, the department would be able to just apply the appropriate task template with the default task durations to each build with a work breakdown structure-- that is, the task dependency relationships-- that are involved. Unfortunately, in our case, it's not that easy. Remember, the fabrication departments are building different complexities for each of the shops involved for each different build, which mean different default durations.

And as a result, the number of possible permutations of task template durations just explodes. So you can't do that. We needed a way to dynamically populate the actual durations of the durations from the task template at the time we put the task template on the build.

Also, Shotgun does currently have a couple of task scheduling limitations. It can only do finish to start relationships if anybody is familiar with Microsoft Project. Can't do start to start, finish to finish yet.

It also doesn't support percentage offsets. Like this task starts 50% of the duration between that task which, we often use to schedule milestones in check-ins and things like that. So this is where Microsoft Project comes in.

The dependency relationship of the tasks-- it would be nice if this was zoomed in-- the dependency relationships gets modeled in Project with just throwaway durations. There can be two or more Shotgun and project templates exactly matching each other representing different task structures. For example, the template for the first build of any given puppet often has lots of testing and approval milestones built into it. Whereas a duplicate build, you don't need to do all the testing approvals anymore.

You're just going to crank the work out, so we have a much simpler template for that. Then Project uses another app we wrote called Excel to Project to take the per build per task durations from the Excel spreadsheet and match them up with the task in the Project template.

And here's where it gets funny. It combines task relationships from Project-- your work breakdown structure-- with durations from Excel and the due dates from the oneline tasks that are already in Shotgun. And for each build, that output then gets run back through Microsoft Project again because Project has all that really complex state math and the work breakdown structure stuff, providing ultimately the full construction schedule for all the tasks.

But we're not quite there yet. Those tasks are still in Project. So the final step is to get them into Shotgun, which we do with yet another of our apps called project_to_shotgun. This reads the Microsoft Project file and programmatically creates and links all the tasks for each build in Shotgun, complete with their dates and durations.

And what you end up with after a few minutes is thousands of new tasks. These are rolled up. These are rolled up bars. Each department can then take over maintenance of their schedule exclusively in Shotgun to do the ongoing schedule adjustments.

Unfortunately, Shotgun on does make it easy to do that. You can very easily move blocks of related tasks and Shotgun on while maintaining their relative date relationships without having to worry about the dependency linkage. Adjustments will be necessary because, remember, all of this was based off of the one line dates, which are estimates.

The real dates required by the stage production for animation and camera are still to come from the process of shot scheduling. So let's talk about that. Oh, but before we talk about scheduling, we're got to talk about multiple scenarios.

What might the schedule look like if we change some assumptions? Like we're going to not build quite as many of these puppets, or maybe we're going to double the number of personnel. Or maybe we're going to change the numbers up hours in the day-- in other words, multiple scenarios. So, obviously, with Microsoft Project, this is as easy as just working in another copy of a file.

In Shotgun, well, the thing is we've become victims of our own Shotgun success. Nobody wants to work in Microsoft Project anymore. Even Project, we don't use it anymore.

So we needed a way to have multiple scenarios of thousands of tasks all within Shotgun. This isn't a natively supported feature, but it's actually not that hard to invent. For each department's pipeline step, we also created a duplicate step called planning.

So you get in our planning and [? Puppet ?] planning. Then we wrote another tool connected to a Shotgun action menu item, or AMI. You'll hear me use that term.

And what that planning tasks AMI does is it copies the selected real tasks onto the department's planning pipeline step. Links to the assets on those tasks are maintained, so you can still do that resource analysis. But we do remove the human personal assignments, so they don't get lots and lots of duplicate spam email notifications when a department plays with the planning tasks.

And so the department heads can then just adjust the planning tasks completely independently of the real tasks because they are completely different tasks. This system also supports more than one alternate scenario by using Shotgun's tags. So you could tag a set of planning tasks as standard one-hour days, or you might tag them as let's work 24/7. Or you might say let's just make the movie out of glue and popsicle sticks-- different options just by switching a tag in Shotgun's filter panel.

And finally, the great thing about this planning task action menu item is that it works the other way. You can then select the planning tasks that you've been messing around with, whatever scenario it is that you like, and copy them back onto the real tasks. And any orphan tasks that you threw away during the course you planning-- they get automatically omitted by this tool-- so quite a bit going on. Now, excuse me.

While the fabrication departments have been figuring out all these numbers of builds and developing their schedules, the story and editorial departments have been breaking down the sequences and scenes in the script into the actual shots. And that is the 200,000 to 300,000 pictures that we have to take. A shot is basically just a collection of pictures generally taken from approximately the same camera angle-- maybe a panorama zoom but the same camera angle. You change your angle. That's a new shot.

We break down those shots using storyboards. Storyboards are just still images representing the key action beats during each shot. Story department and draws them with Adobe Photoshop and manages them with Foundry's Flix software.

And we've integrated Flix with Shotgun by using custom entity 0 1. Right, Rob? And what's cool is that they're then kept in sync. Editorial cuts the boards into animatics-- videos of boards that have been timed to what will be real movie time like little mini cartoons. Shots in Shotgun are then created programmatically by editorial, simply publishing and animatic of an entire sequence, which is the set of scenes in a major storyline in the script.

LAIKA movies tend to be about 1,500 shots or so. And there's a lot of stage work to do for each shot. There's set dressing. There's rigging. There's lighting. There's rehearsals.

There's the actual hero animation, of course. There's additional camera passes for VFX. There's multiple exposures for HDR, all and more.

So the number of stage tasks-- here's the point. To actually produce shots is very significantly higher than the number of oneline tasks-- 130 or so oneline tasks. Production management is responsible for scheduling all those stage tasks as well as maintaining that schedule to make sure they all get complete.

And doing that boils down to one rule-- keep the animators animating. The work that the animators do is at the heart of our movies, and it is extremely painstaking-- remember, four seconds a week pretty much. So the key is you want to keep anything from delaying the animator on their work. You never want them waiting for anything.

So while they're working on animating a shot on a particular unit, the stage support teams are preparing another one or two units for that animator to move on to-- we call it a bounce on two-- as soon as they finish that first shot. Managing all these asset deliveries and preparing the dozens of stage units each day depends on tightly coordinated involvement of every department. To do that coordination, stop motion productions have traditionally relied on big boards. Like everything to stop motion, it's very tactile and very physical. Cards for the stage tasks for the entire film got pinned up on boards to show the daily shooting schedule.

Big boards drive every aspect of the production. They tell the shots-- they told the shots. When they had to deliver their assets, the stage crew knew what had to be prepared, what units had to be gotten ready, and the VFX team knew when they could expect the turnover of plates when the animators completed their shots. The crew would meet in front of the board during the day to plan and resolve conflicts, keep the animators schedule.

It worked. For years, it worked. It's visual it's easy to understand. It's public. It's centrally located.

In stop motion, the big boards are the center of everything, but they don't scale very well.

What you're seeing here is a 4-foot by 8-foot board. That one 4-foot by 8-foot board could fit about three weeks worth of stage tasks for only about half of units. That's only about 25 units there.

So again, a little bit of quick math-- a full paper big board schedule for a 90-week shoot would stretch nearly the length of a football field. And as our films got more complex, with most shots requiring multiple passes and VFX elements, it was getting really crazy. At some points, some Boxtrolls and on Kubo, we had boards that were stretching out the office, down the hallways, and around the corners into next building, making daily adjustments, took all night, and you can look at poor Nathan over here trying to do an insert.

Can you imagine you've got a schedule out like six months? And now, you've got to move 500 cards over. Yeah, but that's not even the worst part. The most critical issue of the paper big boards is that it had no real link to the digital asset schedule.

So starting with Paranormal-- that was film number two-- like it began representing high-level groups of stage tasks in Shotgun at kind of a low resolution by just using a standard four-task task template for each shot. But with 1,500 shots, even just four tasks per shot meant 6,000 tasks to wrangle. Worse, four tasks a shot doesn't even begin to capture the real details of the work that's actually being scheduled down to two-hour resolution daily. Four tasks also doesn't account for the specific requirements of certain shots. Maybe it's fine for a single piece of origami floating down but not for a 20-foot tall skeleton monster forming from flying bones and rearing up with fire coming out of his eyes.

Four tasks is not enough for that. So the reality is that an accurate stage test schedule for one of our movies is more like 25,000 tasks for one movie. So a keyboard and a mouse and a desktop screen is just not going to do it for the daily data entry required to keep that shot schedule current-- not for 6,000 tasks and certainly not for 25,000.

So the production departments demanded a digital system that could capture the real details of the staged task while also being as fast and intuitive and capable of handling all those tasks and maintaining that tactile and visual method of building the schedule. We met this challenge, which significantly scaled up our Shotgun on usage during the second half of shooting Kubo by building three new systems, BB gun, the planner, and the display. BB Gun is a Django REST framework back-end service. It was named after an earlier iPad-based prototype.

Its development began long before Shotgun's REST API. So it had to rely on the Python API. It provides datetime math functions that override Shotgun's, as well as memcached application-specific query endpoints and update endpoints. Related microservices down here also provide access to Shotgun media without token authentication and also rely on memcache to reduce response time.

This strategy allows all sorts of client apps to safely access and modify the schedule data. BB gun really gave us the ability before the REST API to write custom web apps tailored for very specific use cases while keeping everyone working on that same single source of truth. But one of the most important functions of BB gun is to compensate for Shotgun's task datetime problem.

And the Shotgunners that are here, I apologize for this next bit. This is the single biggest limitation of Shotgun as far as LAIKA is concerned. It really can't be overstated. The start and end fields on Shotgun tasks only support full-day values. They can't store a starting time.

Even though task durations can be scheduled down to a single minute resolution, our stage tasks have to be scheduled in one to four time slots, 9:00 AM, 11:00 AM, 2:00 PM, and 4:00 PM. That's when we start all these things. So think about a 2 and 1/2 day long task that starts on a 4:00 PM on a Wednesday.

Shotgun would see the Wednesday and would calculate the end date to be Friday. But really, it was 4:00 PM on Wednesday. So 2 and 1/2 days later is the following Monday morning at 11:00. So ultimately, this means at the end dates of the stage tasks, as calculated by Shotgun, were often incorrect by at least a day and sometimes even by weeks if we had to take into account holidays and Thanksgiving and production breaks and all that sort of stuff.

So this is what BB gun does. It recalculates the correct end dates, taking into account the time, the start time, so they're accurate in all of the applications that go through BB gun, like planner and the display. And frankly, we're just lucky honestly that the fab departments are more concerned just about with the start dates than the end dates.

We're also very lucky right now that VFX is OK with a little bit of fuzziness and that turnover of the completion of a shot to give them the plates to work on. So, again, we're lucky that all the existing automation and apps that we've written work properly with Shotgun's existing date, math, and work schedule system. But the problem is only going to get worse and more complicated as we move into our next film.

Our production management group has been asking now for finer control to account for individual crew member work schedules and ad hoc Saturday work. So this guy's going to work Saturday, but that guy is not going to, as well as the fab departments are starting to talk about scheduling and our resolution too. So native time support and Shotgun really remains a significant open concern for us. Excuse me. Thank you.

So let's get back to some happier topics. That second new system I talked about of the three new systems is what we call the planner table. The planner table combines a 55-inch touchscreen display with a Scala and Java native UI that communicates through BB gun, instead of directly to Shotgun and because of that task datetime thing. Stage schedulers needed easy access to a lot of different operations at the same time on this big table.

So we divided the UI into kind of three sections. The bottom is this collection of pallets from which the scheduler can pick unscheduled shots, template tasks to paint onto those shots and resources such as the available puppets and the available crew. We had to blur these out because this originally came out before Kubo was released. And they can schedule lay things out in time.

In the middle, there's this area that we call the sequencer where you combine the resources and the shots to lay them out in the desired shooting order-- kind of like you were using a non-linear editor. and then up at the top is the live schedule where that production scheduler drags the assembled tasks as a group onto a real stage unit thus publishing them into Shotgun. This very much mirrors the work that they used to do on just the big table in the old production alley.

Now, also, to take care of Nathaniel, when rescheduling happens, we often need to fix a gap by pushing or pulling a bunch of tasks. This was a lot of work for Nathaniel overnight on the old paper boards. But with a digital planner, it's just a couple of taps of a nudge tool. Now, completing the holy trinity, the display system-- this combines multiple short throw projectors with Hoylu's steganographic surface and Bluetooth imaging pens for wireless UI. It's that same wall-size big boards form factor that's familiar to everybody in the studio.

But it also adds enhanced interaction. The real key-- before we show those new features-- the real key to the display system was maintaining that visual language of the cards from the original big boards. All of these colors are different color-coded tasks, like these gold things. this is like hero animation shooting, and the red is set dressing.

And so people knew what these colors meant. So we kept the pattern of the way the cards were laid out in the colors, which made the new boards instantly readable by anybody. As the tasks get published from the planner, Shotgun and generates messages out onto Revit MQ.

The display app listens to Revit MQ via essentially a WebSocket and allows any number of instances of the display app to live update across the studio in near real time. This ensures that the schedule you're looking at is always current, regardless of how long you kept that tab or that display app open. It's also designed to scale, so you can scale it down to a desktop or tablet if you want. And so we even embed it back in Shotgun. Now let's go down and talk to some of the interactivity features.

Crew members can zoom in and get details for a particular shot. You couldn't do zoom in on a sticky note. You can view the animatic review the notes from the other departments.

You can Zoom all the way out and see the entire shooting schedule for the movie on one wall instead of on a football field. You can scroll. People don't have to kneel or jump or take the meetings into the next hallway anymore. Excuse me.

You can even render the oneline view for the selected show on that same day projector. You can filter for anything. You can filter on an asset or a unit or any other refinable resource or just your own assigned tasks, which was really important for animators to find out where my bouncing to next.

And you can even put freeform hand-drawn notes and sketches anywhere on the digital board, just like you could on a paper board-- scribble on a sticky, stick it up. You can do the same thing with a digital board. All that work preserving these tactile visual workflows for the planner and display was really worth it. The scheduling team intuitively knew how to use it, and live updating was a huge win. So we can put boards in meeting areas and conference rooms, and everybody trusts them.

Another win was the enhanced collaboration. The accuracy and always live nature of that shooting schedule created social pressure on the fabrication departments to keep their information equally as accurate and up-to-date. Until BB gun and the planner and the display systems really connected the shot in the asset schedules, Project could only bring the department heads to the Shotgun water, and we couldn't make them drink. But their peers in the other groups can and do. Believe me, they do.

So you might ask, did this all work? Yeah. Yeah, it did. Yeah, that's a dumpster full of boards out the back of the building.

So yeah, all right now, we, actually have to pull that off on a daily basis. The show specific departments have their own dedicated folders for their workflow pages. They have many specialized pages during production such as these. This RP shot sheet tells the [? wrap ?] proto department when they need to deliver things.

AD shot approval helps the assistant director take things off the stages and get them reviewed as quickly as they can. We work on rendering or wrangling our render farm, and we do use Shotgun's native review notes app very effectively in the VFX dailies. It's great, and there are pages for tracking down where assets have wandered off to during the day because they grow legs.

Now we also have many other action menu items that we've created in Shotgun, and we have teams such as set dressers and camera crews that are always mobile. They're always moving between what's now 90 units on our stages. So we had to develop apps to put that info and access they needed on their mobile devices. They're all Shotgun backed, and they all rely on BB gun or the REST API.

This is really literally a map of our shooting units now. And what's great is it provides the ability to locate-- right now, it's set to locate equipment. So this is showing cameras and lenses and coopers and robots and stuff and what units that they're on. And it's all in real time it's all lies because it's connected to the tasks.

This End of Days app provides notes regarding critical activities performed during a shooting day to the late night crew that are preparing units for the animators to bounce onto the next morning. This puppet hospital is a very special area near the units where the broken puppets go to be cured. And this puppet hospital app is basically it's their medical charts. We have a hand tracker app that runs on an iPod Touch.

There's one particular really busy coordinator who's keeping track of the hands and the fingers, and she's running between units all day long. Now, she doesn't have to run back to her desktop or even carry a tablet. She can just carry her iPod Touch.

Now, like this fabrication schedules have become more complex. One movie's greenlight starting point has started overlapping with the prior movie's finishing. This had an interesting side effect. It made us realize that there were some shops that like that really are not actually movie-specific. For example, making large format prints and machining custom parts for rigs and arbiters-- those are functions not necessarily associated with just one movie.

Furthermore, these shots, run on more of an on-demand sort of a basis rather than being scheduled way in advance. So we needed to provide a way for someone to submit a request for studio global support to one of these show-agnostic shops, after which that shop would then create Shotgun tasks of their own to track fulfilling that request.

And at first, we considered using Shotgun's ticket or note entities to do this, but both of those are project-specific, which defeats the purpose of the show-agnostic thing. And their page designs are locked down by Shotgun. We really wanted to request to be able to make a request that could either be global, not specific to a project, or be on behalf of multiple projects. We also wanted complete control over the Page Design.

So we made use of another custom known project entity and filled it with custom fields to support the various different shops. We wrote another action menu item that pops up a custom modal flask-based form. The user can visit the print shop queue from Shotgun's global pages and make a new request using a form like that. Print Shop for personnel then fulfill the requests in a Kanban-like fashion, which again, good factory practice.

This request system recently led to a whole new integration with another show-agnostic service group like out machine shop. We have a full-on machine shop with your Mazaks and your Integrexes and all the tumblers and all that good stuff. They're part of our rigging department. And basically, rigging is responsible for holding things up.

So, for example, we're talking about the armatures-- these fully machine custom machine armatures that are inside of all our puppets-- or supporting rigs that then get rotoscoped out. And I don't know if anybody recognizes this, but this is the sashimi from those storyboards earlier with the scene with monkey chopping the fish up or even these robotic systems supporting sets or motion controlled cameras. During box roles, we deployed this request entity system for users to make requests for custom machine shop parts.

But what we've now come to realize, the machine shop is using Autodesk Inventor involved to design and track these custom parts. But again, as with assets and shots, there wasn't a good connection between the parts and the process and the deliveries. They'd been using an entirely different database to keep track of it all as we found out.

So moving all that data-- we are moving all that data into Shotgun-- which means that the parts can be correlated to the assets for which they require, which also lets us do things like future needs projections. Like we had to make 30 Kubos and maybe we're going to need to make 40 of the next year. And, now, we know how many machine parts we needed.

And what's cool is that this is a case where the task templates do totally work for us. You can create a task template for each individual custom part. And when that part gets ordered, apply the test template and require tasks in the machine shop group get created complete with machine and process-specific settings. So we're deploying a whole new suite of custom nonprofit entities, as well as plugins, for Inventor and for Vault and even FeatureCAM to read and write these talking directly to Shotgun on using REST API.

This project had that fortune of starting just as the REST API data had become available. So, again, no custom Python interpreter needed for Inventor revolve. This was especially important because the machine shop uses those tools-- only uses those tools that nobody else uses-- but only that, they're also all Windows-based. And everybody else is all Mac and Linux. And so the REST API just totally erases that divide. So great, we scoped a bit of movie. We're producing it, maintaining its schedule.

Last bit is tie it all together and actually measure the progress of the production deadlines and milestones have to be hit to meet the movie's release date. Shotgun supports displaying services and percentages at any single point in time really well but only recently got the ability to graph data over time. And while graphs can be useful, LAIKA really needed to be able to measure progress on many different fronts, many different metrics. So during Kubo, we fleshed out the use of Shotgun's work schedule system and designed another custom entity specifically for tracking data over time. But first, we needed shaken to understand our counter.