GSoC/Ideas Suggestions

Blender Summer of Code 2020 - Ideas

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

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 Ton Roosendaal: ton at blender.org.

General information for students and (potential) mentors

The list below provides ideas for projects that:

  • A student can complete in 12 weeks (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 free to submit their own proposals or modified versions of the ideas from this page.

Mentors

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

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
Students' Getting Started and Application Template

Inspiration

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

Ideas

Cycles Rendering

Many Light Sampling

  • Benefits: Optimized rendering for many lights.
  • Description: Make many light sampling project started last year production ready, making the existing implementing stable and supporting importance sampling of more features.
    • Test on production scenes and fix issues.
    • Complete GPU rendering support.
    • Better light importance estimation for textured lights
    • Investigate balancing importance with background and portal lights
    • Volume rendering support
  • Requirements: Some experience with rendering algorithms, math for computer graphics
  • Difficulty: high
  • Possible mentors: Brecht Van Lommel

Modeling

Collision-Aware Bevel

  • Benefits: The Bevel tool and modifier work with bevel amounts that cause overlaps or clamping currently.
  • Description: This is the biggest and most important outstanding project in task T48583.

Many users have asked for the Bevel tool and modifier to be smarter when the offset edges collide with each other. The current code either tries to clamp the bevel amount or let overlaps happen. Users would be very happy if the 'Clamp Overlap' option could just go away because the code would 'just work' when overlaps happen. Another benefit is that the current 'Bevel after Boolean' addon has to do a lot of hard work to try to deal with this case, and isn't always successful. It would be good to solve this once and for all inside Bevel itself. Two possible approaches to solving this problem that the current Bevel maintainer has thought of:

  1. Adapt the 'Straight Skeleton' approach to dealing with collisions between the advancing offset edges. This approach has been used in the 'Inset Straight Skeleton' addon and works well for insetting faces in a collision-aware manner. The challenge for this approach is adapting it to the 3d case and also dealing with 'eating away' new faces that are encountered by the advancing edges.
  2. Make 'pipes' of radius equal to the bevel amount around all of the beveled edges and intersect them, throw away the interior of the pipes, and reconstruct a bevel in the gaps created. This is like the approach taken by the 'Bevel after Boolean' addon.

This is quite a difficult project and will require a fair amount of up-front planning.

  • Requirements: Proficient in C programming, familiarity with 3d concepts and operations on vectors, some experience coding geometric algorithms.
  • Difficulty: high
  • Possible mentors: Howard Trickey

Shading

New Texture Nodes

  • Benefits: Use the same Cycles and EEVEE texture nodes everywhere in Blender.
  • Description: Cycles and EEVEE use their own shader and texture nodes, which are different than the old Blender Internal textures. The plan is to make all of Blender support these nodes so they can be used for modifiers, compositing, painting, particles, and more.
    • Add support for textures datablocks to contain a shading node tree, replacing the separate texture nodes system.
    • Refactor shading nodes system to support evaluation outside of rendering.
    • Implement a subset of Cycles and EEVEE shader nodes in C code.
      • Texture coordinates and attribute nodes (get data from a provided mesh).
      • Texture nodes (straight port of existing code).
      • Miscellaneous nodes.
      • Any nodes involving BSDFs, lighting, ray tracing would be left out.
    • Backwards compatibility with old Blender Internal textures and nodes.
  • Requirements: Proficient in C
  • Difficulty: medium
  • Possible mentors: Brecht Van Lommel

User Interface

Tool System for the Movie Clip Editor

  • Benefits: Users will have a consistent way to access tools.
  • Description: 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.
  • Requirements:
  • Difficulty: medium
  • Possible mentors: Campbell Barton, Sergey Sharybin, Julian Eisel


Menu Editor

  • Benefits: Users can edit their own custom menus which currently only have limited add/remove capabilities.
  • Description: Create a generic menu editor. See Menu Editor for Quick Favorites
    • Support adding removing items.
    • Re-ordering items.
    • Set/unset properties.
  • Requirements: Proficient in C
  • Difficulty: easy to medium
  • Possible mentors: Campbell Barton, Julian Eisel


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: Sergey Sharybin, Brecht Van Lommel, 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


Multi-Properties editing

  • Benefits: Easier ability to adjust properties across multiple objects at the same time
  • Description: Blender currently only allows you to easily affect the properties of the *active* object. Many users would like to make it easier to affect propertied across many selected elements (objects, keys, stripe, etc) without holding down hidden keyboard keys. (https://developer.blender.org/T54862)
    • Make Properties listen of the *selection* rather than *active* item
    • Only show properties that are common among the selected items
    • Add different display of properties when they differ
  • Requirements: Proficient in C/C++
  • Difficulty: medium
  • Possible mentors: William Reynish, Campbell Barton, Julian Eisel

Virtual Reality

VR Controller Input

  • Benefits: Big step towards milestone 2 (continuous immersive drawing) for bringing rich XR support to Blender. This is the basis of much further work on VR.
  • Description: During GSoC 2019 and the following months, the groundwork for OpenXR based XR support was implemented. This project was very focused on delivering stable basics and simple workflows. The next step would bring more advanced interactions to the table. Possible deliverables:
    • Minimum viable product: OpenXR action system support for controller input & haptics
    • Python queries for controller state and events
    • More advanced: Picking (finding what a controller points at when triggering actions, through either OpenGL selection or ray-casting)
    • Stretch goal: Allow 3D input for operators/tools (e.g. Grease Pencil painting with VR controllers)
  • Requirements: Proficient in C. An OpenXR compatible HMD would be useful, but one can be provided.
  • Difficulty: medium
  • Possible mentors: Julian Eisel, Dalai Felinto


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:
    • 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

Compositor

Improve Compositor Performance

  • Benefits: Faster and more memory efficient compositor.
  • Description: The compositor is not as fast as it could be. A number of incremental design and implementation changes could significantly improve CPU performance without a full rewrite. There are a number of know issues, and others would be identified through profiling and testing.
    • Create automated tests for compositor correctness and performance.
    • Refactor code so per-pixel virtual function calls are avoided, and pixels are processed in blocks.
    • Revise tile memory management.
    • Make node settings relative to image size, so users can easily work at lower resolution.
    • Profile, identify and fix bottlenecks.
  • Requirements: Proficient in C++
  • Difficulty: medium
  • Possible mentors: Jeroen Bakker

Interoperability

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 some parts of those into C modules could reduce the time to seconds. Doing some simple formats as a GSoC project could pave the way for future developers to tackle the more complex formats.
  • Description: Speed up import and export of the PLY and STL formats. Both of those are simple formats. Write C modules (that can load with Python inside Blender) to do the slow parts of importing and exporting (likely: file reading/writing and the parsing/formatting of raw text).
    See D2835 for how C modules can be incorporated into Blender.
    Note that PLY and STL we selected because they are relatively simple and good candidates for this project. Other formats may benefit from this too.
  • Requirements: Proficient in C and Python programming, 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: Quickly detect if fixes and new features break existing functionality.
  • 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, similar to the system Cycles uses. Some areas that would be good to test:
    • Mesh modifiers:
      • Write or improve scripts to compare mesh vertices, topology, data layers.
      • Create test infrastructure to save and compare meshes to a reference version.
      • Visualize failed tests on a HTML page (example)
      • Create tests for all modifiers with a script by applying them one by one to a test mesh in a .blend.
      • More extensively test different modifier settings.
    • Compositor
      • Make a good set of input test images, with different alpha, channels, HDR colors, etc.
      • Compare resulting images for all compositing nodes with various settings.
    • Object/Bone constraints:
      • Similar to meshes, could compare object/bone transforms or rendered images.
    • Operators (hard)
      • Record operators in Blender and then replay them in a test
      • This would work best for operators that have an easily testable input/output, comparison code from above areas could be reused.
      • Operators that need a UI would be challenging, but could be useful to test e.g. painting or sculpting.
    • Feel free to propose other areas.
  • Requirements: Proficient in Python programming.
  • Difficulty: easy/medium/hard (depends a lot on the areas tested)
  • Possible mentors: Campbell Barton, Bastien Montagne, Brecht Van Lommel

Audio

Sequencer Background Audio Rendering

  • Benefits: Better usability of various audio features within the video sequence editor (VSE).
  • Description: There are a few issues with how blender currently uses audio in the video sequence editor. These issues include the resolution used to render audio animation, animation of pitch values, exact editing of cuts for audio, playback of scenes inside other scenes and dynamic effects. All these issues (some more details here) can be addressed by rendering the scene audio into a buffer in a background thread.
    • Port rendering of the audio scene to Blender (currently done inside the audaspace library).
    • Run this rendering in a background thread to render into a memory buffer.
    • For longer scenes it should be possible to render into a cache file instead (wav or maybe flac) to preserve RAM.
    • Implement an algorithm to find out which parts of the buffer need to be rendered upon changes in Blender.
    • Optional: implement an audio meter for the VSE that takes advantage of having the rendered audio data in a buffer.
  • Requirements: Proficient in C++
  • Difficulty: medium
  • Possible mentors: Joerg Mueller

Physics

Fluid Display Options / Tools

  • Benefits: Better and more detailed view of underlying fluid simulation grids.
  • Description: There are currently only some options to visualize smoke simulation grids. The goal of this project is to add support for liquid simulations and to improve the existing visualization tools in general: Ultimately, the visualizer should be as detailed as the standalone Mantaflow GUI (Mantaflow is Blender's fluid simulation engine).
    • Explore the current state of Blender's fluid visualization tools and compare them with Mantaflow's GUI.
    • Must implement liquid grid visualization tools, especially the visualization of external forces and fluid velocity vectors.
    • Students can propose their own visualization options (the Mantaflow GUI can be used for inspiration).
    • Other nice-to-have options include:
      • Show strength of vectors through colored grid cells.
    • It should be possible to show only select grids and to step through the list of grids.
    • The visualizer should dynamically detect which grids are in use (i.e. and not just use a static list of grids).
    • Optional: Make it possible to visualize grids not only per frame but also in between frames (subframes).
  • Requirements: Proficient in C/C++, Python
  • Difficulty: medium
  • Possible mentors: Sebastián Barschkis


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


Retrieved from "https://wiki.blender.org/w/index.php?title=GSoC/Ideas_Suggestions&oldid=17454"