GSoC/Ideas Suggestions

Blender Summer of Code 2021 - Ideas

This page collects potential ideas and mentors for student projects in the summer of 2021.

Contacting us

You can contact us via our developers forum or bf-committers mailing list.
Also on

For matters you prefer to discuss in private, mail Ton Roosendaal: ton at

General information for students and (potential) mentors

The list below provides ideas for projects that:

  • A student can complete in 10 weeks half time (not too easy and not too hard);
  • Implements a feature that developers have agreed would be a great improvement for Blender.

Choosing an idea from this list is not mandatory. Students are encouraged to submit their own proposals or modified versions of the ideas from this page. Another source of inspiration can be the TODO and Design tasks listed in the Workboards of Blender modules.

See also


A mentor should be someone with Blender coding experience, who can guide a student during all stages of the work, from design to implementation.


Students who wish to apply should first carefully read the Getting Started page and check if all the conditions to participate are met.

If by some reason you can not participate or are not a student, your contribution outside of the program is still welcome! Feel free to develop an idea from the page as long as no student chose it.

We especially invite students to contribute based on their past experience and competencies, or based on their current research.

Nearly all project ideas will require a strong working knowledge of C and/or 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). An exception to this are projects where only Python is required.

Getting Started


To get an idea of what sort of project can be done for Blender and of the current development direction, see:


User Interface

The UI module decided to not explicitly promote GSoC ideas. A good proposal may still be accepted.


Knife Tool Improvements

  • Benefits: More versatility in uses of the Knife tool, and improved workflow.
  • Description: A number of users have suggested improvements to the Knife Tool. A selection of these that could be accomplished in the GSoC timeframe would make for a nicely thematic modeling project. Among the possible improvements:
  • Requirements: Proficient in C/C++
  • Difficulty: medium
  • Possible mentors: Howard Trickey, Campbell Barton

Curve Improvements

  • Benefits: Extra options and improved workflow dealing with Curves.
  • Description: The Curve object type probably needs overhauling, but some simpler user suggestions for improvements could be done in the GSoC timeframe. Some examples:
    • Adaptive Resolution in Curves. See here for details.
    • Curve length calculation and display option.
    • Option to do a vertex-bevel-like rounding of corners. See here.
    • General refactoring of the code to make it more understandable and more maintainable.
  • Requirements: Proficient in C/C++, good math abilities
  • Difficulty: medium-hard
  • Possible mentors: Howard Trickey, Campbell Barton

UV Editor Improvements

  • Benefits: More tools to improve editing of UVs.
  • Description: A selection of some of the smaller user requests for UV editing tools would help users make better UV maps more easily. Some example ideas:
    • A tool to straighten selected edges into a line. This request shows some examples.
    • Adapting some more Mesh Edit tools to the 2d UV editing case. For example, Vertex and Edge Slide.
    • A number of UV ideas in the Under Discussion section of this workboard.
  • Requirements: Proficient in C/C++, familiarity with vector math
  • Difficulty: medium
  • Possible mentors: Howard Trickey, Campbell Barton

Virtual Reality

VR Drawing Optimizations

  • Benefits: Improved performance and interactivity of VR views.
  • Description: During GSoC 2019 and the following months, the groundwork for OpenXR based XR support was implemented. Performance-wise the efforts were focused on minimizing VR specific overhead, improvements to the viewport drawing itself were not done. There are still many optimizations to be done there. Primary ideas (picking one for the project is totally enough):
    • Single pass (multiple draw-calls) drawing: Using the DRWView abstraction, we can draw multiple eyes in one render-loop iteration (as opposed to one iteration for each eye). This will still trigger multiple OpenGL draw calls but much of the surrounding logic will only be executed once.
    • Parallel execution of the VR session drawing: The entire VR session drawing could happen on a separate thread, even if the viewport drawing itself remains mutex'ed. While there's no big performance boost to be expected from this, we can avoid the overhead of Blender's main loop that way. There are also blocking OpenXR calls that should not lock the main thread.
    • Identify and eliminate further avoidable bottlenecks, especially with Eevee.
  • Requirements: Proficient in C and graphics programming (ideally OpenGL). An OpenXR compatible HMD would be useful, but one can be provided.
  • Difficulty: hard
  • Possible mentors: Julian Eisel, Dalai Felinto


