Pipeline developer, Carlos Anguiano, offers insight on his role, how he got there, and what it takes to be successful, not only as a pipeline developer but anywhere in the VFX industry as a whole! Here is what he had to say —
G: Can you explain in your own words what pipeline development in film is?
CA: A pipeline developer tends to work mostly at the studio-level. While I work with folks to implement solutions on a particular show, they also need to be accessible to every other show at the studio. The biggest difference between a Pipeline TD and a Show TD is that the show TD is allowed to work more within the bubble of his or her show. They are free to quickly develop solutions for problems at the show level without having to worry about how s/he effects the rest of the studio.
Pipeline development is about making tools, scripts, and APIs that all artists and TDs can use to more effectively get work done, while setting a standard the whole studio can follow. This way pipeline becomes a set of tools and standards that are constantly being improved rather than reinvented on every show. Consistently reinventing the pipeline makes it stagnant and sharing resources across shows difficult if not impossible.
G: As a pipeline developer, what programs or processes do you use on a regular basis?
CA: As a pipeline developer you need to know a little of everything. We are primarily programmers; therefore, a strong knowledge of python, qt, maxscript, .net, Mel, etc, are a must. In addition, a deep understanding of object oriented programing and databases are mandatory. At the end of the day our job is to make other people’s jobs easier by writing code. As a pipeline TD you always have to pick up something new, whether it is a new programing language, library, or a new software package. In addition to this technical side, there’s also the challenge of knowing and understanding how the artist your developing for actually work. A strong knowledge of modeling, shading, rigging, animation, lighting, and compositing, along with understanding on how the work is handed of from one department to the next greatly influences the success in adoption of the tools you write. This knowledge base is probably what makes good pipeline developers hard to find.
G: How did you decide, or fall into the role, of becoming a pipeline developer? What kind of background knowledge/education is necessary to handle this role successfully?
CA: Becoming involved in pipeline was an organic process for me. I started as a generalist with a focus on animation setup (rigging). Early in my career, I worked in smaller studios where one had to do a bit of everything. So I think this experience along with my background in art (B.A in media arts and animation), gave me a good interest and insight into the big picture of creating rendered images. At the same time, my focus in animation setup had me learning about expression and scripting, which eventually evolved into tool development outside of rigging.
It was because of these experiences that I went from being a generalist at smaller studios to being a full-time rigging and set up artist at larger studios. During this time I was lucky enough to work at companies like Disney, Digital Domain, Rhythm and Hues, and ILM that allowed me to get some great insight into the pipelines that create some of the most cutting edge work in our industry. These experiences motivated me to bring some of the ideas that I learned to smaller studios. I began to do consulting for commercial shops and smaller boutique-style Vfx shops.
One of these studios was Scanline Vfx, where I eventually took the role of Character Supervisor and developed their asset pipeline and their rigging and simulation pipeline for assets. At Scanline I spent most of my time working on pipeline which was a responsibility I shared with another fellow artist Lukas Lepicovsky. Two years into working at Scanline, Pixomondo reached out to me about joining they’re pipeline development team, which lead to my first official position as a full-time pipeline developer.
G: What kind of person do you recommend for the role of a pipeline developer?
CA: Pipeline developers need to be critical thinkers, have good communication skills, love programing, have an interest and solid understanding in the process of creating visual effects. Moreover, they should excel at working in a team and be willing to do the work for the pride and hardly ever for the praise. The most important quality a pipeline developer should have is that they always work for the end user. The moment a developer elevates him or herself over the end user, he is no longer working for the betterment of the studio. If I may be honest, you have to be a little messed up to be a good pipeline developer or show TD for that matter 🙂
G: Does pipeline development take place before post production begins? — So once the pipeline is set into place your job is done — or is it an ongoing process that evolves throughout the life of the project?
CA: A place that has good respect for pipeline is always working on developing optimizing and evolving they’re pipeline. Pipeline is a topic that is very broad; it deals with the everyday artist tools, which is what most people limited to, but also expands to IT, production, and HR. Pipeline is about the big picture of running a business. It helps to ensure the maximum output with the least amount of input necessary. These days it is becoming a deciding factor on whether a studio stays open or goes under.
G: How did you end up working on Star Trek Into Darkness? How long were you working on the film?
CA: My involvement with Star Trek Into the Darkness was through the development of one of several tools I created for Pixomondo world-wide adoption. These tools were part of a larger effort to unify the studio under what I refer to as a modular non-linear asset flow pipeline. The tools that were used to achieve this included: a proprietary hierarchal referencing system for 3dsMax and an easy to use render pass manager system that had full Deadline and Shotgun integration for versioning and batch submissions of elements to the farm. The nature of this type of development is that it’s not usually adopted by the entire studio in one swift move. Instead, a single show that is early into production will be used as the test bed. In this case, it was the crew and supervisor for Die Hard 5 who took the ball and ran with this new pipeline that allowed us to quickly prove the difference that these tools were going to make in our ability to create the work faster with more revisions and hopefully less overtime. They were also critical in helping us workout some of the main bugs within the new workflow.
Due to the success of the Die Hard Show, the Star Trek crew showed great interest in adopting the new tools. However, the asset system proved to be tricky because it meant retrofitting certain parts of the show that had already been approved using the older pipeline. At that point we switched our focus towards moving Star Trek into our new render pass manager tool workflow. The tool was adopted quickly with only small bugs being reported which I was able to immediately address. The scope of Star Trek show pushed the render pass manager to some pretty crazy limits which made it evident that I needed to optimize the code. At the same time the trek artists and artists evaluating the tool in other branches were coming up with a number of exciting feature request which were impossible to ignore. All in all, I was on and off-the show helping with development for around 8 months.
G: Did you encounter any challenges while working on the project? Were you mentally stretched in any particular way, or learn something new as a pipeline developer, that you would like to share while working on Star Trek Into Darkness?
CA: As a developer at Pixomondo the biggest challenge is being able to keep track of how changes effect each and every branch. Changing something that seems insignificant can have devastating effects at another branch. During Star Trek, we were in the process of unifying our pipeline across all branches and all shows to facilitate asset and work sharing. Since each branch has a unique history, and pipeline legacy a developer must tread carefully sense things that he/she takes for granted might not work in other facilities. Hitting these types of walls usually means taking a detour into fixing a different set problems before one can continue to make progress with the original task. It can be a slow process and can greatly test people’s patience at times.
G: What projects are you working on currently?
CA: I am currently taking some time off to develop some pipeline tools. For anyone who’s interested I have some information about it on my blog.
G: Is the role of a pipeline developer your end goal, or is it a stepping stone towards something else? Do you intend to take on another role in the future?
CA: I enjoy being a supervisor and I wouldn’t mind getting back into that sometime. Ideally, I would like to do more consulting, training, independent software development, and remote support.
G: For people striving to become a VFX artist in the industry, can you offer any advice on how they can get their “foot in the door?” Are there any pit falls you would recommend avoiding that you personally experienced?
CA: It seems to me that companies looking to hire pipeline developers are putting great value on computer science or equivalent degrees. Pursuing this area of study is probably a more direct way to getting into pipeline work than a degree in art which I received.
If you go the computer science route, make sure to make time to learn packages like maya, max, and Houdini. Many programmers finish school having learned all there is to know about complex programming such as writing a fluid simulator from scratch, but have no practical knowledge of the software that is used on the industry of how to develop for it. If you can figure that out on your own, you’ll be way ahead of the game.