Josh Tomlinson is a Senior Pipeline Engineer at Autodesk and a member of the global Pipeline/Asset Management Team at Shotgun (SG) Software, aka, the Toolmakers. Josh has over a decade of experience designing and implementing pipelines for animation and VFX studios and related Digital Content Creation (DCC) tools. His credits include Land of the Lost (2009) and Alvin and the Chipmunks (2007). Josh talks to JHI about his experience with pipeline development and working on global, software-development teams.
You have worked as Pipeline Lead on specific shows, such as Evan Almighty (2007), and you have also served as Pipeline Support for studio-wide tools and applications. Is there a difference between those two roles and do you have a preference?
Not all studios are at a scale where they have (or need) both production-specific pipeline support and dedicated, back-end pipeline developers. During my time at Rhythm & Hues (R&H) Studios, for the size we were, the number of locations we had, and the goals of our pipeline, these roles played important parts in the overall well being of our productions. From a day-to-day perspective, the roles were quite different, but also very much complementary. Show support teams were in constant communication with the studio development teams in order to identify trends in both the workflow and requirements from the various production disciplines.
Evan Almighty (2007). © Universal Pictures.
The studio development team was responsible for taking that information and providing tools and frameworks that were usable across all productions but also flexible enough to conform to the needs of individual shows. Often times at R&H, pipeline team members would rotate between the front-line production pipeline support roles and the back-end pipeline development roles. This was a great way to keep pipeline folks in touch with the production perspective while considering the overall studio efficiency goals and vice versa.
So, could you compare and contrast the show-based pipeline support versus the studio pipeline development roles?
I don’t think that I appreciated it at the time, but the best part about the production pipeline support role was the experience I got interacting with every department on production and trying to learn how to deal with all the different personalities throughout the highs and lows of a production cycle. The best part of the studio development role for me was building tools, designing workflows, and providing APIs that were used on a multiple feature films. I started gravitating toward the overall studio development efforts early on in my career. I always enjoyed the challenges we had as a team trying to build scalable solutions for a global pipeline. There was also a lot less overtime in that role too which was a priority for me when we were starting our family.
At one point in your Two Guys and a Toolkit blog, you had requested input from Toolkit builders and Shotgun (SG) users from various studios. Are there any “cool solutions” that you received and implemented into SG as a result?
The blog series was a great opportunity for Jeff Beeland and I to riff on some of the philosophies we built up over the years working at R&H and how they might fit into Toolkit in SG which was completely new to us. Much of the feedback we got from the community was that others were also going through the same process of trying to learn and implement a solution using Toolkit that fit into their studio’s goals. I think the best thing that came from the series and from the feedback was the pipeline tutorial we published shortly after the series ended. It has been used both internally and externally by folks trying to get up-to-speed with Toolkit. The tutorial can be found here.
You work with a global team of developers and tool makers who are spread across multiple time zones. Can you share any recipes for successful teams that are able to collaborate and communicate in a geographically-dispersed work environment?
The Toolkit team follows the principles of agile development using the scrum methodology. I hadn’t worked this way before I started at SG, but I think it provides a nice framework for distributed teams. Part of the workflow dictates daily “stand-ups” where everyone talks about what they’re working on, what road-blocks they’ve hit, etc. These meetings are great for keeping everyone aware of progress toward the goals of the current sprint, but they also provides a way for us to have “water cooler” discussions. We always spend at least a few minutes talking about life outside of work and that really helps us bond as a group, I think. For me, that’s critical to keep remote team members from just being faces on a screen. We also have summits at least once a year where the team physically meets in a city and works side-by-side for a week. This is another great way for the team to jell and become stronger as a unit.
As an MFA student at Clemson, you co-developed an open-source production pipeline framework. Is that framework still around and do you hear from folks using it?
Actually, when I was a student at Clemson (many years ago) I don’t think I knew what a pipeline was!
When I left R&H in 2014, I went back to work at Clemson and help build an pipeline for their Digital Production Arts (DPA) program. Our goal there was to build a pipeline framework that would be used on student productions, but also be something the students themselves could build upon. The pipeline itself would be a teaching tool which we thought would separate the DPA program from others. In the summer of 2015, however, I got an offer from Shotgun that I just couldn’t pass up. The DPA pipeline was in a state where it had been used in a couple of small student summer projects, but it was definitely still in a work-in-progress state. We did open source it before I left but since I was the primary developer, its development has stagnated. I’m hoping one day I’ll have the time to go back into the code and clean some things up, add some more docs, and make it easy to get up and running. I know the Clemson students are still using at least some parts of it since I get the occasional pipeline notification email!
Most undergraduate- and graduate-programs in digital arts and animation put a stronger emphasis on the artistic aspects of production over the technical disciplines. Do you have any advice for aspiring students who are in these programs and wish to fashion an education that enables them to become pipeline programmers and support staff?
There are technical opportunities and challenges at all levels of digital art. There are ways to programmatically interact with, alter, and support nearly every piece of software we use on production. With that in mind, someone who is interested in learning more about the pipeline side of production could start by exploring the Python console in Maya, Nuke, or Houdini.
Reading through the docs to see how simple it is to call a method to make something in the scene move or to write a file to disk is a great way to get started and to get inspired towards creating tools that make their own workflows easier.
Beyond that, I’d suggest books like Learning Python or websites like Code Academy to get a feel for the breadth and capabilities of a language like Python. Obviously, taking software development courses would provide valuable insight and practice as well. Cloning and diving into open source repositories is another excellent way to get a feel for and try out real, production-related code. The Toolkit source code, for example, is shared on GitHub and includes many different examples of software integrations and tools that are used on productions everyday all over the world.
- Interview by Shish Aikat