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

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: https://github.com/godotengine/godot-proposals/issues/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: https://github.com/godotengine/godot-proposals/issues/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: https://github.com/godotengine/godot-proposals/issues/3943, https://github.com/godotengine/godot-proposals/issues/596

Refer this pull request for designing & developing the code: https://github.com/godotengine/godot/pull/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: https://github.com/godotengine/godot/pull/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: https://github.com/godotengine/godot-proposals/issues/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: https://github.com/godotengine/godot-proposals/issues/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](https://github.com/zeux/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: https://github.com/godotengine/godot-proposals/issues/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](https://web.archive.org/web/20121105134010/http://dice.se:80/publications/title-shadows-decals-d3d10-techniques-from-frostbite/). See this feature proposal for further details: https://github.com/godotengine/godot-proposals/issues/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: https://github.com/godotengine/godot-proposals/issues/3854 **Skills required/preferred:** C++ programming, graphics programming (prior Vulkan or OpenGL knowledge required) **Size of project:** 175 hours (part-time) **Difficulty rating:** Medium

godotengine / godot-proposals