GSoC/Ideas Suggestions

Blender Summer of Code 2019 - Ideas

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


Student applications are closed! The results will be announced on 6 May.


Contacting us

You can contact us via our developers forum or bf-committers mailing list.
Also on IRC: irc.freenode.net #blendercoders

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.

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


Embree BVH for GPU

  • Benefits: Faster motion blur and GPU rendering, simpler code.
  • Description: We want to replace our own BVH builder with the one from Embree, and use it for both CPU and GPU. Embree already has CPU BVH traversal, but for GPU we need to copy the BVH to our own data structures. For faster motion blur the Cycles kernel also needs modified BVH traversal.
    • Implement converter from Embree BVH to Cycles BVH data structures.
    • Verify if Embree can export oriented bounding boxes and motion steps, and if needed improve Embree API.
    • Adjust Cycles kernel BVH traversal for faster motion blur.
    • Test performance and memory usage to compare to existing BVH, and fix any issues if needed.
  • Difficulty: medium
  • Possible mentors: Sergey Sharybin, Brecht Van Lommel

Modeling

Bevel Improvements

  • Benefits: Add some user-requested enhancements to modeling with Bevel tool and modifier
  • Description: There are a number of possible enhancements, improvements, and bug fixes for Bevel described in task T48583. A good project would be to select some of these that could be done in the GSoC timeframe. One possible set:
    • User-drawn profiles. There would be some UI work to get a widget for capturing the profile, or perhaps a separate object could be used (clunkier). And then work on how to do the edges with that profile (fairly easy), and how to do the corners with that profile (fairly hard). If the profiles aren't symmetric, then a solution for figuring out the orientation of the profile on each edge needs to be found.
    • Remove the need for clamping by properly dealing with the cases where the bevel geometry collides with / intersects other geometry. This is quite a hard project and could probably be enough work for an entire GSoC project.
  • Requirements: Proficient in C programming, familiarity with 3d concepts and operations on vectors
  • Difficulty: medium to high
  • Possible mentors: Howard Trickey


Boolean modifier improvements

  • Benefits: Boolean modifier which just works!
  • Description: The new BMesh based booleans in Blender should become more robust to handle real-world cases, particularly in the presence of non-manifold or degenerate geometry. A list of issues is here. Some examples:
    • Support for self-intersecting shapes.
    • Handle exactly overlapping geometry and zero (or near zero) length edges in faces.
    • More robust handling of open meshes with ill-defined interior.
  • Requirements: Proficient in C, 3d-math
  • Difficulty: high
  • Possible mentors: Howard Trickey, Bastien Montagne, Sergey Sharybin

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

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


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: medium
  • Possible mentors: William Reynish, Campbell Barton


Outliner Improvements

  • Benefits: More user-friendly and powerful outliner.
  • Description: The outliner has a number of usability issues, lacking standard interactions and tools that would make it easier to work with and more powerful. A few examples of improvements are listed below. The developers would work with users to find the most important usability issues and fix them. (detailed information)
    • Shift-select to select a range of items.
    • Box selection by simple click and drag.
    • Shortcut keys for operations like delete, duplicate.
    • Arrow key navigation.
    • More consistent and powerful right-click menus.
    • Sync selection between 3D viewport and outliner.
  • Requirements: Proficient in C
  • Difficulty: medium
  • Possible mentors: William Reynish, Brecht Van Lommel

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

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


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