How open film project Cosmos Laundromat made Blender better

No readers like this yet.
Blender film image

The Blender Institute. CC BY 3.0.

At the beginning of August—the 10th, to be exact—the Blender Institute released Cosmos Laundromat: First Cycle, its seventh open project (and sixth open movie). Cosmos Laundromat, or Project Gooseberry for those of us who have been following its production from the start, isn't just a 10-minute short film. It's also the Blender Institute's most ambitious project to date, serving as a pilot for the first fully free and open animated feature film.

You can watch the film right now. (Fair warning: Cosmos Laundromat is animation for grown-ups. It's safe for work, but some folks may not find it appropriate for children.)

What's an open movie?

If you're not familiar with the string of open projects that the Blender Institute has kicked out over the years, you might not be familiar with the term "open movie." Simply put, not only is Cosmos Laundromat produced using free and open source tools like Blender, GIMP, Krita, and Inkscape, but the film itself, and all of its assets—models, textures, character rigs, animations, all of it—are available under a Creative Commons Attribution (CC-BY) license. Want to see what a production character rig looks like? Or know how that giant color tornado was created? How about actually using a character (or just a prop) in your own project? Maybe you even want to redo the entire film to your own tastes. It's an open movie! You can!

Furthermore, the movie itself serves as a proving ground for the open source tools used to produce it. Developers are on-site and get a very real sense of how artists use (and sometimes abuse) their tools in an actual production environment. Not only is this a benefit for understanding user interaction, but it really shines a light on pain points and bottlenecks. In the best case, developers can come up with quick (or at least prioritized) solutions during the production. More importantly, however, the experience gives developers understanding and insight for coding projects that begin after production is over.

All of the Blender Institute's open projects have been released this way, and they're not stopping with Cosmos Laundromat. Alumni crew from previous open movies are already in planning stages for another open short film, tentatively titled Glass Half.

An ambitious plan

Cosmos Laundromat was born as a much bigger idea than this 10-minute short. Its aim was—and to some degree, still is—to be the world's first feature-length animated open film. Of course, funding and producing such an ambitious project is no small matter. All of the previous open movie projects produced by the Blender Institute received a large proportion of funding from crowdsourced pre-sales, many of them before the advent of more convenient mainstream crowdfunding platforms like Kickstarter and Indiegogo. And although these projects raised considerable sums of money (nearly all greater than 100,000 euros), a feature-length film has much greater financial requirements and more challenging production logistics.

Courtesy of the Blender Foundation. CC BY 3.0.

The Blender Institute estimated that the minimum budget to complete a feature-length open movie would be 2.4 million euros, and roughly 20% of that would be needed at the very start of the project. (At this point, it's worth noting that this is a very modest cost compared to big-time Hollywood animated productions with budgets well above the 100 million mark.) Production-wise, the plan was to helm primary production at the Blender Institute's location in Amsterdam while the bulk of the movie would be broken into parts and produced by a dozen other studios around the world. These studios would, of course, use Blender as a major part of their production pipeline.

It was from this plan that the Blender Cloud was born. The primary purpose of the Blender Cloud was to facilitate the distributed nature of the production, serving as a hub for production assets and planning resources. Simultaneously, subscriptions to the Blender Cloud would help pay for the production and software development costs required by the Gooseberry project. Subscribers would get inside access to the film's production as well as the Blender Institute's massive library of training resources (with additional instructional material from the Gooseberry artists).

These were big plans. Huge ones, in fact. To pull it off, the Blender Institute would need to raise 500,000 euros right from the start of the production. The rest of the funds would come from continued cloud subscription fees, plus some additional sponsorship and subsidy money along the way.

Falling short, failing forward

The initial crowdfunding campaign launched in March of 2014 and ran through that summer. The goal was to add 10,000 subscribers to the Blender Cloud. Unfortunately, despite the fact that the community raised more money for this project than for any of the previous open projects, this campaign fell quite a bit short of the desired goal. Less than half.

Still, this was an impressive start. A proposition was made to the community of contributors: the Blender Institute could either drop the project altogether or it could pare down the project's ambitious production goals to match the actual funds that were raised. Ultimately, the community opted for the latter. Rather than pursuing a feature-length production, the story would be truncated to a 10[-ish]-minute pilot that gives a sense of what would be in store for viewers in a full-length film. And rather than spreading the production to studios all across the world, the production would be centralized at just the Blender Institute's location in Amsterdam. The Blender Cloud would remain an important component of both the film and the community's involvement (via feedback and funding).

So what did we get?

Courtesy of the Blender Foundation. CC BY 3.0.

Roughly one year later, the production is complete. According to Ton Roosendaal, who helms both the Blender Institute and Blender Foundation, the production costs weighed in at just under 400,000 euros. This paid for everything, including three full-time developers, two developers for three-month stretches, seven artists for a 10-month period, and four artists for three months. The results? In addition to a visual treat of a film with a great start to an engaging story, there were quite a few development milestones:

  • Improved hair/fur simulation and rendering
  • Enhanced 3D view (with cool effcts like screen-space ambient occlusion and depth of field)
  • Painting features and performance increases (including cavity masks)
  • Updated/improved dependency graph
  • Forceviz forcefield visualization
  • Filebrowser preview of image sequences (including playback)
  • Sticky keys
  • Progress integrating open source libraries such as OpenVBD (volumetric data), Alembic (mesh caching), and Ptex (high-detail textures)
  • Two external-to-Blender tools for rendering and pipeline management, Flamenco and ATTRACT
  • Lots of bug fixes
  • And of course, a wide array of small, but time-saving enhancements all across Blender (particularly in tools for animating, sculpting, and sequencing shots). These are the kinds of important improvements that can only be made by being in the same room as artists while they work.

A more in-depth listing of development contributions was recently posted on the Gooseberry blog. Of course, many of these features are still in the Gooseberry development branch and may need some refinement and polish before being migrated to the master branch. For instance, although there were a bunch of improvements to Blender's existing hair and fur system, those blocks of code were more of a stop-gap to facilitate the production of Cosmos Laundromat and might not be directly merged with master. Instead, the lessons and experiences in writing that code for a real production will be the foundation for a near-future refactoring of the hair and fur system that yields better, more stable, easier to control, and more production-friendly results.

It's also worth mentioning that throughout the year that Cosmos Laundromat was being made, Blender continued to get additional development energy that was not related to the film's production. Blender's regular high-paced development continued, with no less than 4 major releases in that time span.

What's next?

As the subhead for the short movie indicates, this is just the first cycle. The hope and plan is to finish the film in an episodic way. Exactly when and how that will happen remains to be seen. The Gooseberry crew has been incredibly busy the last few weeks with the film's release, attending SIGGRAPH, and screening their film on-site at large Hollywood animation studios like DreamWorks and Pixar. They're due a well-deserved break.

We do know a few things, though. The Blender Cloud is still going strong, with new content being posted regularly and a growing base of subscribers. The next immediate bit of production energy is going to be focused on the Glass Half short. The next release or two of Blender will involve merging some of the remaining code from the Gooseberry branch, but as Blender approaches the release of version 2.8, the pace of releases will slow a bit as developers turn their focus to workflow improvements.

When will we see the second cycle? Will it get produced at all? It's difficult to tell. According to a recent blog post, the script has been "written, designed and mostly storyboarded." The preference would be to stick as much to the original plan and perhaps relay the production of each episodic piece of the film through Blender-based production houses around the world (with unifying direction and guidance from the Blender Institute).

In any case, it's an exciting time for open source creative tools. Cosmos Laundromat shows just how capable they are. And who knows? Perhaps you'll be the one to produce the next leg of the film. After all, it is an open movie. Isn't that what it's all about?


This article is part of the Open Art column by Jason van Gumster. Do you have an idea for a story about an open source art tool or project? Submit your article idea.

User profile image.
Jason van Gumster mostly makes stuff up. He writes, animates, and occasionally teaches, all using open source tools. He's run a small, independent animation studio, wrote Blender For Dummies and GIMP Bible, and continues to blurt out his experiences during a [sometimes] weekly podcast, the Open Source Creative Podcast. Adventures (and lies) at @monsterjavaguns.


How many of those new features did actually make it into master?

The link to the Gooseberry blog (under that list of features) gives a better accounting, but from memory: 3D View enhancements, painting improvements, sticky keys, pie menus, updated dependency graph (though still disabled by default), VSE improvements, and I'm sure I'm missing a few.

In reply to by Pep (not verified)

Ok, I saw the Gooseberry blog post. There are quite a few features that didn't make it into master. All in all, this seems to be little progress in terms of development considering it took a year and (very probably) a sizeable part of that 400.000€ budget.

In reply to by Jason van Gumster

Bear in mind that the blog post is the account of just one of the developers. Also note that for that budget, there were twice as many artists as there were developers. And the biggest improvements from a open movies come in more subtle things like workflow speed-ups and resolving somewhat mundane (but very important) day-to-day inefficiencies that developers might not otherwise know (or believe) exist.

In reply to by Pep (not verified)

As Jason already stated that is only one of the developers. Reading through the release log of Blender itself you will find tons of optimizations for the Cycles render engine that also stem from Gooseberry but have been done by two other devs.

In reply to by Pep (not verified)

Thanks for the info, Gottfried. That's interesting, although a but too vague. Could you provide a few examples? I can't shake this feeling that, despite everyone relevant in the Blender community trying to convince us to believe the opposite, funding an open movie is just that: funding a movie. I don't have any problem with that, and I didn't really find any problem with the finished result (didn't specially dig it either, just not my cup ot tea). These open movies are useful and necessary to showcase Blender around the world, but I really doubt they are that beneficial to development. As for astists and developers being in the same room... Well, I'm sure it's helpful, but if it was really necessary for the advancement of software, commercial software wouldn't be useable at all, right? There are other less expensive ways of getting user feedback.

In reply to by Gottfried Hofmann (not verified)

This specific open movie may not have the "ooh, wow" feature development that previous open movies had (Blender's compositor came from Elephants Dream, Big Buck Bunny refined animation tools as well as hair/fur, Tears of Steel brought a lot of development to the motion tracker, Sintel was a field test for the 2.5 refactor... and the Cycles renderer itself is a direct result of lessons learned from that production), but what we did get was still a big deal. And, like with previous projects, the things learned by the developers during the project are likely to show up in future features/upgrades.

In reply to by Pep (not verified)

You see, Jason, that's where I think the problem is. Raising much more money than previous movies and showing in exchange for it so little progress on the tool when compared to previous projects might (and probably will) create the impression on the community that Blender Foundation is driving funding mostly to artists and away from developers just for the sake of pursuing someone's artistic goals.

Asking people to fund the development and maintenance of a free open tool is one thing, asking them to fund someone else's artistic endeavours for its own sake is a very different thing altogether. And while there are many who don't care funding both things, there is probably a good portion of the Blender user base who only want to fund Blender development and want nothing to do with movies produced by the Blender Foundation. It wouldn't surprise me if that turned out to be one of the reasons (if not the main one) for the funding campaign's initial failure.

By tying development (at least partially) to open movie projects that emphasize art over development, Blender Foundation might end up driving away potential backers who only want the tool to improve and are not interested in funding other people's art.

My opinion? BI should get back to smaller and cheaper open movie projects that help ironing out workflow issues and development of very specific features, with artisitc quality in mind in order to proudly showcase Blender's capabilities in the final product, but with a clear empahsis on tool development. I might be wrong, but in the long run doing otherwise might hurt BF's sustainability.

In reply to by Jason van Gumster

I guess that's the difference. I don't see it as "so little progress". Sure the other open movie projects saw the birth of big new features. But most of those features didn't get polish and refinement until after the project... and informed by the experience. Again, this is exactly how Cycles got its start. Not to mention all the little fixes and time-savers that got added in the course of the production.

Note also that there *already* is a way for people to contribute to Blender development outside of the open projects. That's the Blender Development Fund. It's still there and going steady. And the fact that Blender Cloud subscriptions have been increasing rather than decreasing tends to indicate that there's a good chunk of the user base who are actually pleased with the direction the BI and BF are headed.

In reply to by Pep (not verified)

Compare $400,000.00 for developers and artists... that created a short movie and improved the software environment along the way... to Microsoft spending about $500,000.00 (on a Hollywood production crew) to make the desktop background image for Windows 10. Which was the better value?

In reply to by Pep (not verified)

Hello Pep,

The problem with polishing and optimizing software is that it's not shiny big features but small things that are necessary nonetheless. Polishing is what makes a software cater to the professional's needs, but it's nothing shiny. And it takes a lot more time and effort to polish and optimize than to hack shiny things. In that regards, the GB crew did really well.
Let's take Cycles for example. In Blender 2.76 you are able to render scenes that are a lot bigger than what's possible say in Blender 2.71. And it will render a lot faster on CPU as well.

For GB it was the first time that no compositing was needed because they could render everything directly as seen in the viewport, like the "big guys" over in Hollywood do. Because everything fits better into RAM and renders faster now.

I will provide examples for Cycles optimizations (which were needed for GB) from release notes ( going from 2.76 backwards. Note that these are only optimizations to Cycles, I am not listing the improvements to animation, VSE, general workflow, I am not listing new features and I am not listing bugfixes:

Camera space object culling
Optimizations in Spatial Split BVH build time
Free caches used by the synchronized objects
Free polygons after tessellation in order to reduce peak memory usage
Free unused images when rendering with locked interface
Reduce peak memory usage of scene synchronization by passing data ownership when converting derived mesh to mesh
Synchronize images after building BVH, reducing peak memory usage in production files
Avoid sloppy memory usage by BVH leaf nodes by splitting BVH nodes storage into inner and leaf nodes
World MIS table building is now multi threaded, reducing scene startup/update time.
Skip consecutive empty steps in Volume Decoupled Ray Marching code.
Make material preview rendering more responsive for complex shaders
Remove Emission shaders from the graph if color or strength is 0. (67eb2c789718)
Record all possible volume intersections for SSS and camera checks (b3def11f5b75)
Use native float->half conversion instructions for Haswell CPUs (2ec221aa281d)
Ray/Triangle intersection is now watertight. This is expected to address quite a reasonable amount of reports from the bug tracker, plus it might help reducing the noise in some scenes.
Implementation of a QBVH optimization structure for CPU with SSE2 support and above. GPU rendering, non-SSE and 32bit processors still using regular BVH. (03f28553ff07)
Optimize black world backgrounds (cd723967970e)
Optimize vector math node without links to a single value node. (43421e9c5354)
Reduce lag between shader tree modification and viewport render (2dfe5e3)
Fallback to bottom-top tile order when rendering from the command line (bb08502)
Optimize memory usage when creating mesh attributes (1862fbf)
Reduce memory used by background light update (0f65250)
Optimize memory usage during BVH construction by freeing memory used by intermediate BVH vectors earlier (3bc9ac1)
Use lower progressive update timeout for preview rendering, gives more instant material feedback
Optimization for Mix RGB shaders (Mix blending mode), when the factor is 0.0 or 1.0
This reduces memory usage and improves performance a bit. (cbffc7499ef8)
Optimize math node without links to a single value node (6a4a911fc39ffc)
Faster rendering of homogeneous volumes, when using decoupled ray marching
Several performance improvements for Heterogeneous Volumes.
Importance sampling for Glossy and Anisotropic BSDFs has been improved, which results in less noise per sample. The gives increased render time as well, but it's generally more than compensated by the reduction in noise.
Decreased memory usage during rendering. (49df707496e5, 0ce3a755f83b)
CPUs with support for AVX2 (e.g. Intel Haswell) render a few percent faster.

In reply to by Pep (not verified)

The only way to create a production ready tool is to use it in production. Real-world testing is invaluable if only to focus development efforts on features that actually are affect the users instead of developer pet projects. "Test scenes" aren't sufficient to create a usable product.

In reply to by Pep (not verified)

You don't have to have hired artist and be in the same room to know what to improve. In many areas it's obvious. Or you believe Blender is that perfect? Please..

I work in a studio as a TD and work with Blender 8h/day. I could talk and talk for days what to improve. And I would have told you the same plus more what you also came up with.

400k EUR for that little progress - yeah you wasted them.

And here is the real pity, you state you already knew these improvements needed to be made, but clearly did not communicate these to the developers of the tool that you are using in production.

You state you know of further improvements that can be made, well then, sit down and write them up and communicate them to the developers. Remember, what is obvious to you will not be obvious to others, so please avoid making that mistake.

BTW: From my perspective you are boasting about doing nothing when you could have helped, this reflects poorly on you. I also encourage anyone else who can help to do so, as it ultimately benefits you also.

In reply to by Jerry (not verified)

@Jerry: so, why don't you file bugreports/enhancement-requests to developers, instead of ranting here.

In reply to by Jerry (not verified)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.