Google Summer of Code: And the Winners are…

Last year, the result was a bit disappointing, but when I talked to Ton and Chris in the Blender Foundation chatroom, everyone seemed to be quite satisfied with the result. Thirty proposals were submitted of which Ton thought about 15 were serious enough to be considered. Chris Want, who will be coordinating the effort on behalf of the Blender Foundation, says:

There were a lot of great applications this year, and that made the decision process very difficult. I think the ones we’ve chosen will add some real benefit to Blender. We we’re surprised to get five proposal this year — big thanks to Google!

Coding will commence on May 28th. For the full timeline of the GSoC, look here. We’ll do our best to post regular updates on the progress of these projects on this website.

Below you’ll find the short descriptions of the projects from the Google SoC pages, combined with comments from BlackBoe that I found rather useful.

Congratulations, winners! Make us proud :)

Proposal to implement deep shadow maps and a tiling disk cache in Blender
Joseph Eagar, Mentor: Martin Poirier

This proposal is to implement deep shadow maps, including mipmapping, motion blur, colored shadows and filtering, in Blender. Also, a generic disk cache mechanism will be implemented.

Deep shadow maps are an advanced technique to make high-quality shadows. They work by storing additional samples and transparency info inside of the shadows, allowing for advanced techniques such as mipmapping and motion blur to be applied to shadow maps.

Since deep shadow maps take a great deal of memory, a generic tiling disk cache will also be implemented. This system will simply swap shadow map tiles to disk as needed to keep RAM consumption below a user-defined limit.

BlackBoe:

Deep shadow maps are good for hair and volumetrics and are pretty much in every way better and more detailed than regular styled shadow maps. Coloured transparency, motion blurred shadows, etc. They take up more space, though, so he’s going to make a swapper for them as well, so they don’t drain RAM so much.

A Render API for Blender (version 3)
Aaron Daniel Moore, Mentor: Ton Roosendaal

The current system for converting Blender’s database into render data is awkward. This has two important consequences. First, the system is difficult to maintain. When Blender changes there is no well-established module for the export of the new data for rendering; instead the existing export code must be searched for the places which need changes. Second, it is difficult to integrate external renderers. I propose a render API take the place of the current system. The current setup’s main fault is its lack of structure. Thus, the most obvious change would be to create a well-defined, documented protocol here. By providing easy functions for the access and export of Blender’s scene data, both problems would be solved.

The current system which interfaces between Blender and its renderers (mostly in convertblender.c) would be replaced with two separate systems which perform its task: the render API and the exporter. A plug-in system would be created so that by swapping DLL/SO plug-ins Blender could switch which renderer it is hooked up to internally. Code would be created to connect Blender’s internal render via the API, completing the replacement of the existing system. Furthermore, detailed documentation of the render API would be published online to facilitate the production of exporter plug-ins for external renderers.

BlackBoe:

Render API. Currently, the Blender Internal renderer is tied into Blender in one big, tangled, disorganised mess, all loose wires sticking out. It’s hard and unpleasant for anyone to do any work with render systems. The API will take all the loose ends and tie them into a standardized ‘plug’. This’ll be easier to take care of, and also allow for faster, cheaper, easier and more efficient addons for pretty much any renderer ever, Indigo, Sunflow, Yafray, Renderman, etc.

Blender audio system cleanup and upgade
Csaba Hruska, Mentor: Robert C. Holcomb Jr.

The main purpose is to remove every other sound code references from lender source than SoundSystem library.
The other task is removing unneccessary dependencies (fmod, openal) from SoundSystem code with keeping API unchanged.

The only used library is SDL, because it`s good multiplatform support. Openal will be replaced with verse project`s audio system code (code is available in verse blender source).

BlackBoe:

Blender audio system upgrade. Right now Blender’s sound system is like an old toolbox, filled with odds and ends and old bits of junk which might not be useful but which no-one wants or has the the time to throw away. It’s a basic cleanup and upgrade job, though it’ll take a while, considering the mess.

A GLSL Shader Editing and Preview System for Blender
Miguel Torres Lima, Mentor: Brecht Van Lommel

This project’s goals are: to implement support for improving Blender’s current material display in the 3D View window, using GLSL programmable hardware shaders; extend Blender’s 3D View real-time material preview to support node-based materials by implementing a system to combine shader fragments that represent each node of the graph at real-time and, from those fragments, generate GLSL shaders; create a GLSL shaders representation for Blender’s material nodes.

Further objectives, if the remaining time allows are: to create a generic GLSL shader node, allowing users to create their own shader in Blender’s Text Editor window; to allow to import/export GLSL code for a material node network and to integrate it with Blender’s scripting system and the forthcoming PyNodes API.

BlackBoe:

GLSL Shader Editing and Preview: Basically, a big revamp of how the Blender 3d windows draws materials, this time using GLSL pixel shaders. Will probably be a crapload better than ‘textured mode’. :P

Mesh bevel and offset tools/modifiers
Levi Schooley, Mentor: Geoffrey Bantle

Tools to create beveled edges are very important in technical modelling and rendering. However, it is also important that the artist have as much control over the process as possible. During modelling, the artist should be able to bevel selected faces/edges/vertices, choose the appropriate beveling method, and accurately set and view the final result in real-time. Also, a mesh-wide technique for producing a beveled result would be very helpful, mainly for rendering. This would be best implemented as a modifier with options to bevel based on edge crease values, vertex weights, and percentages (based on face joining angles and face area sizes).

In addition, based on the fact that there is a shared interest and perhaps even similar algorithms, the creation of a parallel offset tool would be a great benefit to technical modelling. A parallel offset tool increases or decreases the area/volume of a mesh while attempting to keep the points on the resulting surface as equidistant as possible to the original surface.

Advertisement