DP: What were some of the challenges you found in making the transition from your programming background into the world of film effects?

JB: Acquiring a good eye for the aesthetics was a challenge. Everything I did before was complete computer coding. It was math. The programming helped, though, because of the need for efficiency and organization. When I switched over to film effects, my background helped me to take on multiple shots, troubleshoot and problem-solve.

DP: How did you develop your aesthetic sensibility?

JB: It comes with time and the experience of doing all these shots. Since I’ve been here, I’ve been able to work with Ken Ralston, John Dykstra, Rob Legato, Jerome Chen and quite a few others. You start learning from all these guys about what looks good and what doesn’t.

DP: What was programming like at an effects company compared to your previous research experience?

JB: The projects I was working on before starting in the effects industry were huge in scale, and things had to be more formalized. The reason for the formalization was to allow somebody else to be able to pick it up at any time. The consortium was large and based out of multiple cities, so theoretically somebody from another town might pick up the code and need to easily understand it and use it. Everything had to be very well written, so to speak. Coming into effects, since I wasn’t necessarily part of software, it was more like meatball surgery. You came in and you coded some stuff up on the spot. It was in the heat of production and it wasn’ t like we had six months to write a program and test it out thoroughly before using it. I would just put things together and test them in practice on a shot. If it breaks, you fix it, and it’s a process that constantly repeats as you continue expanding the scope of the program. With really good code, like what we wrote in my engineering days, there’s a huge requirement spec written for a software project. That stage is skipped when a tool needs to be written for a production. If I need something to do a particular task, then I create it. As the needs change, this thing takes a life of it’s own. It kind of morphs and usually becomes a little less stable.

[Figure 1] A shot showing one of the many costumes worn by Stuart in the 1999 film Stuart Little. All Stuart Little images © 2002 Columbia Pictures Industries, Inc. All rights reserved. Courtesy of Columbia Pictures.

DP: How does optimization work into the equation in the effects industry?

JB: Optimization is tough. Usually it’s hard to do in the heat of production. You end up optimizing during down time. A very big case of this is BIRPS, our rendering system. That has slowly been evolving since I’ve been here. I remember a guy came over just before I did and he started writing the idea of having a sprib, or a single rib, with all of the per-frame information baked out. That was being implemented while I was here and I was actually writing the pipeline around it. We used it on Anaconda and it worked incredibly well for that. I hacked some stuff together for Contact and Starship Troopers, but then we had some down time and really started to think about the design a little more. We were able to implement those changes for use on Godzilla, but, again, it was kind of rough at first. We were just trying to get it ready for Godzilla and didn’t really have time to fully develop it. When Godzilla ended, the rendering system got bigger and we started thinking about inheritance and multiple material files. We wanted to have the capability of creating standards that people could share. We were starting to implement that at the beginning of Stuart Little, and it was necessary because of the scale of that show (see Figure 1). Instead of five to 10 artists, now you’ve got almost 50 artists sharing these materials. The addition of material standards made a big impact.