Blue Sky Studios' Materials Supervisor Brian Hill has been in the thick of the action on the animation studio's last five feature films, where he has led teams working on in his words two and a half movies. Epic, the studio's latest animated feature, shrinks a teenager and places her in a natural environment filled with trees, grass, flowers, and magical creatures. Thus, the materials department surfaced geometry for a human-sized world, and that world as seen through the eyes of two-inch-tall characters, then sent the assets to CGI Studio, Blue Sky's proprietary, physics-based rendering software. Here, Hill discusses his latest work on Epic with CGW Contributing Editor Barbara Robertson. (Also read a Q&A with Chris Wedge in the May/June 2013 issue of CGW, and another with CTO Carl Ludwig online and accessible via the May/June 2013 issue box on cgw.com. And, look for a fourth with co-producer Michael Travers, coming soon.)
When did you and the materials department begin working on Epic? Chris [Wedge] directed Robots, and we started on Epic, which was titled Leafman at that time, just as Robots was wrapping. We worked on a test for Epic and began developing the technology to do it. We ended up choosing to make other movies first, but Chris kept it flowing with a small team. Its been a long journey. From a materials standpoint, it is a very, very complex, ambitious movie for us - one of the biggest things weve done since Robots.
Robots came out in 2005. Could you have made Epic that long ago? Technically, we could have made the movie then. But, the movie we made now is far better visually than we could have done then.
Why could it be visually better now than before? Weve learned how to deal with complex scenes, with high memory loads in our renderer, and with lots of detail and geometry. We know how to build trees more efficiently than before. All those things we figured out for the pictures that came in between, so when Epic hit, we said, All right. Now we can make it look better. And, purely from a horsepower standpoint, the renderfarm we have now is no comparison to what we had then. Its massively more powerful, so we could up the detail.
You introduced procedural shaders for Robots. Did you use them for this film, too? We dabbled a little with procedural shaders on the first Ice Age, but Robots shaders were almost entirely procedural. It was a massive paradigm shift. Since then, a high percentage of what you see on screen is procedural. But, with Epic, we re-introduced texture maps mixed with procedural shaders depending on what we needed to get the job done based on the shot, the leaf, the piece of bark, the rock, the twig. If it was more efficient to write a procedure, we would do that. If it was more efficient to use a texture map to generate a shape, a vein pattern, we would use the map, bring it into our procedural tool kit, and use one of the many layers to make a leaf.
How did you determine which was more efficient, maps or procedural shaders? Some of it came down to timing - production schedules, artist schedules. We have a team with diverse skill sets. Some are really, really good with procedural textures. Others are well versed with 3D paint packages and procedural shaders, and if they were available, and the schedule was tight on something that demanded a high level of detail close to camera, wed have them do a blend of 3D paint and procedural. This was our first film using 3D paint, so we evaluated several packages. The studio already had licenses of [Autodesk] Mudbox for our lighting team, and for what we needed, it worked well. We also used 3D-Coat [from Andrew Shpagin] a little bit.
The thing thats limiting for us when we go down that road, is that it becomes a single-use material. You make a painting, a series of texture maps, that work for that asset in that moment, which is why we steered away from a texture-mapping pipeline. If the texture gets too close to camera, you have to repaint. If its too far away, you might have heavier maps than you need. The ideal situation is when we can come up with a procedural solution that can be multi-purpose, used for something else. But, that takes more time. So when the schedule was tight, we might opt for the 3D paint route. When the schedule was more open, wed dig into the procedural side and add more materials to the library.
You have a library of procedural shaders? As each show comes along, we build a library of procedural materials that we can move from one asset and one shot to another. The library has grown over the past number of shows. We relied on it heavily and fed it with new materials that we developed. Going forward, we can use those materials again. Its just code. It isnt tied to topology or geometry.
The way our materials work is that we attach them to an asset. A large oak tree, for example. We build the material once and attach it, then wherever the tree goes, it gets the material. The forest in Epic is made of thousands of assets. We have probably 20 or 30 generic rocks. A lot of trees. And different permutations of types of trees - oaks, maple trees, pine trees, large, medium, small. And we have a kit of foliage.
Usually what we do is browse through the library and pick a few materials that might be a good place to start. Then we bring them into a scene with the asset, apply them quickly, see which work and which dont. Sometimes we mix two together. Or, maybe take one, duplicate it, and adjust to make a new one.
Did you create all the materials for the assets in Epic early in production? The first time we get a sequence, if its one of the first in the film, we have a lot of work to do, a lot of vegetation we havent seen before. As we work through the film, we have fewer and fewer new materials to do because the assets have their materials built and attached to
