Overhaul addon startup
As the community grows and uses more and more add-ons, we found out that the current add-on startup logic is reaching its limits, as sometimes, you need to reload the editor for new add-ons to work. That’s why we intend to overhaul it to make the experience seamless.
Some research and optimization is needed for the editor file system access. We need to optimize all file access extensions. Ultimately, we need to rethink the current system in order to overhaul it.
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.
As part of this work we need to create high quality tests and benchmarks. Both to ensure that we do not break anything, but also to validate the performance improvements.
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.
To aid in this, we want to create more educational materials on profiling performance issues (both for CPU and GPU workloads).
In order to make the best decisions, we need to rely on mesurable 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.
We do have a public benchmark page! You can follow Godot’s main branch performance on the following website:
In order to make the best decisions, we need to rely on mesurable 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.
We do have a public benchmark page! You can follow Godot’s main branch performance on the following website:
Jolt is an open-source (MIT licensed) modern, multi core friendly rigid body physics and collision detection library, tailor-made for video games. We want to make it available to users by default, the current GodotPhysics 3D engine would still be available as an option.
As much as our nodes are made to be compatible with multiple physics engines, the existing integration of Jolt (via the godot-jolt add-on) 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 do expect it will create some compatibility issues.
As much as our nodes are made to be compatible with multiple physics engines, the existing integration of Jolt (via the godot-jolt add-on) 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 do expect it will create some compatibility issues.
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.
Post processing effects are 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.
Hardware ray tracing is slowly becoming more widespread. Soon it will be common for all desktop computers to support hardware ray tracing and soon after mobile devices will as well. 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.
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.
We identified at least two features that we wish to add
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.
Godot doesn’t know how to handle project file changes that happen on non-imported files, such as scripts, when it happens outside of the editor. This can be a common occurrence for users that use an external code editor. This can lead to numerous errors and inconveniences, such as scenes refusing to load. We intend to make this a relic of the past.
We introduced recently UIDs to non-imported files, such as scripts, in Godot 4.4.dev5. We need testing though to fully make sure that it solves our issues.
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.
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. We intend to add support for Blender materials, modifiers, and constraints.
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.
Currently, imported scenes (such as .glb, .fbx, and .blender files) show the scene icon in the FileSystem tab, making it difficult to filter out these files. Showing a preview icon of the scene would greatly help users in their workflow.
Scene inheritance is the concept of creating a scene based on an existing one. It is a feature that should work well in theory, but can be quite finicky in reality.
One idea is to give nodes unique IDs.
AccessKit offers a cross-platform way to implement accessibility features for UI toolkits, such as Godot. Integrating screen reader support into Godot will offer us and game developers opportunities to make more accessible products, such as the Godot Editor itself or games made with Godot.
It is known that compared to Godot 3.x, there’s some delays while creating new Window, especially on Windows.
Debug symbols allow developers to obtain more information when Godot crashes or logs an error. Currently, developers will only have debug symbols if they compile the engine from scratch. By distributing debug symbols for the official builds, developers would be able to easily diagnose crashes without making a custom build of the engine.
For all platforms that support separated debug symbols.
We often receive issue reports about gamepad support, as the numbers of gamepads never cease to increase. As we wish to support as many input devices as possible, we want to work towards better support.
We need to investigate how we can do this. One way would be to incorporate more code from SDL, or to integrate SDL_input directly in the engine.
Godot games should be able to seamlessly work when dragged across multiple monitors even when the monitors have different resolutions and DPI scaling factors.
Godot games should be able to seamlessly work when dragged across multiple monitors even when the monitors have different resolutions and DPI scaling factors.
When your game launches on Google Play, you will start to get automated reports from players highlighting issues like freezes, crashes, or poor performance. Right now that information is hard to make sense of due to the lack of debug symbols. We want to make it easier for users to utilize these reports either by providing debug symbols, or streamlining the process for developers to upload debug symbols themselves.
External textures are textures where their data comes from an external source. For AR, it means getting the camera feed (or anything that can be rendered) from the host operating system and displaying it over in Godot.
Link for the AR Core plugin for Android.
External textures are textures where their data comes from an external source. For AR, it means getting the camera feed (or anything that can be rendered) from the host operating system and displaying it over in Godot.
Link for the AR Core plugin for Android.
Right now the Wayland compositor is limited to making use of a single window. In order to achieve parity with other platforms, we need to add support for creating multiple windows.
As Godot grows in features, it also grows in size. Web games need to be as small as possible and the size of the engine is becoming a pain point for web games. We need to find ways to reduce the binary size as much as possible and provide tools to developers to easily cut features and reduce the size further.
Currently, if no specific steps are taken by the game developer, resources for a game on the Web are bundled into one single .pck file. As users need to download the entire game’s assets at front, we need to find a better way to split the loading throughout the game, only when needed. This would greatly improve the starting time of the game.
We need to investigate ways to solve the issue. We think a custom asynchronous filesystem could fix the issue, downloading files individually when needed.
For most platforms, the current official Godot builds suffice. Games may not use every feature the build has under the hood, but storage is usually not an issue. But Web platform games require the developer to optimize the load size (as bandwidth can be limited) and the load speed (Internet speed can vary).
We are investigating how we can reduce the build size, starting by offering an easy way to the users to customize their builds.
We’re thinking (out loud) about:
Before 4.3’s introduction of single-threaded builds, we had some compatibility issues, especially on macOS and iOS devices. The problem is maybe less important than it once was, but we continue to be alert about compatibility issues that can exist now or at any point in the future.
Before 4.3’s introduction of single-threaded builds, we had some compatibility issues, especially on macOS and iOS devices. The problem is maybe less important than it once was, but we continue to be alert about compatibility issues that can exist now or at any point in the future.
OpenXR uses the “OpenXR action map system” for handling input, whereas WebXR (and any other XR SDKs added via GDExtension) will use their own way of handling input. This complicates making a game that will work on both OpenXR and WebXR. We’d like to add a generalized XR action map system, which will use the OpenXR action map system on OpenXR, but provide a fallback implementation that can be used with any XR SDK.
And eventually other platforms.
Currently, when using OpenXR, you can use the Compatibility renderer or the Forward+ and Mobile renderers, but only when using Vulkan. We want to add support for DirectX12 and Metal so that users on all platforms can benefit from OpenXR.
The end goal is the ability to deploy Godot XR applications made with the executable downloaded from the website on any Android OpenXR conformant device.
The Vendor plugin should only be required to use vendor specific features.
As part of this we will add support for Android to use the Khronos loader.
It offers out of the box locomotion and interaction solutions built on top of Godots core functionality.
One of the main complaints of the GDScript language is the lack of namespaces. A namespace is a way to group code by a common name. This permits the reuse of classes using the same name, as long as they can be differentiated by their namespace.
But the problem can be found with .NET and GDExtension too. The problem occurs at the registration phase of classes in our internal database.
With namespaces, plugin developers could use their own class names without worrying about clashing with users’ internal ones.
One of the main complaints of the GDScript language is the lack of namespaces. A namespace is a way to group code by a common name. This permits the reuse of classes using the same name, as long as they can be differentiated by their namespace.
But the problem can be found with .NET and GDExtension too. The problem occurs at the registration phase of classes in our internal database.
With namespaces, plugin developers could use their own class names without worrying about clashing with users’ internal ones.
While GDScript is fast enough to operate as glue between nodes and program basic logic, its performance is lackluster when it comes to pure data crunching. We would like to improve the processing capabilities of the language and its run-time.
We’re currently investigating whether to compile GDScript, or to use AOT (ahead-of-time) or JIT (just-in-time) compilation techniques.
The main way to reuse code when writing code in GDScript is to use inheritance. While it works well for the most part, it leaves developers to rewrite a lot of code when that method cannot be used. So traits is the path we’re going forward to solve that issue.
The main way to reuse code when writing code in GDScript is to use inheritance. While it works well for the most part, it leaves developers to rewrite a lot of code when that method cannot be used. So traits is the path we’re going forward to solve that issue.
For the time being, users are required to download an entirely separate Godot build in order to use C# features. With our new upcoming .NET module, we intend to support C# with a simple plugin.
Everyone wins, as users won’t have to choose a special version to run C#. It reduces the number of builds on our side by half. Also, it will simplify .NET maintenance.
While the API documentation is complete, it currently lacks a specific .NET API. Both for newcomers and experienced users, it can be difficult or imprecise to translate the GDScript/C++ API to C#.
We intend to host a new website that will host an API documentation oriented for .NET users.
While the API documentation is complete, it currently lacks a specific .NET API. Both for newcomers and experienced users, it can be difficult or imprecise to translate the GDScript/C++ API to C#.
We intend to host a new website that will host an API documentation oriented for .NET users.
Currently, the engine’s capabilities are only accessible if the application itself is a Godot application. However, there are many situations where an application might want to use Godot as an intermediary. One case would be an application that uses native OS API for it’s UI, but needs Godot to render a complex 3D scene. Our goal is to make Godot available as a library to expand the possible uses of the engine.
This feature is better known as “LibGodot”.
GDExtension was created to allow developers to create extensions as if they were coding a module directly in Godot’s source code. Currently, modules can depend on one another, but this is not yet possible for extensions. We aim to expose the necessary API to be able to. So, for example, an extension built with godot-rust would be able to extend an extension built with godot-cpp.