Sep 21, 2017



We caught up with Janice Collier, Pipeline Technical Assistant at Mammal Studios in Los Angeles, to uncover what on earth does a PIPELINE TECHNICAL ASSISTANT do?

So what exactly does being a Pipeline Technical Assistant entail? 
My job is to provide tools and information to keep other people working on their tasks, and not on the various setups and frameworks required to do their own jobs. If you're a Nuke artist spending more time on administrative tasks and shot setup than you are on compositing, that's a concern for me. If you're a supervisor and something is between you and getting your reviews done, that's a concern for me. Anything I do-- code, configurations, support, documentation, research, and reference-- is intended to reduce friction between other members of the facility and their actual work.

Any TD is a technical force multiplier; your code and your vision allow a tiny facility to seem like a much larger studio.

How do you explain what you do for a living to someone who's not at all familiar with your industry?
One of my relatives neither watches movies nor owns a computer, so I tell them that I use my computer to make sure everything my company does ends up going back to our clients in a way that can go in actual movies without too much fuss.

This vastly understates the amount of fuss in some cases, and occasionally overstates the amount of computer, but we get by.

What does your day-to-day look like?
In a facility with a flat organizational structure-- we have six owners, six core staff, and anywhere from four to 10 freelancers during any given project-- you end up doing a lot of different day-to-day tasks. Since I execute on requests from my supervisors, I spend time in Shotgun tickets eliciting specifications and discussing routes to solutions.

I manage our Nuke repository, so I'm often evaluating new gizmos or polling artists for desired features. Artists come to me for software support with Nuke and Shotgun. Data operations and I collaborate on plate ingestion and project configuration. If there's a concern that requires vendor support from Shotgun, the Foundry, or Thinkbox, I'm collecting and collating user experiences into a reproducible support case and submitting it to the right people.

(Don't ask my officemates how often I descend on a room full of artists announcing "OKAY, POLL: who's seen this happen in their comp?! Did you figure out why? Are you able to fix it?" They're used to me, I promise.)

There's occasional render watching, and writing render management plugins for our Deadline farm. Honestly, I believe everyone should render watch now and then just to get a feel for what's going on across the facility regardless of their role. It gives you an idea of where the challenge points for artists are and where the software or the technical approach may not be adequately serving your needs.

Since our data ops and pipeline people sit in the same offices with artists, we also help out with shot reference ("do you need a video of a rocket? WE HAVE THOSE") and "is my track wobbling?/ how does this look?" informal critique.

As I said previously, Mammal is a fairly uniquely-structured company in day-to-day practice-- artists get a lot of individual time with our VFX and CG supervisors, and technical staff get a lot of time working alongside artists, which is uncommon at a lot of facilities. Situations where I'm suddenly digging up research papers on Cherenkov radiation to get the colors right, or our data manager is teaching the artists how to accurately fire a simulated main turret on a Sherman tank, aren't unusual.

(The tank incident happened during David Ayer's FURY; the brilliant blue nuclear-inspired fire is coming soon to a streaming service near you.)

How does Shotgun come into play in your day-to-day?
When I arrived at Mammal almost four years ago, we'd begun basic Shotgun Pipeline Toolkit integration, but hadn't really gotten into the possibilities for plate ingestion, artist-side DCC configuration, and deliverables management.

These days, we can configure a Shotgun project and ingest plates for artist work on a same-day turnaround basis if required. Artists can start working and know that their Shotgun-specified settings inside Nuke are correct for the show, they can source appropriate color pipeline gizmos, and they don't have to worry about anything besides the compositing itself.

Supervisors can review shots as they're published and then push playlists of completed work through our deliverables pipeline to create any form of deliverable required, with accurate slate and burn-in data. Data ops receives the delivery information inside Shotgun and we're out to the client. Our toolset provides all the glue between those pieces of the pipeline, and it's engineered around Shotgun and the Shotgun playlist in particular.

I'd stress, too, that you don't need to be a high-end Python programmer or CS major to do all this. I joke that, as a self-taught coder with a degree in film studies, I solve all my problems with critical essays and strong language, but Shotgun's codebase is pretty accessible.

The public availability of Toolkit source in Shotgun's GitHub repositories has helped me develop as a programmer and exposed me to concepts I might have missed learning on my own. It also makes it easier to help support engineers pinpoint potential issues if I'm submitting a ticket, because I can point right at the actual production code and say "Here. This is where my problem lies, let's see what we can fix together."

I'm told Mammal is one of the more tightly-integrated Shotgun facilities out there. I have no real way of measuring that myself, but if so, other folks in small houses can take heart that you can do this too with minimal alteration to stock Shotgun depending on your client requirements. I realize that bigger facilities' Shotgun demo reels can be very intimidating-- standalone tools! spiffy GUI work! sweeping schema rewrites!-- but you can certainly focus on a few small areas and build a set of pipeline integrations around those needs.

What would you say is the most fun aspect of your job?
I get to spend a lot of time collaborating with the other technical staff members-- our CG supe/ systems engineer, Jason Wardle; our data manager, Chad Collier; and one of our core compositing staffers, Erik Toth. Jason, Chad, and I work together on meeting infrastructure needs, and Erik and I spend time reviewing each other's code and creating new Nuke tooling. Erik has a solid all-around knowledge of areas I don't necessarily have, and I have a reasonable set of troubleshooting and debugging instincts, so we play off one another's strengths.

A big part of my job is designing frameworks to move data in and out of the building according to client specs, so I spend a lot of time evaluating Chad's workflow and tweaking tools to meet operational needs.

There are no teammates like my teammates. I'd say that even if I wasn't married to the data manager. (The plate ingestion pipeline's initial prototype was as much marriage counseling as it was engineering-- "Chad, what exactly are you doing? ...oh, honey, *no.* Let me write a script for that.")

What is the most challenging part of your job? 
Every project is a new project. While we have the basics required to get a show going very quickly, every client spec poses a new set of challenges from the initial plate ingest to the final set of deliverables. For every show that delivers a hard drive full of carefully-conformed plates and corresponding count sheets, there's going to be another one that hands over raw camera exports and a couple of EDLs.

It doesn't matter how the project arrives at my desk, it needs to leave my desk in a way that artists can immediately engage. Those sorts of novel situations require research on what's already possibly out there for us to adapt to our own needs, and what needs to be built to spec in-house. The resulting solutions have to be deployed quickly and the people who will use them need to be trained accordingly.

At the end of the day, you will do all that and you will make mistakes, recover from them, document new procedures and discoveries, and then the next project will overturn some area of your prior understanding and hopefully advance the overall pipeline. That's the challenge.