[TRACKER] Google Summer of Code 2022 ideas list (GSoC 2022)

[akien-mga]

Last updated: 2022-04-07

Note: We've updated this list after discussion with potential GSoC mentors to better estimate whether the listed ideas are indeed good projects for GSoC. Some of the initially listed ideas were features with a too limited scope which couldn't last for a 175 h or 350 h GSoC project. We moved them at the end of the list under an "Archive" section, you can still consult them but be aware that they likely need to be expanded / paired with other related features to make a full GSoC project.
We're also adding some new "validated" ideas to the list.

[ Guidelines for mentors to complete this list: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list ]

---

This is a list of project ideas for contributors applying to the Google Summer of Code program in 2022 (GSoC 2022).

It's only an indicative list, and is subject to change as Godot is very actively developed by hundreds of contributors. Use this list as an inspiration source, but feel free to come with your own ideas on what you would like to work on in Godot.

As a complement, you can check out the community proposals repository and fish out some good ideas for projects. You can also engage the discussions over there.

Make sure to discuss your ideas with Godot developers on the Godot Contributors chat platform, so that we can help you refine them and ensure that they fit in the Godot roadmap and architecture.

Add a built-in video + audio recording tool for creating game trailers and troubleshooting

Possible mentors: reduz? Calinou? (help from lawnjelly on frame timing?)

If you've ever watched indie game trailers, you've probably noticed at some point that stuttering and dropped frames are quite common, especially in lower-budget productions.
Also, when troubleshooting specific issues such as physics, audio or rendering bugs, having pixel-perfect video and audio recording can be valuable.

There are several ways to record this kind of video using external tools, but none are as reliable and easy to set up as a built-in video/audio recorder.

See this feature proposal for further details: #3083

Skills required/preferred: C++ programming, dealing with audio/video file formats
Size of project: 350 hours (full-time)
Difficulty rating: Medium

Add support for multiple displays/screens/monitors in editor

Possible mentors: reduz, groud, KoBeWi?

Being able to detach script editor and edit scene and script on 2 separate screens is one of the most often requested features for Godot. In Godot 4.0, it is already possible to detach some docks to separate windows.
However, separating docks to windows is generally not very useful on its own. To make this ability more useful, a similar feature should be implemented for main screen editors, i.e. 2D, 3D and script editor.

Edit: We suggest focusing on the script editor first and foremost, as the actual use case for detaching the 2D and 3D viewports are not well defined yet. Review discussions and linked proposals in #28 to see what community users have in mind feature wise.

See this feature proposal for further details: #28

Skills required/preferred: C++ programming, Godot GUI and editor
Size of project: 175 hours (part-time)
Difficulty rating: Hard

Add subgraphing in VisualScript to create modular nodes

Possible mentors: theoway, fire?

VisualScript is a powerful scripting tool in Godot, however, it lacks the feature of grouping VisualScript nodes into reusable modules. The user should be able to collapse a selection of nodes into a new function node, expand it to see the original structure and save it as a resource to be shared across projects.

See these feature proposals for further details: #3943, #596

Refer this pull request for designing & developing the code: godotengine/godot#45294

Edit: This proposal is confirmed to be wanted, but it might need to be fleshed out to extend beyond simply updating the above PR. Get in touch with theoway and fire on the Godot chat to discuss more in details.

Skills required/preferred: C++ programming, working with VisualScript
Size of project: 350 hours (full-time)
Difficulty rating: Medium

Command line debugger refactor + debugger expression evaluator

Possible mentors: fales, Calinou

Godot includes a local stdout debugger with the -d / --debug option, which can expose some debugging functionality for use from the command line. It's not much documented and a bit cryptic to use, so this idea would be to rethink how we want to do command line debugging and expose a more friendly (and documented) command line interface for this. It could e.g. be exposing an interface similar to gdb to be able to set breakpoints, print backtraces, print variables, etc.

Additionally, a contributor did good work on adding support for an Expression evaluator and variable watches to the (in-editor graphical) debugger. Another idea, which could be done together with the above, is to rework this PR to get it merged in the engine and also exposed via the command line debugger. PR: godotengine/godot#26219

