Tag Archives: Two Guys and a Toolkit

The pipeline experts behind Shotgun’s ‘Two Guys and a Toolkit’ blog

Jeff Beeland and Josh Tomlinson know pipelines, and we are not exaggerating. Beeland was a pipeline TD, lead pipeline TD and pipeline supervisor at Rhythm and Hues Studios for over nine years. After that, he was pipeline supervisor at Blur Studio for over two years. Tomlinson followed a similar path, working in the pipeline department at R&H starting in 2003. In 2010 he moved over to the software group at the studio and helped develop its proprietary toolset. In 2014 he took a job as senior pipeline engineer in the Digital Production Arts MFA program at Clemson University where he worked with students to develop an open source production pipeline framework.

This fall the pair joined Shotgun Software’s Pipeline Toolkit team, working on creating even more efficient — wait for it —pipelines!  In the spirit of diving in head first, they decided to take on the complex challenge of deploying a working pipeline in 10 weeks — and blogging the good, the bad and the ugly of the process along the way. This was the genesis of their Two Guys and a Toolkit series of blogs, which ended last week.

IMG_6655 jbee
Josh Tomlinson and Jeff Beeland.

Before we dig in to find out more, this is what you should know about the Pipeline Toolkit: The Shotgun Pipeline Toolkit (sgtk) is a suite of tools and building blocks designed to help users to set up, customize and evolve their pipelines. Sgtk integrates with apps such as Maya, Photoshop and Nuke and makes it easy to access Shotgun data inside those environments. Ok, let’s talk to the guys…

What made you want to start the Two Guys and a Toolkit series?
Josh: Since we were both relatively new to Shotgun, this was originally just a four-week exercise for us to get up and running with Toolkit; there wasn’t really any discussion of a blog series. The goal of this exercise was to learn the ins and outs of Toolkit, identify what worked well, and point out things we thought could be improved.

After we got started, the word spread internally about what we were up to and the idea for the blog posts came up. It seemed like a really good way for us to meet and interact directly with the Shotgun community and try to get a discussion going about Toolkit and pipeline in general.

Did you guys feel exposed throughout this process? What if you couldn’t get it done in 10 weeks?
Jeff: The scope of the original exercise was fairly small in terms of the requirements for the pipeline. Coupled with the fact that Toolkit comes with a great set of tools out of the box, the 10-week window was plenty of time to get things up and running.

We had most of the functional bits working within a couple of weeks, and we were able to dive deep into that experience over the first five weeks of the blog series. Since then we’ve been able to riff a little bit in the posts and talk about some more sophisticated pipeline topics that we’re passionate about and that we thought might be interesting to the readers.

pipe_layout copy

What would you consider the most important things you did to ensure success?
Josh: One of the most important ideas behind the blog series was that we couldn’t just talk about what worked well for us. The team really stressed the importance of being honest with the readers and letting them in on the good, the bad and the ugly bits of Toolkit. We’ve tried our best to be honest about our experience.

Jeff: Another important component of the series was the goal of starting up a dialogue with the readers. If we just talked about what we did each week, the readers would get bored quickly. In each post we made it a point to ask the readers how they’ve solved a particular problem or what they think of our ideas. After all, we’re new to Toolkit, so the readers are probably much more experienced than us. Getting their feedback and input has been critical to the success of the blog posts.

Josh: Now that the series is over, we’ll be putting together a tutorial that walks through the process of setting up a simple Toolkit pipeline from scratch. Hopefully users new to Toolkit will be able to take that and customize it to fit their needs. If we can use what we’ve learned over the 10 weeks and put together a tutorial that is helpful and gives people a good foundation with Toolkit, then the blog series will have been successful.

Do you feel like you actually produced a pipeline path that will be practical and realistic for applying in real-world production studios?
Jeff: The workflow designs that we model our simple pipeline off of are definitely applicable to a studio pipeline. While our implementations are often at a proof-of-concept level, the ideas behind how the system is designed are sound. Our hope has always been to present how certain workflows or features could be implemented using Toolkit, even if the code we’ve produced as part of that exercise might be too simplistic for a full-scale studio pipeline.

During the second half of the blog series we started covering some larger system designs that are outside of the scope of our simple pipeline. Those posts present some very interesting ideas that studios of any size — including the largest VFX and animation studios — could introduce into their pipelines. The purpose of the later posts was to evoke discussion and spread some possible solutions to very common challenges found in the industry. Because of that, we focused heavily on real-world scenarios that pipeline teams everywhere will have experienced.

What is the biggest mistake you made, what did you do to solve it and how much time did it set you back?
Josh: To be honest, we’ve probably made mistakes that we’ve not even caught yet. The fact that this started as an exercise to help us learn Toolkit means we didn’t know what we were doing when we dove in.

In addition, neither of us have a wealth of modern Maya experience, as R&H used mostly proprietary software and Blur’s pipeline revolved primarily around 3DS Max. As a result, we made a complete mess out of Maya’s namespaces on our first pass through getting the pipeline up and running. It took hours of time and frustration to unravel that mess and get a clean, manageable namespacing structure into place. In fact, we nearly eliminated Maya namespaces from the pipeline simply so we could move on to other things. In that regard, there would still be work to do if we wanted to make proper use of them in our workflow.

You spent 10 weeks building a pipeline essentially in a vacuum… how much time realistically would this take in an operational facility where you would need to integrate pipeline into existing tech infrastructure?
Jeff: That all depends on the scope of the pipeline being developed. It’s conceivable that a small team could get a Toolkit-driven pipeline up and running in weeks, if relying on mostly out-of-the-box functionality provided.

This would require making use of well-supported DCC applications, like Maya and Nuke, as custom integrations with others would require some development time. This sort of timeframe would also limit the pipeline to supporting a single physical studio location, as multi-location or cloud-based workflows would require substantial development resources and time.

It’s worth noting that R&H’s pipeline was initially implemented in a very short period of time by a small team of TDs and engineers, and was then continually evolved by a larger group of developers over the course of 10-plus years. Blur’s pipeline evolved similarly. This goes to show that developing a pipeline involves hitting a constantly moving target, and shouldn’t be viewed as a one-time development project. The job of maintaining and evolving the pipeline will vary in scope and complexity depending on a number of factors, but is something that studios should keep in mind. The requirements laid out by production and artists often change with time, so continued development is not uncommon.

Any lessons learned, parting words of wisdom for others out there taking on pipeline build-out?
Jeff: This really goes for software engineering in general — iterate quickly and set yourself up to fail as fast as possible. Not all of your ideas are going to pan out, and even when they do, your implementation of the good ones will often let you down. You need to know whether the direction you’re going in will work as early as possible so that you can start over quickly if things go wrong.

Josh: A second piece of advice is to listen to the users. Too often, developers think they know how artists should work and fail to vet their ideas with the people that are actually going to use the tools they’re writing. In our experience, many of the artists know more about the software they use than we do. Use that to your advantage and get them involved as early in the process as possible. That way you can get a better idea of whether the direction you’re going in aligns with the expectations of the people that are going to have to live with your decisions.