Priorities

As bigger projects often rely on CI (continuous integration) to test and deploy their projects, they need to be able to export games from lean environments that don’t implement a graphical interface (headless). For this, we need to make headless command line export more reliable, as there’s currently some issues that prevent it from working flawlessly.

We put a lot of effort lately to add ways to split the work of nodes into multiple threads. This can lead to great leaps in terms of performance. Unfortunately, many nodes are structured in a way that makes it difficult for them to take advantage of multiple threads. We need to audit our current nodes and fix the ones that are relying on being single threaded.

Much of the engine would benefit from a careful evaluation of the current performance bottlenecks and improvements to ensure that it is running as fast as possible. Godot 4.0 drastically improved the overall architecture of Godot, but there is still a lot of legacy code that is not benefitting from the architectural improvements. We need to seek out those areas and fix them.

In order to make the best decisions, we need to rely on measurable data. In order to be able to do this, we need to create more benchmarks. It gives the added benefit over time that we can spot regressions more easily, together with unit tests, as we started lately to track performance of nightly builds.

As much as our nodes are made to be compatible with multiple physics engines, the existing integration of Jolt is not optimal, as there are numerous features that can’t be implemented in Godot due to the current way the system works. In addition to integrating Jolt as the default 3D physics engine, we want to modernize our node bindings in order to fully exploit the new library.

We’re really proud of our in-house technology for global illumination, but we think that we can push performance and quality even further. This is a long-term effort, but is something we are very excited about and would like to see finished.

Some post-processing effects are currently a weak spot in Godot’s renderer. The performance and quality are both worse than we would like. We want to overhaul or replace most of our post processing effects in order to achieve both better performance and higher quality.

The goal of the rendering compositor is to give users fine control over the order of rendering operations and allow them to implement more custom behavior within the renderer.

Debugging and profiling are necessary tools to release high-fidelity games. Right now Godot’s debugging and profiling tools are relatively basic and unpolished. We want to make it easier to diagnose rendering issues and pinpoint performance problems instead of users having to rely on guessing and checking.

Shader templates can be used to have full control over the shaders used to render your assets. This allows you to both optimize your shader by removing unnecessary parts and to dramatically change your shader by adding custom behavior.

This feature would enable the streaming of assets to progressively load scenes, textures, and models in order to boost performance and loading times.

Hardware ray tracing is slowly becoming more widespread. It’s starting to become common for desktop computers to support hardware ray tracing, and mobile devices are starting to follow. We want to expose an API for hardware ray tracing through our RenderingDevice so that users can begin to make use of it. Then, eventually, we want to use that API to leverage hardware ray tracing in the Forward+ renderer.

Deferred rendering is a technique that can be used to increase performance in certain situations at the cost of flexibility. As Godot users create more complex games, we are seeing more games that would benefit from trading the flexibility that comes with our current renderer for more performance.

LightmapGI needs a lot of polish and improvements for us to meet the goals we have set for it. Baking times are slower than we want and it often takes too much manual effort to get bakes to achieve the quality that users need.

WebGPU is a new and modern API that offers direct access to GPUs, exposing features that are not otherwise available on the web. Once WebGPU is supported, it will be possible to export high-fidelity Forward+ and Mobile projects to the Web.

The SkeletonModifier3D abstract node introduced in 4.3 helps users to modify and add new functionality to bones via script. We want to build upon that new structure to add new features to it.

While the experience of dealing with 3D skeletons improved greatly upon the years, the same cannot be said of the 2D one. Our wish is to overhaul Skeleton2D animation in order to make it easier to animate and develop complex 2D figures.

Some file formats are actually containers that hold multiple resources. FBX and GLTF files are one of these, as they not only contain 3D models, but also can contain animations and textures. Currently, the only way to expose these resources is to tell the editor to pull these out on import.

We are thinking about providing a way to users to access internal subresources.

A lot of modern IDEs offer refactoring tools in order to rename variables and symbols across the codebase. We intend to add this feature to our internal GDScript code editor.

Right now the editor is not able to open or edit GDExtension classes. It effectively treats them like binary blobs. We want to make opening and editing GDExtension classes easier to do from within the engine and provide some of the comforts from regular scripting to GDExtension.

As Blender is both a FOSS and a very popular 3D editor choice by the majority of our users, it makes sense to improve compatibility with it. You can already import .blend files, but it’s limited to models, textures, lights, and cameras.

Godot imports .blend files by calling into Blender and asking Blender to export a .gltf file, which Godot then imports. Therefore, everything we want to export from Blender needs to be exported to the glTF data, including glTF extensions, and then Godot needs to import those, all in order for that data to make its way to Godot.

Godot currently has an advanced import dialogue which allows you to tweak many properties while importing assets. We want to polish and expand this dialogue to be more powerful. At the very least we would like to improve the preview lighting, expose more tools for material editing, and expose many more common properties.