Development targets for Gooseberry

La blender fondation vient de livrer sa feuille de route sur les développements de Blender pour Gooseberry !

This morning I had a first kick-off meeting with Campbell, Sergey, Lukas and Antony – to evaluate possible development targets for the film. We really hope to be able to tackle a number of issues that already are being postponed too long.

Hair simulation

Lukas summarized the progress with hair code so-far, the issues and the doubts. Main issue is that there’s complicated existing code that sortof works, main doubt is that there are designs already for a new particle/hair node system. When is work on the existing code a waste of time, and how feasible is it to make a new system from scratch?
Decided was that Lukas keeps working on the existing system, and work with the artists here to create a final-film quality hair sim shot a.s.a.p.

Object Nodes for transform, constraints, drivers, modifiers.

Well. Let’s add particle and hair nodes in the mix too! But it’s a too big project to expect results for within a few months. Lukas will work on this part time (half day per week or so) to make a prototype – if he has time and energy left!

Hair sim editing

“The best sim is no sim” – this whole simulation feature should be nearly invisible and in perfect artistic control. So we need tools to manage stable contact-collisions, set keyframes for hair guides, bake and edit caches. Or even some kind-of modifiers with hair-vertex-group weight control.

Dependency Graph

Sergey already worked on threaded object-updates, and will further check on handling and solving dependencies between transform and modifier updates. Or even just solve the whole deps issue enitrely – including materials, nodes, point caches, and so on.
He’ll be using work as done by Joshua Leung for GSoC last year. Joshua has accepted a Development Grant to work with us in Nov/Dec as well. We want this to be solved before final animation on shots start in January. Rather sooner though – riggers totally depend on this to work.

Cloth sim

One of the main film characters is a person in a suit. Simulations for regular clothing are the hardest ones to get right, but can be incredibly rewarding and time saving for the animators. Issues here are similar to hair sim – Lukas will check on upgrading this as well, including good contact/collision handling and properly integrating Bullet physics.

Rigging and animation tools

Antony started work on a “custom manipulator” system, which technically has been named “window manager Widget” now. The system will allow to directly hook up an event handler with a 2d or 3d item in a view. Everything can drive an operator then!
Imagine controls in Blender for for anything (for example a lamp spot size widget, spin tool rotation widget, a scale widget for selection in dopesheet editor). Widgets can even be parts of an existing mesh model, so riggers can use it to make invisible input ‘widgets’ for posing.
Sergey will check on the “Implicit Skinning” code – which should be available as GPL-compatible soon.
Note: Daniel Salazar and Juan Pablo Bouza will be our riggers, they are in daily contact with us on features and design topics. (And check the bf-animsys list please!)

Viewport upgrade (OpenGL 3, 4)

A good quality preview of characters and shot layouts is very helpful for a film project – a real time saver even, especially with real-time Subdivision Surfaces and real-time fur drawing. A side topic to look at is to work on improved (editing of) shaders in the viewport – for modeling as well as preview rendering and of course for the GE.
Antony is already working on this, together with Jason Wilkins (GSoC Viewport project) and Alexander Kuznetsov.

Alembic support

We should really work on unifying the use of animation caches in Blender – including support for entire characters, with particles, hair, fluid and smoke. Having such caches stream in real-time in Blender would be much faster and prevent issues with instancing, duplication and linking issues as well.
Campbell will work on this further.

Cycles

Well – basically we only have 1 real problem with Cycles rendering. Speed!
Sergey has a couple of ideas he will be starting to work on first – especially for more efficient sample schemes. We also discussed a couple of ways to optimize renders using coherence better (or just simply bake things automatically).
We have an offer from Nvidia to use a massive cluster (16 x 8 of their best gfx cards) to render the entire film with. Will be tested and checked as well.

Image Cache

We had this feature working for the 2.5 render branch (for Sintel) already. It means that Blender (or our asset system) should manage automatically the resolution levels of image files we need, especially to handle the larger textures – which can easily go into 10k x 10k pixels. In many cases (like viewport work) you don’t need to load all the large files anyway. Campbell checks on this.

Pipeline

Blender’s dynamic .blend linking feature has to get in control much better – with a UI to manage it, update things, split or merge, pack or unpack, etc. We need ways to define “assets” for fast re-use, for versioning and for ‘levels’ or resolutions (low res character, high res final characters). Linked data should also work with partial local overrides (called “Proxy” now in Blender) – so you can locally pose characers, or to change just 1 parameter of a shader system.
Then there’s a need to define a “project” in Blender, to link Blender files together with a root path to work with – for example.
Last but not least – we’ll check on coding a “.blend file compiler”. This is code that can split up .blend files (in assets) and re-assemble it again – for example based on an artist’s job description in a project. On submitting the job back, the compiler then simply splits up the job again and only stores the relevant piece. Probably – hopefully – this compiler can bypass a lot of problems we have with linking and proxy now.
Campbell will start working on the pipeline with Francesco, next week.

Compositor

The compositor still lacks a a good way to define and use coordinate spaces (placement of node images inside a canvas). Speed is always an issue too! Most likely Sergey will be working on this.

Sequencer

Antony already has been fixing quite some issues here for Mathieu (who did the animatic storyboard edit). Aside of general usability issues, he’ll be working on bringing back threaded pre-fetch.

Modeling and sculpting

Both Antony and Campbell love to keep tools work here in a perfect state – right after this meeting they shared progress on allowing to sculpt holes in meshes. That’s much needed by Pablo now, and he’ll get it in a few days.
So – this was just a 2 hour discussion summary. Are we really going to do all of this, or even more? Who knows 🙂 The Mango development target list had quite some of the above topics as well. Time will learn! You’re welcome to help though. Our development project is open (go to blender.org, “get involved”), or support us directly by joining Blender Cloud.

Special thanks to the members of the Development Fund and the 1000s of people who already supported us during the Gooseberry campaign (and who are massively renewing their subscriptions now) – thanks to you we can afford to have a lot of developer and artist powers on tackling it all!

-Ton-