Making-of: Spring

Not only the results of the software development itself, but also the films should remain open. The team around the Blender Institute, founded in Amsterdam, has thus become a pioneer in the use of Creative Commons licences for assets that are not code and crowdfunding to finance projects.

13 years – 12 short films

The Blender Foundation’s first Open Movie, “Elephants Dream”, was published in 2006. The twelfth short film, “Spring”, was released 13 years later. A few things have changed since then. The Blender Institute has become the Blender Animation Studio. Financing is no longer based on crowdfunding, but on the Blender Cloud, where the data of all previous open movies, training videos and other Blender-related services are made available for a monthly subscription fee.

Blender 2.8 is Production-Proven

But one thing has remained the same: The Open Movies continue to serve to support the development of Blender. And just as “Sintel” accompanied the transition from Blender 2.49 to Blender 2.5, “Spring” was intended to give the developers of Blender 2.8 feedback from a real animated film production as early as possible. What has changed, however, is that in “Sintel” the film team still had its own branch of Blender, whereas in “Spring” they worked in the real Blender 2.8 right from the start.

For Blender users, the advantage of this is that the film team didn’t get custom-made extras that wouldn’t flow into the main branch after the film because they were either too special or quickly hacked together. No, with “Spring” every feature, every request from the artists to the developers had to have a hand and foot, as the result was incorporated into the finished version of Blender 2.8. But the developers also had to work more cleanly as a result. This time it was not possible to include shortcuts in the one movie branch.

2.79 to 2.8 – the big leap forward

The “Spring” team started production in Blender 2.79, but switched to the development branch of Blender 2.8 as early as possible. The use of this branch began at a time when important elements for film production were not yet available in 2.8. For a short period of time, a dual-track approach was therefore adopted. For example, the animation still took place in Blender 2.79, when lighting and look dev could already be realised in 2.8.

But even when the entire film was ported to Blender 2.8 and there was no turning back, the time of hardship for the artists was not yet over. After all, software in an alpha state is not exactly stable, and Blender 2.8 was no exception. Blender users who tried out the first early versions back in June last year will surely remember that the Blender 2.8 bug tracker was initially reserved for the “Spring” team. The developers already had enough to do with their bug reports alone.

It started in 2017

The initial planning and preparations for “Spring” began at the end of 2017, when Blender 2.8 was still little more than an idea or a branch with rudimentary changes. The switch to version 2.8 was only completed around six months later during the Code Quest, where a large number of developers came together over several weeks at the Blender Animation Studio in Amsterdam to programme together on site and plan the future of Blender. It was to take almost a whole year before the preview could be celebrated on 27 March.

The baby has taken flight

And while “Spring” is now finished and no further open movies are planned for the time being, the development of Blender 2.8 continues. It should be ready in July. However, Blender will have to overcome the last hurdles before the big release without the support of a parallel film production. It doesn’t really need to, because the bug tracker has since been opened up to ordinary users, and Blender 2.8 is already being used in commercial projects around the world. The days when a small group of artists in Amsterdam were the main source of feedback for developers are over for the time being.

Hopefully, however, the concept of open movies is not over. Because the development of Blender is far from finished, with Blender 3.0 already on the horizon. Perhaps this version will be accompanied by a feature-length animated film?

DP: I’m currently at FMX with Andy Goralczyk. He’s the director of “Spring”, the Blender Foundation’s new open movie, which you can see here in the cinema tomorrow.

Andy Goralczyk: “Spring” was made with the aim, among other things, that Blender 2.8 development should be accompanied by real artists who put the software through its paces during its development and use it in a real production.

DP: With “Spring”, however, you started with Blender 2.79 and did a lot with it in the film until you switched at some point. Why didn’t you immediately use Blender 2.8 for the production?

Andy Goralczyk: First of all, the framework conditions: We had just finished the agent film “Agent 327 – Operation Barbershop”. The producer, Ton Roosendaal, was very keen to produce a proof of concept for a cinema film. Of course, we did that in 2.78 and 2.79, which took a lot of time, so the whole endeavour of doing the animation test.