Skills required/preferred: C++ programming, familiarity with debuggers and client/server interfaces
Size of project: 175 hours (part-time). Possibly full-time if grouped together with the next idea (frame-by-frame stepping) or other debugger-related ideas.
Difficulty rating: Medium

Add a keyboard shortcut to perform frame-by-frame stepping when running a project from the editor

Possible mentors: fales, Calinou

Godot currently offers many debugging tools to find and resolve issues within a project. However, troubleshooting bugs in your character/AI controller scripts or physics bugs can be difficult due to the real-time nature of the simulation.
When a hitch is only visible for 1/60th of a second or sometimes even less, it's hard to see what can go wrong in real-time.

Frame-by-frame stepping can be used to see this kind of one-frame issues more easily, without having to use a video recording tool (which may drop frames and be inaccurate).

See this feature proposal for further details: #3105

Skills required/preferred: C++ programming, working with a debugger client/server (which is what Godot uses for editor-project communication)
Size of project: 175 hours (part-time)
Difficulty rating: Medium

Replace Godot's CSG implementation with a better designed library

Possible mentors: reduz, fire?, BastiaanOlij?

Godot has its own CSG implementation in modules/csg/ which was written by reduz, but has some limitations (TODO for GSoC contributors: talk about it with reduz to understand what the problems are, and what he has in mind to solve them). We've been discussing investigating the use of better designed thirdparty library to replace parts of the CSG implementation.

One such library which was mentioned in https://github.com/elalish/manifold

This is a rough idea and still needs fleshing out and a proper feature proposal for further discussion.

Skills required/preferred: C++ programming, 3D meshes experience, understanding of the main concepts of CSG as a prototyping or level editing tool
Size of project: 350 hours (full-time)
Difficulty rating: Hard (to be confirmed)

Improvements to the GPU lightmapper

Possible mentors: JFonS, Calinou?, lawnjelly?

Godot 4.0 comes with a GPU lightmapper, and there's significant room for improvements in its current features.

• Soft shadows
  Difficulty: Low – Usefulness: Very High
  Add support for soft shadows so the "size" property in Light3D can be used to blur out the hard edges of direct light shadows. This is already supported in the 3.x CPU lightmapper with this PR, but it needs to be reimplemented to run on the GPU.

• Debug draw modes for texel density
  Difficulty: Medium – Usefulness: High
  Add a debug draw mode that easily displays the texel density of lightmaps. Related proposal.
  This would require figuring out a way to display a checkerboard pattern on all surfaces based on their UV2 coordinates. Probably similar to the overdraw debug mode, it can be a good exercise to search for DEBUG_DRAW_OVERDRAW in the code-base and see what is going on.

• Multi-image atlases
  Difficulty: Very low – Usefulness: Low
  Right now every LightmapGI node stores its atlas in a single large image. This means that larger scenes may refuse to bake because they don't fit within the size limits of an image. This was already done in the 3.x CPU Lightmapper with this PR, so it should be a mostly straight-forward port to master.

• Adaptive sampling
  Difficulty: Medium – Usefulness: Medium
  Implement an adaptive sampling strategy in order to reduce bake times. There are plenty of academic papers on the topic, but here is a shorter blog-post that explains the problem and a possible solution: https://blog.yiningkarlli.com/2015/03/adaptive-sampling.html

• Testing and fixing directional lightmaps
  Difficulty: Very High – Usefulness: Very High
  LightmapGI in 4.0 supports directional lightmaps by using Spherical-Harmonics. We've had some reports that it's not behaving well in some cases so investigation and fixing those issues could be part of your GSoC work. I strongly recommend testing the issue and making sure the bugs are still there before picking this task for your final proposal.

Skills required/preferred: C++ and GLSL programming, familiarity with lightmapper and willingness to read rendering papers
Size of project: 350 hours (full-time)
Difficulty rating: Medium

---

Archived ideas

Those ideas were listed originally but were later found not to be good fits for GSoC 2022, either due to being too easy/fast to implement (not amounting to the expected 175 hours or 350 hours for GSoC projects), or badly timed due to the current stage of development we are in (rendering features specifically are tricky in general, and even trickier this year as the rendering backend are in flux and constantly updated and refactored by our rendering contributors).

