GSoC/Ideas Suggestions

= Blender Summer of Code 2023 - Ideas =

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

For matters you prefer to discuss in private, mail Thomas Dinges: thomas at blender.org.

General information for contributors and (potential) mentors
The list below provides ideas for projects that:


 * Have a expected project size of ~ 175 working hours or ~350 working hours.
 * Implements a feature that developers have agreed would be a great improvement for Blender.

Choosing an idea from this list is not mandatory. Contributors 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 https://summerofcode.withgoogle.com/how-it-works/

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

Contributors
Contributors 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, your contribution outside of the program is still welcome! Feel free to develop an idea from the page as long as no contributor chose it.

We especially invite contributors 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.

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


 * Release logs
 * Code Blog
 * GSoC projects for 2022
 * GSoC projects for 2021
 * GSoC projects for 2020
 * GSoC projects for 2019

= Ideas =

Files as Assets

 * Description:
 * Support XMP sidecar files for storing asset metadata for files.
 * "Import Files" operator to select files from the file browser to display in (and possibly copy to) the asset library. Queries which file types are supported (e.g. through add-ons).
 * Basic usages, e.g. drag 'n drop for image files into the 3D view behaving just like drag & drop of Blender image data-blocks.
 * Expected outcomes: Enable core code and/or scripts to display any file type in the asset browser. Simplify asset management of non-Blender data within Blender.
 * Skills required: Proficient in C/C++, basic Python
 * Possible mentors: Julian Eisel, Sybren Stüvel
 * Expected project size: 350 hours
 * Difficulty: medium

Asset Catalog Selector for Asset View Templates

 * Description: Add a selector to asset view templates that spawns a search menu to select catalogs (with a simple visualization of the catalog tree). These templates are a mini version of the asset browser to display assets anywhere in the UI, currently used in the sidebar for pose libraries. Asset catalogs are the main way to organize assets in an asset library for browsing in Blender. Without a selector for them in asset view templates, both the templates and the catalogs become less useful.
 * Expected outcomes: Allow users to browser & select catalogs outside of the asset browser in asset view templates (e.g. pose library sidebar)
 * Skills required: Proficient in C/C++
 * Possible mentors: Julian Eisel, Hans Goudey
 * Expected project size: 175 hours
 * Difficulty: easy/medium

Core Library Tests

 * 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.
 * Expected outcomes: Improve development process so changes to Blender's core libraries so further development can be validated.
 * Skills required: Proficient in C programming.
 * Possible mentors: Campbell Barton, Bastien Montagne, Howard Trickey
 * Expected project size: 350 hours
 * Difficulty: easy/medium/hard (depends a lot on the areas tested)

Regression Tests

 * 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:
 * 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.
 * Expected outcomes: Automated regression testing improves quality of Blender by quickly detecting if new features break existing ones, and therefore catch bugs way before users do.
 * Skills required: Proficient in Python programming.
 * Possible mentors: Campbell Barton, Bastien Montagne, Habib Gahbiche
 * Expected project size: 175 hours
 * Difficulty: easy/medium (depends a lot on the areas tested)

Shader AOVs

 * Description: Shader AOVs for writing custom render passes are supported in Cycles, but have a number of limitations that make them not as useful as they should be. Missing features include vector AOV output, Open Shading Language support, viewport display of AOVs, a shader node group to write the same AOVs on all objects in a scene, and alpha transparency. This project would implement a subset or all of these features.
 * Expected outcomes: More powerful shader AOVs.
 * Possible mentors: Brecht Van Lommel
 * Expected project size: 175 hours
 * Difficulty: medium
 * Related Task: T73266

Volume BVH

 * Description: Rendering of OpenVDB volumes currently uses bounding meshes and a volume stack to keep track of which volumes a ray overlaps. This is inefficient with many volumes in a scene, and is a source of precision problems and artifacts. In this project, instead a dedicated bounding volume hierarchy over all OpenVDB volumes in the scene would be built. For volume shading and shadows, there would be a quick function to traverse OpenVDB tree nodes along a ray.
 * Expected outcomes: More efficient volume rendering.
 * Possible mentors: Brecht Van Lommel
 * Expected project size: 350 hours
 * Difficulty: hard

Volume Nodes

 * Description: OpenVDB comes with many tools for volumes and signed distance fields (level sets). Exposing these to geometry nodes in a consistent way would be a useful change. The way volume grids correspond to fields means that implementing this fully would involve supporting existing field operations on voxel values. However, a smaller version of the project would involve accessing "built-in" grids on volume objects without implementing fields.
 * Expected outcomes: Provide access to powerful existing volumes tools, iterate on how to best map them to geometry nodes and other Blender concepts.
 * Skills required: Proficient in C/C++
 * Possible mentors: Jacques Lucke, Hans Goudey
 * Expected project size: 350 hours
 * Difficulty: medium

Fast Import / Export for selected formats

 * 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.
 * Expected outcomes: 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.
 * Skills required: Proficient in C++, familiarity with 3d concepts
 * Possible mentors: Howard Trickey, Campbell Barton, Jacques Lucke
 * Expected project size: 175 hours
 * Difficulty: easy/medium