In the meantime, there was also the development work on 2.8, which took quite a long time. There was always the thought that Blender had to take the next step. There were some problems in the workflow, which is why 2.8 is called the workflow release. Blender is difficult to learn, there are thousands of areas Blender can work in and for each one the individual user has to customise their own workflow. This is one of the great strengths of Blender.

The whole thing was a bit slow, there weren’t enough people. There are never actually enough programmers, most people are responsible for bug fixes and maintenance. We simply need more funding to guarantee features, support, bug fixes and the entire project management. That’s the idea behind the institute.
After the barbershop, Ton said that we needed to take 2.8 a step further and spent some time researching the best way to do this. That’s when the Code Quest campaign was launched, in which we organised a funding campaign and spent almost a month trying to get programmers from all over the world who were already actively involved in Blender development to come to Amsterdam to take the whole thing a step further. That is, to bring all the loose ideas that existed – with tool systems, work spaces, look development, Eevee, wireframes or no wireframes, left-click, right-click and all that – under one roof. In the end, that was the starting signal that drove the whole thing forward.

We ourselves started with “Spring” independently. There was always the idea that we would use 2.79 and at some point in the future, when the time came, we would take the step of converting everything we had to 2.8. However, this has not been so easy, as 2.8 was only a concept for a long time. It was all this dependency graph stuff, copy on write, these incredibly difficult features that in turn enable other features, for example the whole linking system, collections, static and dynamic overwrites and so on. That set everything back a bit, because there were no modifiers, no animations for months. Everything was so rudimentary that you couldn’t do anything with it. We occasionally made proofs of concept, i.e. moved a character over to see what it looked like in Eevee, but it took ages before 2.8 became usable.

That was the idea behind the Code Quest. We were in our old office in the centre of Amsterdam, and then the Code Quest started and all the people moved to the new office in Amsterdam North, and we artists – we were only four people – sat there a little bit left behind in the empty office while all the new sexy stuff started in the new studio. We were then given the condition that when we moved into the new office, which was about a month later when the Code Quest was already running, we had to use 2.8. At the end of the day, that was incredibly ambitious, as it put fire under the arse of all the programmers. Blender was not yet far enough along to say: This is the framework of features that we need and that could be included in a 2.8 release. There were already specifications and then there were new things that were developed during the Code Quest, new problems that came up – if there is a tool system, where do the options for the tools go, all this interface stuff in addition to all the other problems that came up with Copy on Write and the Dependency Graph and with the Asset Manager, which was then scaled back a bit.

So we moved into the new building and we were able to do something. There were already a few modifiers, the array modifier, mirror modifier and subsurf, but not everything ran smoothly. It was really incredibly difficult. We then spent the next two weeks starting a kind of hybrid. Half of our film, for example the lighting work, we did in 2.8 and the animation work in 2.79 because the animation in 2.8, especially with the huge rigs we had for “Spring”, was really slow. That’s why we decided to start small and say: We’ll convert our rock library so that it runs under 2.8. You don’t have to convert very much, but you just make a separate file and change a few things here and there so that it runs under 2.8. Then we converted the characters, then a few of the environments, and then we slowly got it up and running in a proof-of-concept manner, bit by bit, until after two or three weeks the animators were finally able to switch over to 2.8.

DP: Once in 2.8, there was probably no going back?

Andy Goralczyk: Yes, there was no going back (laughs).

DP: In terms of the data structures, you probably can’t load it back either?

Andy Goralczyk: You can still app things or something, that wasn’t a problem. We were still moving things back and forth for a while, for example some things for Julien, who then made all the environments and background characters, i.e. the alpha creatures. He sculpted some of them in 2.79 because the sculpting tools were a bit behind, multi-resolution didn’t work, there was only dynamic toplogy and there were a lot of things that didn’t work properly. Of course things have to be made to work, but it’s a question of prioritisation. If you only have a limited number of people who are able to do this, then of course you can’t do everything at once.