Fast Import / Export for selected formats

  • Benefits: For very large models (millions of vertices), the Python importers and exporters in Blender can take a long time (minutes). Moving them into C/C++ modules could reduce the time to seconds.
  • Description: Speed up import and export of the PLY and STL formats by moving them from Python to C++. Both of those are simple formats, though they have both ASCII and binary forms. There was a GSoC 2020 project (soc-2020-io-performance branch) that did this for OBJ, and the new importers and exporters should build on that work, following the same pattern and reusing code where possible.
  • Requirements: Proficient in C++, familiarity with 3d concepts
  • Difficulty: medium
  • Possible mentors: Howard Trickey, Campbell Barton, Jacques Lucke

Automated Testing

Core Library Tests

  • Benefits: Improve development process so changes to Blender's core libraries so further development can be validated.
  • Description: There are multiple libraries in Blender which could have improved test automation. These include:
    • BlenLib (BLI) low level libraries for data structures, math and filepath handling (some areas are already well tested).
    • BMesh: Mesh editing operations (subdivide, split edges, recalculate normals.. etc).
    • ImBuf: 2D image library (scaling, rotation, color operations).
    • Developers note, feel free to other areas.
  • Requirements: Proficient in C programming.
  • Difficulty: easy/medium/hard (depends a lot on the areas tested)
  • Possible mentors: Campbell Barton, Bastien Montagne, Howard Trickey

Regression Tests

  • Benefits: Automated regression testing improves quality of Blender by quickly detecting if new features break existing ones, and therefore catch bugs way before users do.
  • Description: This would involve using Python to automate detecting changes to Blenders behavior, by comparing the result from operations in new Blender versions and a reference version. Some areas that would be good to test:
    • Object Bone/Constraint:
      • A similar framework to MeshTest can be written to automate constrains for different types of objects.
    • Shape keys: Extend existing frameworks to support Shape Keys
    • Compositor:
      • Extend current framework to support video/animation nodes
      • Node correctness testing, (e.g. blur node makes image less sharp, bright/contrast node makes image brighter regardless of exact absolute values etc…)
    • Operators: Simulate user input in unit tests to cover much more operators than currently possible.
    • Modifiers: Extend existing framework to support Volume and Grease Pencil objects
    • General Mesh: add test cases using existing frameworks to improve test coverage, e.g more extensively test different modifiers/operators or a combination of both (see T84999).

Any suggestion for other areas is welcome, especially new parts of Blender or where changes are planned soon.

  • Requirements: Proficient in Python programming.
  • Difficulty: easy/medium(depends a lot on the areas tested)
  • Possible mentors: Campbell Barton, Bastien Montagne, Habib Gahbiche.


2D Fluid Simulations

  • Benefits: Simulating fluids in two dimensions saves computation time (compared to 3D) and is sufficient when working on 2D projects.
  • Description: Blender's integrated fluid simulator Mantaflow natively supports 2D fluid simulations. So far though, Blender only sets up simulations in 3D. The goal of this project is to extend the existing fluid simulation system in Blender so that it can simulate in 2D too.
    • Make the existing Blender-Mantaflow API 2D compatible (e.g. adapt grid initialization)
    • Implement a system to set up 2D simulations: The domain should be a 2D object (e.g. a plane, side of an object) instead of a 3D object, flow and obstacle regions could be described with objects (2D or 3D) intersecting with the domain plane.
    • For smoke simulations: A way to render smoke volumes on planes needs to be implemented.
    • For liquid simulations: Instead of a 3D mesh, the output of a liquid simulation could be just a curve.
  • Requirements: Proficient in C/C++, Python, Mantaflow (optional)
  • Difficulty: medium/hard
  • Possible mentors: Sebastián Barschkis

Display Simulation Data for Cloth/Rigid Body Simulation Systems

  • Benefits: Would make it easier for both developers and artists to analyze what is happening in our simulations and tweak parameters and/or fix issues. We will also have more feature parity among our simulation workflows.
  • Description: Currently only the Mantaflow (Fluid/Smoke) simulation system has good viewport display options for simulation data. If we could have the same functionality for the rest of the blender physics systems, that would make it easier to see what is happening within our simulations. This system should (but is not limited to):
    • Visualize and display vertex simulation velocity, acceleration, and individual forces from force fields etc.
    • Show useful information about individual cloth springs (is it extended or compressed, how much force it is exerting, is it disabled, etc).
    • Display if a vertex or rigid body object is colliding or not.
    • Show dynamic rigid body states in the viewport (disabled, sleeping, or active)
    • Display compound and mesh collision meshes for rigid body objects (only built in primitives are displayed currently). Bullet has built-in methods for getting this data.
    • Visualize rigid body constraints in the viewport.
  • Requirements: Proficient in C/C++, Python, Bullet (optional)
  • Difficulty: medium/hard
  • Possible mentors: Sebastian Parborg