UV Editor Improvements

 * 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.
 * Expected outcomes: More tools to improve editing of UVs.
 * Skills required: Proficient in C/C++, familiarity with vector math
 * Possible mentors: Howard Trickey, Campbell Barton
 * Expected project size: 350 hours
 * Difficulty: medium

User Interface
The UI module only suggests refactoring projects here (without user visible changes) due to limited resources on design topics.

Continue Outliner Code Refactor

 * Description: As part of ongoing efforts to improve code quality in the UI code, a rewrite of the Outliner code was started, using C++ and basic object-oriented programming. Main architectural changes are done, but plenty of work is left to port all code to it. Part of the deliverables would be some basic technical documentation.
 * Task:
 * Expected outcomes: More maintainable, testable and scalable code for the Outliner. Improved documentation.
 * Skills required: Proficient in C/C++ and object oriented programming.
 * Possible mentors: Julian Eisel
 * Expected project size: 175 hours
 * Difficulty: easy/medium

Performance Improvements

 * 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.
 * Expected outcomes: Updating preview quickly is important for video editing experience
 * Skills required: Proficient in C, FFmpeg knowledge welcome
 * Possible mentors: Richard Antalík
 * Expected project size: 350 hours
 * Difficulty: medium

Waveform Drawing Improvements

 * Description: Waveforms are processed by single thread and progress bar is used to indicate this process is running. This task can be parallelized to read waveforms faster. Instead of a progress bar, the available portion of the waveform can be drawn as it loads. Making the waveforms visible on strips allows to work with immediately available data.
 * Expected outcomes: Reduce time to draw wavevorms.
 * Skills required: Proficient in C
 * Possible mentors: Richard Antalík
 * Expected project size: 175 hours
 * Difficulty: medium

Editing Tools

 * 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.
 * Expected outcomes: More interactive tools that fits tool system make it easy to discover functionality
 * Skills required: Proficient in C
 * Possible mentors: Richard Antalík
 * Expected project size: 175 hours
 * Difficulty: medium

Preview Tool Improvements

 * Description: Current interactive tools in preview require selection. Non-interactive tools can use selection in preview to perform operations that were originally intended to be accessible only from timeline. This usually requires simple changes to switch context of tool, but in other cases principle of operation may have to be adjusted to make this possible.
 * Expected outcomes: Non-interactive tools can now be used in preview context further optimizing workflows.
 * Skills required: Proficient in C
 * Possible mentors: Richard Antalík
 * Expected project size: 175 hours
 * Difficulty: easy/medium

VR Windows

 * Description: Some users have expressed interest in accessing Blender's traditional 2D interface during a VR session for adjusting scene shading/lighting, positioning objects, and even modeling in VR using a mouse and keyboard - all without having to remove one's headset. While there are various external solutions (desktop mirroring, passthrough), it would be nice to have this functionality included in Blender natively to provide a standard, maintainable experience for users. In addition to viewing windows in VR and interacting via mouse and keyboard, interacting with windows using VR controllers would be useful.
 * Expected outcomes: Access to Blender's 2D interface from within VR without relying on external solutions such as desktop mirroring.
 * Skills required: Proficient in C/C++. Must have an OpenXR compatible headset and system setup/OS.
 * Possible mentors: Peter Kim, Julian Eisel
 * Expected project size: 350 hours
 * Difficulty: medium

<!--

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

Tool System for the Movie Clip Editor

 * Description: (more detailed, 2-5+ sentences) Implement Blender's dominant tool-system in the movie-clip editor for motion tracking and editing 2D masks. See Update Clip Editor for 2.80 Toolsystem
 * Expose tools for selection, editing and transforming as tools.
 * Expose a user interface for accessing tool properties.
 * Make necessary modifications to the tools so they can be usefully activated and controlled.
 * Expected outcomes: Users will have a consistent way to access tools.
 * Skills required:
 * Possible mentors: Campbell Barton, Julian Eisel
 * Expected project size: 350 hours
 * Difficulty: medium

Info Editor

 * Benefits: give users access to information and statistics about rendering, dependency graph, viewport, tracking, etc.
 * Description: The info editor only shows operator and property Python commands currently, but can become much more useful. It should show logs from renders to debug performance issues, dependency graph logs to analyze performance and dependency cycles, or viewport information to analyze performance and debug graphics issues.
 * Store render logs along with render result and display them in the info editor.
 * Modify dependency graph logging to make it easier to understand for users, store the logs, and display in the info editor.
 * Make viewport performance information available in the info editor. Add logging of viewport data useful for debugging of graphics issues.
 * User interface improvements: better selection, export of logs, search.
 * Requirements: Proficient in C
 * Difficulty: medium
 * Possible mentors: Julian Eisel

Dynamic Brush Previews
-->
 * Benefits: Better, automatic brush previews for sculpting, painting and grease pencil.
 * Description: Blender's brush system currently has static icons, which do not reflect the brush settings and need to be manually created. Instead we want to dynamically generate them based on brush setting such as spacing and textures. (mockups and description).
 * Add brush preview storage, and user interface to display them for sculpting and painting.
 * Implement brush preview rendering for the various brush settings and modes.
 * Improve user interface, experiment with ideas in the mockups.
 * Requirements: Proficient in C/C++
 * Difficulty: hard
 * Possible mentors: William Reynish, Campbell Barton, Julian Eisel