Our rendering pipeline was primitive in comparison to many in production today. We rendered the scenes in a number of different layers. Character, foreground, background, matte painting and sky layers were rendered as different image sequences which were then composited one on top of another at a later stage.

We looked at tools to accomplish a more sophisticated rendering environment that could output colour, shadow, specular, diffuse and reflection channels. This would have allowed us a great degree of freedom during the compositing stage to work with the look of each shot. However, great freedom comes with its own sets of problems. We had limited time, rendering capacity and storage space, and 80 shots to complete in two months with no dedicated compositor. For this reason we decided to limit the number of layers and thereby limit the options available to us during compositing.

Our primary concern was the ease with which we could make changes, so we rendered a separate layer for each character. This allowed us to adjust each character’s animation later without having to re-render the background. If necessary we also rendered a shadow layer for the character. Where the camera was static and we could get away with rendering a still rather than an image sequence for a layer, we did. By splitting up the scene we reduced the resource demands on the individual computers, thereby improving render times.

For the tech-heads:

In our lab we had five 2.4GHz Intel boxes with 1Gb RAM each and three 800MHz Intel boxes from Hewlett Packard running Windows, a dual 2.4Ghz Intel server running Linux, and for the last month another two dual 2.4Ghz servers, also running Windows. We did benchmark test between Linux and Window and did discover about a 30% speed improvement in rendertimes under Linux. However, our lab was also a teaching environment and each workstation needed to be loaded with certain Windows only packages for the students to work on, so we never fully explored running the whole network under Linux..

We used Spider, the freeware Maya network renderer to distribute our rendering load over the network and it was great. Easy installation and rock solid under Windows 2000. One of our workstations was running Windows XP Pro and it gave us some trouble. We attributed this to a conflict between Spider and XP Pro as we didn’t encounter this problem with any of the other render nodes.

One of the dual 800 MHz boxes acted as our file server, since it only had 256MB of RAM. We did have some bottleneck issues with the ethernet due to the volume of data that needed to be transferred and would in future look at installing an optical network.