New Production Phase, New People
Okay, two and a half days at the Blender Institute and my brain is spinning again with ideas and new questions of how to connect the bits and pieces of the open-source animation film-making culture. By all scholarly standards, a brief visit lasting 2.5 days is nothing for getting input for ethnography-based research, but I think in this occasion it worked well — there were opportunities to talk to people and look around, and the rest of the time follow the work through IRC and the weeklies.
Every time I try to plan a visit to the Gooseberry production and wonder when I should come, I get the reply from Ton and Francesco that any time is an interesting time, as there’s always something different happening. This tends to make my visits quite unpredictable and inserts an element of surprise – I never know in advance whom I will find at the office, what new people I will meet and who has left, and what the production atmosphere will be.
This time the new people in the team for me were Elysia, Campbell, Manu, and Bastien. Typical of my visits to the Blender Institute is the unpredictability of finding opportunities to chat with people, because everyone is always very busy and I do not feel comfortable stealing people’s work time. Campbell was literally running back to coding after grabbing a coffee from the kitchen, leaving just a few minutes of time to talk. Fortunately for me, the second evening a totally unplanned opportunity to talk arose, and I grabbed it.
Our conversation starts in a slightly unfocused and unsure way, jumping between themes. Gradually it begins to flow, and when we look at the time it is suddenly approaching midnight. We realize that we have spent over two hours talking Blender, open source, APIs, patch trackers, working full time for the Blender Institute, volunteers, Stack Exchange, open movies, and everything in between.
Campbell and I spend a lot of time talking also about renderfarms, and the advantage of having your own, and generally building your own infrastructure: “Things would always fail and we would not have enough control to be able to figure out why.” In other words, it’s better to be in control of the technology you depend on. I find the rendering process fascinating in its triviality and practicalities: the fascinating thing for me is that it connects animation to really material things – it materializes the actual movement and life of animation, a process which seems like a separate struggle on its own, where bits can get flipped, hardware can burn, and many other things can go wrong. But when they go right, they produce magic.
In the beginning of our conversation, I asked Campbell for some guidance on how to think about (1) the artist-developer relationship in the Blender Institute film productions, and (2) how the software actually gets developed during the film-making process. Where should I look to grasp the dynamics of it? What should I look at? When? What’s his experience been in the previous productions? This somehow leads us to talking about the pleasures of coding, the enjoyment of solving interesting problems in a clever way, and the boring but necessary work of maintaining infrastructure.
My mind latches onto the “clever” problem-solving, as it reminds me of a quote from Gabriella Coleman’s book on free software and the Debian community (2013, p.93):
“Hackers value cleverness, ingenuity, and wit. These attributes arise not only when joking among friends or when hackers give talks but also during the process of making technology and writing smart pieces of code. Take, for example, this short snippet of what many hackers would consider exceptionally clever code written in the computer language Perl:
#count the number of stars in the sky
$cnt = $sky =~ tr/*/*/;This line of Perl is a hacker homage to cleverness; it is a double entendre of semantic ingenuity and technical wittiness.”
I am yet not sure if I should think of Blender developers as hackers, but I think the attitude of working with software and finding pleasure in the coding is close to the attitude one can find in hacker and open source software communities generally.
Campbell also talks about “clever hacks,” which aren’t necessarily elegant, but provide quick solutions, sometimes with real advantages over more complex solutions. His example is an early ad-hoc render farm that he wrote 6 years ago. “Simply write placeholder images, never overwrite anything, point systems on a local network to a shared location, and press render,” Campbell explains the code. “It’s a hack really — but in a pinch it’s less hassle than installing full-featured farm software. We ended up using it for the Big Buck Bunny credits, for example.”
From there we jump to the topic of how Blender development would be different from, say, Linux-related development. We end up in a discussion about the way in which developing for an operating system can be very systematic, and in certain ways easier to decide on what improvements should be made. In Blender, we conclude, it works differently because of the dependency of artists on the software, which makes it very sensitive to change as it can affect existing work-flows. Also, the many requests for features and bug-fixing need to be prioritized, and the things that are actually causing problems get ranked higher than the “merely” hypothetically useful things. It seems difficult to say, “I will make this user friendly,” because what is very user friendly for one artist is not for another. Small changes can disrupt whole work-flows, causing users to suffer.
In this sense, Campbell says, the work done for open movies like Gooseberry helps to temporarily focus the software development on things artists are actually struggling with on a daily basis. You don’t have to imagine what problems they might have and what features they would need: in production you experience the problems first-hand. In this way you can go beyond the domain of “speculative programming” and have a really pragmatic and practical approach to solving what really needs to be solved when setting priorities. My takeaway: pragmatism rules over hypothetical thinking and is a really distinguishing “Blender” feature compared to other free software communities and practices.
The Sunbeam bug
Earlier that day I got to see a mini-illustration of this, when Pablo experienced a weird bug when using Sunbeam. (Sunbeam is a “cheap” way, in terms of rendering, to simulate the effect of volumetric light, Pablo patiently explained to me. I think, ‘Hmm, is this an example of a smart technical solution in the field of 3D animation — another example of hacker culture translated into the pragmatics and technicality of 3D making?’) In the process of rendering an environment, Pablo’s image appeared as if it were corrupt. After mentioning this in passing to Lukas, who happened to be walking by, by the next day Lukas had solved the bug. Having a developer around who knows the code looks indeed like a pragmatic and efficient way of working and solving technical problems in the process of animation making.
Screenshot from Pablo’s work on environments
Campbell and I also talk about the satisfaction that the work on Blender and for the Blender Foundation gives. It sounds like a very non-alienating work experience, giving a great degree of moral satisfaction, autonomy, and self-responsibility. This was actually something I was curious about when speaking to Manu: how is it different to work on Gooseberry for the Blender Institute in comparison to his work for (“Angry Birds” studio) Rovio. We talk about this while Manu takes screenshots of the visible elements of the island, improving his skills on command-line use of GIMP and ImageMagic to crop frames and screenshots automatically. He tells me that a substantial difference is the benefit of showing your work, through the sharing and weeklies, as well as the release of assets as commons – in the industry, months or years of work can be put into something that may never see the light of day, and it may be impossible to even include it in a demo reel. (Watch Daniel Plink talk about the 3 principles of motivation — autonomy, mastery, and purpose — for more insight into Manu’s philosophy.) The Blender Institute way of making films exposes this “hidden” work, and makes it possible for everyone to use it. This visibility of work is something that was also mentioned by developers in my previous visit – coding is one of those things that often remains hidden, but Blender’s public sharing helps cast a light on this work.
In fact, there is a tremendous amount of invisible work that goes into the production of an animation film. Since Gooseberry is a project with very high and ambitious goals, but without the resources to match (compared to the productions currently leading the industry), the film-making process is in constant fluctuation. Things seem to change and face new developments at every moment, and while the basic ideas are clear, details are not. Where should Franck look in a scene? How should he grip and release the dragonfly’s antennae? In fact, how should the dragonfly fly, or rotate, and when? How many dragonflies should there be in a scene? Should they be there at all? Should there be any other flying creatures? The various options must be tested to see how they look in practice. What remains obscured in this process is the amount of work put in and that becomes invisible and untraceable in the process of constant recreation. In fact, the only way most followers at home will glimpse these pieces is through the weeklies — as, for example, Elysia wrote about how several different layouts of the same scene changed and evolved in the course of two weeks. Still – seeing the video of the layout hides the actual volume of work behind it, which is significant.
For example, while Manu has been doing some preparation work before starting to model the island setting of the first scenes in the film, Mathieu has been working on the layouts of the opening shots, shortening lengths. What does that mean in practice? That, while Manu has been taking the screenshots of the visible elements of the island, some of these scenes have been cut. I wondered: is this a coordination problem? Or a natural consequence of the animation workflow? That the workflow is a “future-oriented” process, as researcher Limor Shifman would perhaps say, in which every step leads to the next one, but each step requires a lot of work to insert a high degree of precision of details to save resources for and ease the next step? Figuring out the details means also an exercise in communicating visions and ideas of movement, a rather challenging task. At the stage in which Gooseberry is now, trying to find the answers to these questions is about actually reproducing the possible movements, and trying to map the image of the movement to the feeling of the film developed by the director through actually seeing the movement in practice.
While Hjalti can spend two days on the layout of a scene that lasts as-yet-undefined number of seconds, this effort is oriented toward visualizing the way the director sees the film. If it does not look, work, or feel good for some reason, more effort is put in to create a new representation that the director and artist feel works better. So, in one moment Hjalti’s and Mathieu’s work on the layouts represents a collecting point that merges the fragments of everyone else’s work in the production into a movement, but it also represents the means to communicate each one’s individual representations of the director’s imagination of the film and how it works in the context of the film. (Sorry if this is a bit abstract, but I hope you understand my point! :)) The work loop can repeat as many times as necessary: whatever does not work is put back into the loop of fragmented polishing and re-work.
By the way, while Mathieu is a director, he is also working on layouts at the moment, and recording sounds, and doing perhaps a hundred more things…just like everyone else. This is very different from how it works in most of the industry, where directors might sit on a different floor from the artists — where the layouts are done via a trial and error process that involves everyone. As work-intensive they can be, these layouts are also a life-saver when moving to the next step – the animation process itself. As Hjalti explains to me, when moving on to the animation phase, any cuts and changes hurt much more because of the tremendous effort and personal feelings involved in creating unique character animations. Hjalti gives me an example: Disney used to have an award for the person who spent the most time on things that didn’t make it into the final film, and tells me about a person who had been working for a few months on some very difficult scene that afterwards, because of a small change in the script, was totally cut out.
All this brings me to the thought that producing an animation film is a very big practical exercise in collective dreaming over a long period of time — of imagining how something might be. On the other hand, the production process is very pragmatic, as well as craft- and technology intensive: shaping the objects, worlds, and tools that make animation possible. It is fascinating how much effort and emotion is put into this collective imagineering process, which in the end will produce a laconic yield, some minutes of animation — which needs to be all the more soulful to compensate for its brevity. Considering this effort, the exposure granted by sharing this work in public gives the artists’ a way to extend its value, garner more appreciation, and allow for more value creation (in terms of knowledge, etc.) from it.
More reports, research and thoughts can be found on my blog.