The Gooseberry project moves ever forward and the team is deep into making the movie. Blender is being put to the test again and modified to meet the needs of this production.
So, what do code monkeys do in this environment behind the scenes? What are their eating habits? What branches do they climb on? What does a code banana look like? Are there gnus around? Are there monoliths with a strange black surface? This post will attempt to answer those questions, specifically regarding the habits of the code monkey specimen known in the code underworld as Psy-Fi. (That’s me.)
As production proceeds, we have moved from modeling assets to animation, so we are slowly shifting the focus to animation tools. My personal tool-coding list consists mainly of animation-curve visualization, Viewport code overhaul, and the widget project.
Animation-curve visualization is a pretty straightforward feature: we generate a set of points in 3D space where an object or bone has passed through during animation and present that to the user. This already works in Blender, but we want to make it better. There are 3 ways we’re trying to do so:
The widget project mainly consists of creating clickable and dragable widgets in the Viewport, which can enable various functions to be executed easily. Those can include transforms or even sliders to control properties of rigs and meshes. This should in theory alleviate some of the need for animators to actually select bones to animate and also might enable more intuitive interaction with objects in general, if we define meshes themselves to act as widgets. Campbell and I have done some experiments and code for this project over the past months, with Ton acting as the proverbial monolith in this Space Odyssey, providing ideas and guidance; and Julian will join us shortly to help carry on the torch.
Aaah, the Viewport project! You might want to read the code blog post for more details on this. This is, strictly speaking, not tied to the Gooseberry project anymore, since it’s highly unlikely that the Gooseberry crew will benefit greatly from it (apart from drawing code optimizations). At the beginning of the project I allocated some time to investigate depth of field in the Viewport to make it easier for Mathieu to make choices in his direction during the animatic stage of the production. As a byproduct, we also had real-time Ambient occlusion to help with modeling and sculpting. Currently though, we aim for more Blender-related targets: physically based rendering in the Viewport, performance improvements, and support for modern graphic card features. Basically we’re trying to make Blender’s Viewport faster and more beautiful than before, even making it a viable choice as a rasterizing engine.
Over the past weeks, I have spent a sizable amount of time trying to get existing code by other coders to work with recent Blender versions, as well as read up on modern graphic card capabilities and techniques, and experiment with some of them (such as a new method for the depth-of-field effect that made it into Blender today).
Editing is crucial in this movie. Mathieu never stops asking for Sequencer features. Even as I’m writing this post, he hovers above my chair repeatedly asking for improvements on how strip proxies are stored on the disc, for instance, while sweet glockenspiel music is coming from Francesco’s sheep doll nearby. This means I should stop writing soon though and start looking at his problem.
Last but not least, we have painting. Lots of small improvements were done, such as cavity masking, which was added after Andy made a random remark about the lack thereof, or random angle support for raked brushes, which was added as a Christmas gift to Manu. There are also larger structural changes planned to fix long-standing bugs and limitations.
You never know when an artist will throw the contents of his desk on the wall and start running, screaming hysterically while swearing at the software, the universe, life, and bad coffee. That’s why prevention is the best measure, and we try to keep Blender as bug-free as possible and, thus, keep such moments of frustration to a minimum. One day per week (Thursday for me) is bug-tracker day, and I have to take care of bug reports in the Blender tracker. We also have to take care of bugs in new features, but luckily a studio full of capable artists is more than enough to get feedback and stabilize the code before “masterizing” it (that is, adding it to our official Blender releases). Needless to say, any breakage that is really urgent in the studio often takes precedence over other requests, since we need to keep things moving.
Aaaand, that’s it! I hope at least some questions about the ecology of code monkeys have been answered.