DP: In this case, you had more developers than artists in the building?

Andy Goralczyk: During the Code Quest, yes. It has to be said that our developers mainly work on Blender itself and not on film-related features. This means that every now and then we get one or two, maybe Sergej or Brecht do something for us, but of course the programmers are all there for Blender and work on maintenance. We sometimes have to take a back seat. It’s a huge undertaking and, of course, it’s for a good cause and not just for us.

DP: Was there ever a point when you opened Blender 2.79 again and thought: “Oh, I’m in the Stone Age!”?

Andy Goralczyk: Also, yes. Actually from the point when 2.8 was running properly. Personally, I was able to get used to it relatively quickly. I’m not sure why, the animators still have a bit of a problem to this day, but of course that’s because the tool set for animators is different to that for environment and lighting, for texturing and sculpting or similar. There are simply fewer models for how something like this can work. All the work I did, like lighting and compositing shots, has become incredibly easy with 2.8 because there are collections. You have the ability to make an infinite number of layers and things that you can throw in there and name. You have an incredibly clean structure that you can give your files. This makes everything much clearer, but also makes the files much more complicated. In the beginning, we had huge problems with files that were far too large; our recordings are around 200 Mbytes in size, whereas before they were 60. They are now back down to 60 or 80 Mbytes. What it has allowed us to do, however, is a much greater level of complexity, also in terms of linking assets. We had to develop a bit of a new workflow around it. Before, you had groups that you could link to another file. Now collections work in much the same way as groups. They actually replace them, you can link them into a file, you can instantiate them, you can also link them directly, then you have a file that consists half of local assets and half of linked things.

DP: How do you manage it all?

Andy Goralczyk: It’s still a bit hairy and naturally leads to a lot of problems. But since it all started, I’ve never really wanted to go back. With the whole viewport, everything looks very smart of course, sometimes a bit too smart and a bit too slow. It takes some getting used to, but in the end everything looks much cleaner and much clearer, and that’s a good thing.

DP: Speaking of slower: Blender 2.8 has the new Eevee engine, which is relatively fast. Why did you decide on Cycles and not Eevee after the film was supposed to accompany the development of Blender 2.8?

Andy Goralczyk: That’s our main question on YouTube: Cycles or Eevee? You have to put it this way: the film was made with the idea of making it in 2.8, but of course there are many ways to make films. You can make a realtime film – the film lent itself better to Cycles than Eevee in terms of the story and the environment, the look we wanted. It’s possible to do some of that stuff in Eevee. We used Eevee a lot, also for visualising smoke simulation, for example, it’s incredibly helpful because of course you don’t have to patch everything. You have a good preview if you just throw it into Eevee and then render an OpenGL viewport playblast. I would say that even though it’s helpful to see things close to the final rendered image, real-time engines are still a bit behind in terms of shadows and reflections, for example. Back then, we had a scanline render blender internal with “Big Bug Bunny”, and all the lamps were shadow buffers. Similar to Eevee, except that Eevee is real time. We had incredible problems with shadow buffers all the time. As soon as you cheat things, you have more effort again, and we didn’t want to do that in this case. We wanted realistic lighting, realistic smoke, an environment that felt real. Of course, you can achieve that in Eevee, but then you always have problems – the anti-aliasing isn’t right here, the blur isn’t right here, the separation doesn’t work properly due to the real-time technology and so on.

DP: Are there perhaps plans for an open movie using Eevee after all?

Andy Goralczyk: There are no plans for an open movie in the near future. It’s possible that we could work in Eevee. We used Eevee all the time, for texturing, for previewing, and some of the passes from the film were even rendered in Eevee
Eevee. Cloud parts were simply recomposited, they were rendered one-to-one in Eevee and even Workbench. I would definitely like to make an open movie with Eevee. It’s a cool new technology.