Machine Learning for Fluid Simulations

Note: This is an exploratory project. It is not planned to be merged into master directly at the end of GSoC.

  • Benefits:
    • Fluid simulations in Blender rely on precomputed caches. Especially at high resolutions and with varying scene geometry (e.g. positioning of collision objects, strength of flow objects), figuring out the final simulation setup can be a very time-consuming task.
    • Current research on machine learning for fluids shows promising results (e.g. Thuerey et al.) that closely recreates the behavior of traditional fluid simulations. Embedding a machine-learning based fluid simulator in Blender could make room for workflows that are faster and more flexible than current brute-force simulations.
  • Description:
    • Design and build a system around the existing fluid modifier in Blender that leverages a machine learning framework to generate fluid flows.
    • The machine-learning framework can be chosen freely. However, the choice should take into consideration existing work in this area and your own experience with that framework.
    • Explore different approaches and come up with a design for a machine learning based fluid workflow in Blender.
    • Implement the most promising design and get user feedback for the prototype.
    • Document challenges along the way and give an outlook for future work (e.g. evaluate pro's / con's of implementation, suggest improvements or potentially other designs).
    • Overall, the scope of 'machine learning & fluids' is bigger than a GSoC project. The idea for GSoC is therefore to focus on building a proof of concept.
    • It is recommended to discuss the proposal / your project approach with the mentor before submitting it.
  • Requirements:
    • Proficient in C/C++ and Python.
    • Practical experience with at least one machine learning framework.
  • Desirable:
    • Knowledgeable about theory of fluid simulations (e.g. experience with physics-based computer graphics, CFD, other 3D software packages, or related).
    • Motivation to explore the topic and the Blender code beyond GSoC.
  • Difficulty: medium/hard
  • Possible mentors: Sebastián Barschkis

Geometry Nodes

Modifiers as Nodes

  • Benefits: Improve geometry nodes workflow by not forcing the user to leave the node group for some common operations that are only available as modifiers currently.
  • Description: Many nodes cannot (and should not) be mapped 1 to 1 to geometry nodes. Good nodes corresponding to existing modifiers have to be designed to make them work well in a node based workflow. The new nodes should integrate well with the new attribute system. Good candidates for modifiers that can be converted are: Remesh, Mirror, Weld, Decimate, Solidify, Wireframe and Smooth (among some others).
  • Requirements: Proficient in C/C++
  • Difficulty: medium
  • Possible Mentors: Jacques Lucke, Hans Goudey

Video Sequence Editor

Strip Previews

  • Benefits: Ability to see content preview of strips helps with orientation in timeline.
  • Description: Strips are currently drawn with simple geometric shapes and solid colors. Strip previews can use existing job and cache design directly or with some modifications. Images can be read from cache and drawn in UI.
  • Requirements: Proficient in C/C++
  • Difficulty: medium
  • Possible Mentors: Richard Antalík

Performance Improvements

  • Benefits: Updating preview quickly is important for video editing experience
  • Description: There are areas, that arent performing as well as they could. Examples are seeking in video files, disk cache IO / compression speed and single threaded image processing.
  • Requirements: Proficient in C, FFmpeg knowledge welcome
  • Difficulty: medium
  • Possible Mentors: Richard Antalík

Editing Tools

  • Benefits: More interactive tools that fits tool system make it easy to discover functionality
  • Description: Currently editing tools are designed to be fast, but if you are not familiar with what they do, it is hard to memorize them. functionality can be improved with drawing gizmos on top of strips that are edited, drawing previews of frames when these are useful for operation. Some editing tools use playhead as editing cursor, which sometimes is useful but it can be counter productive and more interactive approach can be used.
  • Requirements: Proficient in C
  • Difficulty: medium
  • Possible Mentors: Richard Antalík