You can contact us via our developers mailing list
Or via IRC
You can also use our wiki.blender.org, your private page, to write down proposal drafts for discussions.
For matters you prefer to discuss more in private, mail Ton Roosendaal: ton at blender.org.
GSoC Project Ideas 2013
The following list provides some ideas for projects that
1) a student coder can complete in the time frame given (hopefully not too easy, and not too hard); and
2) implements topics marked as "to do" by current developers, implements a coveted feature request from our user community, or improves upon existing code.
Each project has multiple potential mentors (we usually have at least 3 individuals as potential mentors for each project). So if you are interested in feedback or discussion of an idea please email our development discussion list bf-committers or visit or irc channel #blendercoders .
Additional project ideas may be added to this list, so you may want to check this page later as the application deadline looms.
Please note that proposals that have been merely cut and paste from this list of project ideas with little value added will be swiftly discarded.
All projects will require a strong working knowledge of C/C++, in addition we use Python for much of our interface code (anyone skilled in C/C++ can trivially learn enough python to make the needed interface code changes). We use C++ in game engine code; and C++ is also present in many of the libraries we use such as the Bullet physics library. However all C++ libraries use a C interface when accessed from within the Blender core code.
(don't add to this list unless you are a developer who could potentially mentor the project)
Getting the big picture
A good illustration of projects we do for Blender you can find on many places at blender.org and our wiki. For example check on:
Mesh Custom-Data Transfer
A generic system to move custom-data between different mesh objects.
Currently we have such a system but its limited to vertex weights.
Support different methods to transfer mesh data.
- spacial - find close points on both meshes.
- ray-casting - do ray-trace lookups to identify similar geometry.
- topology - 2 meshes with the same or similar topology.
Support for copying vertex/face custom-data: including shape-keys, uvs, vertex-colors.
Some custom-data would need special handling.
- UV seams would need to be handled to prevent a single face getting UV's from different islands.
- Shape-Keys (may want to limit which ones are copied).
This project would involve refactoring the existing weight copy tool into a more generic system.
Modifiers are probably one of the best introductions to coding new modeling tools. Modifiers have a well-defined API (DerivedMesh comes in, new DerivedMesh goes out), so the student need learn only a small part of Blender's internals before becoming productive.
Ideas for modifiers can come from academic papers, but be sure to check details of the paper for full understanding (e.g. if interpreting the paper requires knowledge of some mathematical field, be sure you have that knowledge before taking it on as a project.)
- Boolean modifier could be improved in several ways:
- Currently N-Gons are triangulating before sending to Carve library. But this library supports planar N-Gons and supporting them in BSP would really be nice thing.
- Improve behavior in cases if non-closed manifolds, co-planar intersecting faces, double geometry and so.
UI and Workflow
- Make a custom and customizable "manipulator handle" system in Blender, which can be used for purposes such as rigging (handles to transform bones), tools (Spin, Screw), or editing properties (Lamp spot size).
- Blender's "snap" feature for transform has many open issues. todo list, and could get more common features for precise modeling. Needs proposal from someone experienced with CAD or architecture modeling.
Muscle system for character rigging. Can have several aspects:
- Under skin volume simulation:
- New muscle primitive (maybe a bone type) that repels the mesh with a spheroidal algorithm. You should also be able to move this object and it should make the skin slide over it. A Simple jiggling effect could be added to the bone.
- Refactor Shrinkwrap modifier to work with geometry based muscles in a smooth and fast way
- Refactor Warp modifier to be able to produce non spherical forms
- High resolution muscle tension or skin wrinkle animation:
- multires sculpt keyframing (follow mesh shapekeys)
- Blender's Sequencer is carrying over a lot of code from the past. The core for its "Strip" definition and handling could be recoded entirely, including better visualization. This is not a typical beginner project though.
- Blender's Sequencer internal 'rendering' code could get a similar recode, bringing it back to more clean APIS, and especially look at (optional) GPU support for color operations.
Generally, this is a complicated area (requires lots of knowledge in mathematics and computer vision), but there're also some simpler projects:
- Tools improvement. For example scene orientation operators could be improved in a way, so after every structure solution it's not needed to re-orient scene again and again and again. Will also need some nice user interface for this. Stabilization tools are also pretty much basic at this moment.
- Lens estimation, will require some mathematics involved. But also algorithms from other open-source libraries could be adopted here. Same goes to grid calibration.
- Current algorithm used for feature detection is also pretty basic. Could be improved and made more robust for outliers.
- Reconstruction from non-calibrated camera.
- Single frame reconstruction using manual survey data.
- Variable focal length, so motion reconstruction could happen in cases focal length is changing across the footage.
- Point clouds reconstruction and orientation, using unordered sequence of photos.
- Multicamera reconstruction, in terms several cameras are shooting the same scene.
The new Cycles rendering engine has a huge number of opportunities for GSoC projects. Generally speaking a student interested in working on our rendering engine will want to have experience with rendering algorithms and generally a strong math background. OpenCL and/or CUDA is a bonus but for most projects is not necessary. Pick enough tasks to fill up the GSoC time.
- Temperature to RGB color node
- Ambient occlusion color node
- For specifying custom AO normal and using it as shader color
- Point/vector space transformation node (world <=> object <=> camera)
- These matrices are available, just need node implementation
- Diffuse and Phong ramp BSDF
- Gabor noise node
- Can generate many interesting patterns, might need good UI for parameters
- Better anisotropic BSDF (ashikhmin, D-BRDF?)
- Light Groups
- Per-object ray offset bias, to deal with terminator problem
- Split/Combine XYZ node
- Currently is done with RGB, seems a bit hacky
- Per object multiplier for motion blur shutter time
- OpenColorIO integration
- Option to clamp BSDF reflectivity by e.g. 0.8 (for faster convergence/correctness)
- Transparency and refraction might need exceptions?
- Use render visibility when selecting render layer preview in viewport
- Needs depsgraph fixes
- Add Ray Depth to control the number of bounces from a shader
- Add Ray Roughness to manually control roughness filtering tricks
- Fresnel node should get a Normal input.
- Add back worley weights to voronoi node.
- Access to object color and other object properties from nodes (support RNA paths?).
- Option to include environment lighting in shadow pass.
- Use OSL metadata for sockets name, min/max, default texture coordinates.
- Better auto position when adding nodes (with multiple inputs nodes overlap)
- Auto sync BSDF color and viewport color
- Needs some algorithm to deal with mix shader hierarchies, to find the good diffuse node
- Decouple lamp size for hemi/sun lamp and point/spot/area, the units for the former are wrong
- Show watts, watts/m^2 units in the UI
- Hide alpha component for node sockets in the UI
- Image cache for CPU (OpenImageIO)
- SIMD for BVH/triangle intersection
- Multiresolution shading cache
- Light portals
- Adaptive sampling
- Open Shading Language shaders are slower than SVM still.
- Lazy Loading / Cache
- Deformation Motion Blur
- BVH build and trace support
- Fluid simulation motion vectors
- Distributed network rendering
Video Editing and Compositing
- Compositing Improvements Improve a collection of nodes and tools that currently lack in quality like:
- Dilate/Erode node: Quickly turns smooth edges into blocky edges
- Vector Blur: See improvements proposed here http://www.sparkde.com/blog/?p=600 and here http://www.sparkde.com/blog/?p=660
- Workflow improvements: Use backdrop handles to move, rotate and scale (transform node). This could also be done with Input nodes (Render layer, movie, Image, texture).
- Additional nodes to apply instance effects, like interlacing effects.
- Node that outputs the relative screen coordinate.
- Scene relighting: composite lights like a GLSL shader does. For this we might also need a world position render pass and several nodes to do vector math like distance, dot, etc...
- Extend elbeem fluid sim with thin fluid features
See: http://www.youtube.com/watch?v=GyfB_vQHMAo and: http://www.youtube.com/watch?v=7Who8EpbvCY also see the papers by the author of Elbeem - note that this would likely require prior fluid dynamics experience to have a successful result. http://www.ntoken.com/pubs.html
- Compositing Nodes
- This requires compiling the compositing nodes down to a GLSL shader and running them through the BGE's 2D filter system. This would be similar to how material nodes are already done (compiled to GLSL code). It would be nice to also have the compositing nodes work in the viewport for better previews. Getting the BGE's 2D filter system working in the viewport would also be nice and would go hand-in-hand with this project. -Moguri
- Collection of smaller projects
- A couple of times in the past the BGE has had GSoC projects that would fix/implement a set of smaller features. These have been somewhat weak in the past since they usually have vague goals, but having the smaller projects well defined in advance would probably help. Some possible smaller projects include:
- Discrete Level of Detail
- While this has been worked on in the past, Blender trunk currently has no builtin level of detail (LoD) control. A discrete LoD system is one that has preset levels (with pre-made meshes) and swaps out the meshes at some specified level. Adding in mechanisms to smooth out popping issues would also be nice. -Moguri
- Procedural textures
- Getting Blender's procedural textures working in the BGE could be useful for getting some quick textures on objects. The main hiccup with this is the texture generation code is in the render code, but it could probably be moved to its own library (possibly bf_render_textures), which means the Blenderplayer could link against it. This would also fix bug #31965. This would probably be trivial to get working in the viewport once the textures work in the BGE, which would provide better viewport previews. -Moguri
- Group properties
- At the moment working with group instances can be rather bothersome if a user wants to have per instance properties. In other words, it would be nice to define a set of properties for a group object that each instance could change. At the moment, this type of behavior can be emulated with a Python script, but it gets rather clunky. Having a clean way to do this via the logic/property UI would be much nicer. -Moguri
- Better Profiling Tools
- Right now the only profiling tools we have is the "Framerate and Profile" option, which displays stats for a fixed number of categories. However, it would be nice if users could choose to not display some of these categories that have little to no impact on their game (Networking, Services, Outside, etc). Furthermore, it would be nice to get more detailed information such as which Python logic bricks are taking the most the time (so users can try to optimize Python scripts) and how much VRAM is being used. Both pieces of information can be found using other tools (cprofile and gDEBugger), but it would be nice to have some easier to use builtin tools, and leave the bigger tools for more detailed analysis. This project could potentially be expanded into a full GSoC project since there are a lot of little profiling features that could be worked on to fill up time. -Moguri
- Collision Python API
- The Python API is sorely missing access to collision information. At the moment, users are forced to use logic bricks to get collision information. Something like this proposal would be nice to have. -Moguri
- Cleanup Blenderplayer Command Line Argument Parsing
- The Blenderplayer's parsing of command line arguments is currently very picky and prone to breaking, and adding more command line options can be a bit painful. Instead, we should take advantage of a library such as one listed on this Stack Overflow page, or BLI_args, which is used by Blender. The BGE already has Boost as a dependency, so Boost.Program_options is an option. This project would also involve adding some more command line arguments for controlling audio options, anisotropic filtering, and possibly others. -Moguri
- Using blender as game engine/level editor
- The target of this project is to utilize blender as a game development tool for external engines. To get an idea what blender should be used for, have a look at other game engine tools like the UDK or CryEngine toolset. The outcome of this project should be either a usable editor for a specific engine or a very good document on how to use blender like this, focusing on the actual implementation and showing samples for some imaginary non-existent game engine. Examples of features and important things to think about: adding a RenderSettings.engine (next to Blender Internal, Cycles and Blender Game) to select the game engine and change the UI elements to what is used for the engine; level editing tools, for example setting entities and their properties; necessary exporters for levels, game engine models, etc; baking of light-/shadowmaps and similar for the asset pipeline of the game engine; and many more! -neXyon
- Alembic fileformat support. This goes beyond simple IO though, it needs design work on how to handle multiple animation systems or simulation caches together.
- Playback manager - A class/interface that can handle multiple sounds being played back with different categories assigned (eg. voice, music, background noise, notifications, etc.) where each category can be controlled. Useful for the game engine for example to easily pause/stop all sounds and adjust volume levels of different categories.
- Binaural audio: 3D audio with headphones, using HRTFs (head-related transfer functions)
- Environmental audio: different sound modifications (filters, reverb, etc.) which are spacially dependend on sound source and listener position. For example a gunshot in a tiled bathroom sounds different than in a room with sound absorbing walls.
- Dynamic music: a music playback interface which can change the music based on some user-defined flags. For example: a game has some random background music while the player runs around and then he starts fighting against a bunch of enemies and the music gets more exciting. This interface should then use predefined loopable music samples and transition nicely between them changing the mood of the background music according to the action that is currently going on.
- Random sounds: repeating sounds all over again sounds boring and is easily noticed by the player (for example footsteps) so this functionality should add a list of sounds to the sound actuator instead of a single one, with the ability to choose sounds randomly or sequential when it is triggered.
- Back- and front-ends (libogg, -vorbis, alsa, pulse, Windows and OSX backends)
- Plugins (including plugin architecture)
- Synthethic music: tools to create and edit music inside blender
- Lipsync: see the not-implemented project idea
- Speech recognition: can it be helpful to control blender, or used in the game engine?
Path handling and generic file access
- The path handling in blender is quite convoluted for historical reasons and could use a rewrite to also support things that can be expected:
- support UNC path on Windows
- support following shortcuts in file browser
- Additionally we might consider a generic way of accessing files from different places and implement the path as an URL:
- local files, network, svn/git, ftp,...
Google Summer of Code, application page
Blender project page
A guide for new developers
Google Summer of Code FAQ's
Previous summer of code projects
http://wiki.blender.org/index.php/BlenderDev/SummerOfCode2005 http://wiki.blender.org/index.php/BlenderDev/SummerOfCode2006 http://wiki.blender.org/index.php/BlenderDev/SummerOfCode2007 http://wiki.blender.org/index.php/BlenderDev/SummerOfCode2008 http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2009 http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2010/Proposals http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2011 http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2012