Add ability to mask view layers in the 2D and 3D editor viewports

Edit: After discussion, we think this can be done much faster than in 175 hours, and is therefore no longer suitable standalone for a GSoC project. It could be grouped together with other related enhancements into a bigger proposal for 2D and/or 3D editor usability improvements.

Possible mentors: Calinou, YeldhamDev?, KoBeWi?

When working with secondary viewports in 2D or 3D projects, objects located in those secondary layers can get in the way.
To improve editor usability, there should be a way to filter layers in the 2D or 3D editor view, so you can focus only on what you actually need to see.

See this feature proposal for further details and a suggested UI mockup: #3218

Skills required/preferred: C++ programming, designing user interfaces (editor dialogs)
Size of project: 175 hours (part-time)
Difficulty rating: Easy

Add a mesh simplification option for TriMesh collision shape generation in the advanced import settings

Edit: After discussion, we think this can be done much faster than in 175 hours, and is therefore no longer suitable standalone for a GSoC project. It could be grouped together with other related enhancements into a bigger proposal for physics improvements.

Possible mentors: JFonS

3D levels with complex geometry will have complex triangle meshes generated by default, which lowers physics simulation performance and reliability. Maximizing physics server performance is important for games where CPU cycles come at a premium (mobile/web platforms) and for game servers that use server-side physics.
Using a separate hand-authored collision mesh with less details will result in faster and more reliable collisions. However, while iterating on the level geometry, having to maintain this mesh separately can take a lot of time.

The proposed solution is to add an option to simplify the generated trimesh collision shape using the built-in decimation algorithm (meshoptimizer).
This library is already integrated within the engine and is used for automatic LOD mesh generation. The goal here is to integrate it with the triangle mesh collision generation system.

See this feature proposal for further details: #3603

Skills required/preferred: C++ programming (no physics programming knowledge required)
Size of project: 175 hours (part-time)
Difficulty rating: Medium

Use bounding box/sphere-based directional shadow splits instead of view depth

Edit: The rendering backends for Godot 4.0 are still too much in flux at this time, so we prefer to avoid GSoC projects that touch rendering features directly. This one requires a significant amount of time from both GSoC contributor and mentors to get up to speed on rendering techniques, and then the implementation part would likely be too fast for a 175 hours GSoC project.

Note: Idea needs approval from reduz first.
Possible mentors: JFonS, clayjohn?

In 3D, Godot uses stabilized directional shadow rendering, but the effective shadowmap resolution isn't optimal. There is a lot of wasted space, leading to shadows that are rendered but never displayed.
The reason why this happens is that shadowmap textures are aligned to the directional light's frustum, but the camera's view frustum does not match this.
Therefore, shadow splits will not display the entirety of the shadowmap texture, and will display lower-resolution splits where higher-resolution splits could be displayed instead.

The proposed solution is to use a bounding box or bounding sphere approach to displaying directional shadow splits, as demonstrated in DICE's GDC09 presentation.

See this feature proposal for further details: #3908

Skills required/preferred: C++ programming, graphics programming (prior Vulkan or OpenGL knowledge required)
Size of project: 175 hours (part-time)
Difficulty rating: Medium

Implement overscan in the Vulkan renderer to improve screen-space effect stability in motion

Edit: The rendering backends for Godot 4.0 are still too much in flux at this time, so we prefer to avoid GSoC projects that touch rendering features directly. In particular, Godot is due to get a Deferred renderer, where this feature would make more sense. It also seems fairly complicated for a GSoC project in first approximation.

Note: Idea needs approval from reduz first.
Possible mentors: Calinou, clayjohn?

In 3D rendering, screen-space effects like SSAO, SSR, SSIL and glow suffer from artifacts that are mostly noticeable in motion.
The camera doesn't "know" what's located outside the view frustum, so it cannot apply screen-space effects based on geometry positioned outside the view frustum (such as a wall or a glowing object).
This is an inherent limitation due to the screen-space nature of those shaders.

