Rendering & Technology

You don’t have to be a rocket scientist to work at blue sky, but only because we already have some. It takes many incredibly brilliant minds to develop and maintain the technology behind our films.


In R&D, the team writes software that our artists use to give Blue Sky movies their signature look. Besides drinking lots of coffee, our team divides their time between doing research and writing software, or what’s commonly referred to as code.

Research may involve staring out the window at the clouds or trees, playing with pieces of fur or blocks made out of peculiar materials, flicking our hair back and forth or simply looking at our own reflections in a mirror. Reading books and using the Internet counts as research too, but it’s more fun to stare out of the window and still be able to say you’re working.

Writing code essentially involves telling the computer exactly what to do, like cooking a recipe except in much more painstaking detail. Computers require overwhelming complex instructions to complete even a relatively basic task. One step wrong in the code and the world comes crashing down, or at least the computer will.

So instead of writing "use 1 cup of sugar" in a recipe for humans, one would have to write code that goes something like: Walk to the pantry, open the pantry door, scan contents for a bag with the writing 'Sugar'; if not found, go buy sugar; otherwise raise arm to align hand with sugar, move hand forward to grab sugar, grab sugar, move hand back, close pantry door, walk to the kitchen drawer, open kitchen drawer, scan contents for cup measure; if not found, put down sugar and go buy cup measure; otherwise grab cup measure; etc. You get the picture.

In reality, the example is not even detailed enough. How does a computer know what a pantry is or how to walk to it or even how to walk in general? The detail required to tell a computer what to do is mind boggling.

So to avoid going insane from all the detail, we employ a tactic called 'encapsulation'. I already used it in the above example where I wrote 'go buy sugar', which for humans is sufficiently clear, but not for a computer. In my example, I assumed that another  software engineer had already spelled out how to buy sugar in all the detail required and encapsulated it in a so-called function called, say, "go buy".

Having someone else write a function that encapsulates a load of detail means we don't have to bother with it and we can simply call that function instead: go_buy (sugar) or go_buy (flour) etc. From there, it doesn't take much to understand that we can write the function "bake" that can be invoked on Thanksgiving Day a couple of times: bake (pie::pumpkin), bake (poultry::turkey). The "bake" function would of course invoke other functions such as "go_buy."

Here is an example of a function that was written in R&D.

A digital movie consists of 24 images per second and each image consists of pixels (about 2 million per image). Each pixel has a color. It’s our job to write software that determines what color each pixel should be.

Somewhere in the code there is a function that figures out that color. The function is called "render". The render function itself invokes lots of other functions and they in turn invoke other functions and so on and so on.

Most of the time all goes well as function after function, pixel after pixel, image after image, movie after movie gets made. We smile, pat ourselves on the back and take a swig of coffee because we know just how good we are at writing those functions.

But then all hell breaks loose. We choke on our coffee, cough until tears stream out of our eyes as we read the email announcing the trouble: Bad pixels in the freshly rendered images. Our render function failed! Crikey, now what?

After the initial panic subsides and we can think straight again, we do the first thing that comes to mind: try and blame someone else. We look and look to see if any of the artists involved didn't do something wrong. Sometimes they have, they are human after all, but sometimes it is our render function.

If it is our render function we like to pretend it wasn't our mistake so we call it a "bug." Fixing that mistake is called debugging. 

So here we are with a bug in our render function. That is to say, the bug might be in the render function, or in the functions it invokes or in the functions they invoke, etc. Trying to follow the trace of function invocations feels sometimes like going down the proverbial rabbit hole. Our coffee goes cold and our emails go unanswered as we hunt around for the sneaky creature.

Meanwhile deadlines loom, tension rises, the coffee, long cold, evaporates and becomes a sticky goo in the bottom of the cup when suddenly, just when we're getting desperate, a flash of insight reveals the problem. We climb out of the rabbit hole and proudly proclaim: We have found the Bug and Squashed It Dead. Everybody rejoices. The Bug Is Dead, The Bug is Dead. We are hailed as the great Bug Squashers.

It's such a great feeling to fix a bug that it almost seems better to make a mistake and debug it later than to do it right in the first place! Almost.

It's an even better feeling to see what our artists do with the software when it works right. It's always so creative and sometimes quite surprising.

We always try to give them the best, most intuitive and easiest to use software possible. Often we end up doing things quite differently from coders elsewhere, just because we feel it is the best solution for our artists.


The Render Department works hand-in-hand with nearly every department in the studio.

The department's most basic responsibility is the production of frames. All final work from each department is fed to the Render Department, where it is pulled together and the images (aka "frames") are calculated by the computers (aka "rendering"). The frames are then passed back to each department so that they can see what their work looks like in relation to the other departments' work.

Throughout the process, the Render Department is responsible for efficiency. A computer can take up to two or more days to calculate all the information that goes into a single frame. At an average of 129,600 final frames per film, the time and energy cost of rendering is extremely high. The Render team works hard to minimize the number of calculations per frame while retaining the high visual quality expected of a Blue Sky film.

Though the Render Department's work is important, it can be nearly invisible in the final product. The team takes pride in keeping production as smooth and efficient as possible so that the movie can be keep pace with the myriad of deadlines and technological advances it faces during the production lifetime.


Production Engineering is a team composed of people from both technical and artistic backgrounds providing studio tools.  The team's unique mix of skills and talents are instrumental in providing both practical and straightforward technical solutions.  The main focus is to bridge the technology gaps within the production pipeline and to develop tools and processes to improve interdepartmental work flows.  We develop and integrate both proprietary and third party software into the pipeline, and we continually review the studio's pipeline and develop solutions to problematic areas.