However, we can sidestep this limitation of screen-space effects by performing overscan on the 3D viewport buffers.
This consists in rendering the viewport at a larger resolution, increasing the camera FOV (like you'd do when supporting widescreen in old games) and displaying the middle of the viewport on the screen (letting the viewport's corners go outside the screen).
This can have a significant performance cost depending on the overscan factor used, but it can improve quality a lot on higher-end GPUs.

See this feature proposal for further details: #3854

Skills required/preferred: C++ programming, graphics programming (prior Vulkan or OpenGL knowledge required)
Size of project: 175 hours (part-time)
Difficulty rating: Medium

[akien-mga]

Guidelines for GSoC applications

Note: These guidelines are a work in progress and will be updated over the next few weeks.

Godot is a big project with dozens of contributors active on a daily basis, and as such we receive a lot of applications for GSoC each year, and can only select a few of them.
In the selection process, we aim at making sure that Godot is the right project for you to thrive in as a GSoC contributor, and that your idea is both wanted by the community and core contributors, and based on an implementation proposal that fulfills our requirements.

Over the years, we have found some elements that can be signs of a successful GSoC program where the contributor will be able to fit in the Godot community, and let both the contributor and their mentor(s) have a good experience. working together. You can consider them as pre-requisites for your application, as while they are not mandatory strictly speaking, we are unlikely to select a candidate that doesn't tick any of these boxes.

Join the community of contributors

• Join the Godot Contributors Chat to discuss with other contributors. Join the #gsoc and #new-contributors channels and any other that you are interested in - you're welcome in all public channels to read and participate in contributor discussions. Feel free to ask questions, and be patient - contributors are often busy and spread across many timezones, might not know the answer to your question right away, and might already be talking with other GSoC candidates asking similar questions. Take your time to familiarize yourself with the existing contributors.
  • You're also welcome to join any other community channel to interact with the community.
  • Make sure that you read and respect our Code of Conduct in all your Godot community interactions.
• Read our Contributing guidelines. There's a lot there so you might not want to read everything in one go, but you should have a general idea of what's in there for when you need to reference it (e.g. when making your first Pull Request).
• Do some contributions to familiarize yourself with our workflow. As mentioned Godot is a complex project and it can take a while to learn the ins and outs of the Pull Request workflow, our code style guidelines, our best practices for contributors. So we're automatically more interested in GSoC applications from people who we've interacted with on GitHub and who we know will be operative fast if selected. We recommend focusing on bug fixes and documentation updates - it doesn't have to be complex fixes, and it doesn't have to be related to the engine area that you're applying for - though it is a good idea to become familiar with the area you're interested in by doing some bugfixes, as it will help you write a better proposal with a good understanding of that section of the codebase.

Overall the most important is to show that you are able to communicate with contributors, listen to feedback, improve your Pull Request based on code reviews from contributors, etc.
A good communication flow between GSoC contributors and other existing contributors (and especially would-be mentors) is key to an exciting and successful GSoC project.

Application contents

IMPORTANT: Applications are only valid if submitted as "final" on the GSoC dashboard before April 19 at 18:00 UTC.

Your application should be a single document including:

• Descriptive title of your proposal
• Personal information:
  • Name, Email, Timezone, GitHub handle, if applicable Godot Contributors Chat handle
  • Link to Godot contribution(s) that you've made in the past (if applicable)
  • Any curriculum information that you find relevant (we don't need a full resume, keep it to a couple paragraphs at most)
  • Your motivation for contributing to Godot Engine
  • Information about other commitments that might affect your ability to work during the GSoC period (exams, classes, holidays, other jobs, weddings, etc.). This is not a selection criterion and the GSoC timeline offers a lot of flexibility for part-time work, but we need to know in advance and plan accordingly.
• Project information:
  • Use case: Describes the problem this feature would solve with some realistic examples of applications. This is very important, we only include features if they have a well-defined use case for making games or applications with Godot Engine.
  • Motivation: What's your personal motivation for working on this topic.
  • Feature proposal: Describe the feature that you would like to implement. Give a high level example of how it would typically be used (e.g. with mockups or pseudocode).
    Summarize your initial research on the topic (bug reports or feature proposals from the community, papers or blog posts, relevant FOSS libraries, discussions with contributors, etc.).
  • Project outline: Propose a timeline for the implementation of the feature (including writing relevant documentation and fixing bugs).