Shader baker
Preheat the oven
Anyone that plays modern games, especially on PC, has had the experience of waiting for shader compilation. Usually, it shows up in two forms: either the game makes you wait when it first launches, or it makes you wait right in the middle of the action.
That’s because shaders are small programs for your GPU that draw the current scene. And they need to be compiled in order to be used.
While pipeline compilation is still unavoidable and a requirement, Godot now offers a way to do everything that can be done by the editor ahead of time, reducing such wait times by a lot.
Where ubershaders were a big step towards optimizing pipeline compilation and eliminating compilation stutters, the shader baker addresses the long startup times.
When enabled in the export settings, the shader baker will scan resources and scenes for shaders and pre-compile them in the right format used by the driver on the target platform.
When targeting Apple and Windows devices, using Metal and D3D12 respectively, we even saw a 20× decrease in load times for our TPS demo. Talk about fast!
Duplicate at ease with expected results
As deep as you wish
For a long time, even though Resource.duplicate() has a deep parameter, people realized that setting it to true doesn’t always perform in a reliable and predictable way. Notably, it does not duplicate subresources stored inside Array or Dictionary properties. The same thing happens with Array.duplicate() and Dictionary.duplicate().
The new duplicate_deep() methods for these classes now give users full control over what gets duplicated or not.
This new feature is the result of an overhaul of the duplication logic for arrays, dictionaries, and resources. For developers, we made sure to keep what was working and consistent intact. If you need more details, feel free to consult our new exhaustive documentation about the duplication specification.1
Tailor fit the engine for your projects with these build profile improvements
Since Godot 4.01, users can open Project > Customize Engine Build Configuration to access the “Edit Build Configuration Profile” window. This utility helps with selecting and even detecting which classes (i.e. which Nodes, Resources, and servers) are actually needed for the currently opened project. The idea is that by reducing the features to only the ones actually needed, users can build their own Godot template that is custom fit for their game.
4.5 expands on what is detected. Not only does it detect classes, but can also now set correct build options. It also takes into account which classes are used by the project’s GDExtensions.
Editor language can switch on-demand
Changing the editor language no longer requires an editor restart.
This feature can be quite handy for editor plugin developers testing their translations.
For everyone else, now you can test the editor in all the languages it supports!
Execute EditorScripts using the command palette
Any named EditorScript files in your project now appear in the command palette, making it much easier to execute specific project commands.
Cascade content easily with FoldableContainer
The new FoldableContainer node adds an easy way to display a lot of details at the discretion of the user, in an “accordion” view.
It even supports grouping, making sure that only one foldable container is open at a time.
Handle a complex GUI easily with recursive overrides
Gooey GUI no more
It is now possible to change mouse and focus behavior of a Control node recursively. This greatly helps creating complex GUIs without breaking a sweat.
Here’s an example: let’s say you create an inventory screen for your game. On the left, there’s a grid displaying what the hero is carrying. On the right, it shows a detailed view about the selected item on the left; a rotatable display of the item in 3D to examine every detail, a section containing a scrollable description, a box containing stats and modifiers (with hyperlinks for technical terms), and a list of buttons representing actions that are possible to do with it.
Now, the problem is that the right view depends on an item being selected on the left. The user shouldn’t be able to interact with the detail view until that happens.
By changing Control.focus_behavior_recursive and Control.mouse_behavior_recursive of the detailed view container to their disabled value until an item is selected, focus and mouse events will be disabled for every child. You no longer have to resort to complex messages to manage the behavior of Control groups.
Editor UI adapted for non-desktop users
Virtual keyboard users can attest to the desktop-oriented nature of the editor UI. Common actions–such as undoing and saving–are tedious to execute, as they require opening up the menu bar each time to find the action.
With the new TouchActionsPanel, tablet and phone users now have direct access to common actions buttons.
This feature is currently Android-only, but we intend to port it to other platforms as soon as possible.
Support for devices with 16KB pages
Computers have a few tricks up their sleeves to handle gigabytes of memory. One such trick is “paging” memory in discrete blocks, so that the system can quickly jump to it when looking for a specific address.
Pages can come in multiple sizes depending on the platform. Since its inception, Android only supported 4KB pages, but the Android team recently announced compatibility with 16KB pages from Android 15 onwards. Developers should note, though, that starting on 1 November 2025, Google Play will require all new submitted apps targeting Android 15 to support 16KB pages.
Fortunately, we’ve got your back; Godot 4.5 supports this feature out of the box.1
Edge-to-edge support
Usually, developers had two choices for displaying content on the screen: either their app leaves the top and bottom areas for the system status and navigation bars, or their app could go full-screen, claiming all the space without displaying these bars.
From now on, there’s a new export option. Android has a feature called “edge-to-edge” display. It offers the developers the ability to draw on the entire screen, as if it was fullscreen, but with system bar overlays.
This gives your game a more modern look that matches Android’s design style.
Camera feed support
Godot now supports accessing the device’s raw camera feed on Android.
This enables developers to access live camera input and process the data for any purpose they want. From cute face filters to AR, the possibilities with this feature are endless!
WebAssembly SIMD support
Free performance boost
For about two years now, all major browsers have supported WASM (WebAssembly) SIMD. SIMD stands for “Single Instruction, Multiple Data” and is a technology that permits CPUs to do some parallel computation, often speeding up the program as a whole.
Starting with 4.5, you can expect your Web games to run a bit more smoothly, without having to do anything – especially when things get chaotic for your CPU. It isn’t a silver bullet for poorly optimized games, but it will help nonetheless.
Loading .NET assemblies directly from Android APKs
Straight from the source
Assemblies are the building blocks of any C#/.NET application as they provide types and resources for different functionalities. Functionalities range from system I/O utilities to your own game logic.
In the past, for Android, we’ve been extracting the .NET assemblies from the exported APK and stored them in cache. While this works well on other platforms, it caused issues on Android, such as outdated assemblies or permission errors.
We now load those assemblies directly from the APK, which solves all those issues.
Introducing variadic arguments
GDScript functions can now accept an arbitrary number of parameters!
extends Node
func sum(first_number: float, ...numbers: Array) -> float:
var total := first_number
for number in numbers:
total += number
return total
func _ready() -> void:
sum(1) # 1.0
sum(1, 2, 3) # 6.0
sum(1, 2, 3, 4, 5) # 15.0
Main loop callbacks
GDExtension plugins sometimes need to run code at engine specific cues. For example, there were a lot of issues accessing the engine singletons from GDExtension, since there was no simple way to know when the engine had started up or shut down.
From now on, developers are able to register main loop callbacks directly from GDExtension, such as startup and shutdown.
This new feature is the result of our ongoing efforts towards bringing C#/.NET to GDExtension, as the port needed to register a frame callback.
Bind bones to other bones with BoneConstraint3D
Yo dawg, I heard you like constraints, so I put constraints in your bones so you can move bones when bones move.
With BoneConstraint3D and the new AimModifier3D, CopyTransformModifier3D, and ConvertTransformModifier3D, it is now possible to bind bones to other bones. This can enable more natural movement and poses.
This feature is really helpful for handling VR and metaverse avatars.
Reintroducing batch editing of assets
If it ain’t broke…
Want to quickly change the same import setting for multiple resource files?
We reintroduced options in the Import dock for batch editing of assets. Now, when you select files in the FileSystem dock, the Import dock will let you select which properties you want to edit. With a single click of the “Reimport” button, your new import settings will be applied to all selected files simultaneously.
SDL3 gamepad input driver
Gamepads galore!
Gamepads are a given in modern PC gaming. Users expect their gamepad to just plug in and work. Not only that, but in order to deliver unique experiences, some gamepads are introducing new features; from adaptive triggers and advanced haptic feedback, to microphones and motion controls.
Over time, issues accumulated in our gamepad driver implementation and missing features began to crop up. We were facing an ever-growing mountain.
That’s why we turned our heads to the SDL project. SDL is a well established and mature cross-platform library that handles audio, keyboard, mouse, joystick, and graphics. We determined that it’s now a net positive to defer the responsibility for gamepad handling to it.
While this change doesn’t by itself bring new features, expect bugfixes and new features to come a little bit faster from now on.
SceneTree 3D physics interpolation
Frames grow on trees now
We transplanted (or should we say “grafted”?) 3D physics interpolation to SceneTree. Introduced in Godot 4.4, 3D physics interpolation is the concept of making physics-based movement appear fluid even if it’s running slower than the process frame-rate.
We previously implemented that feature in the RenderingServer, as the feature is mostly tied to drawing in-between states and it didn’t require changing code handling Nodes. Unfortunately, this caused some issues. Namely, in practice, Godot’s built-in nodes—and custom nodes—often rely on Node3D transforms for their behavior. Due to technical and performance-related reasons, it proved impossible to query the RenderingServer for interpolated transforms. We had to move everything to SceneTree for 3D, where nodes reside.
Not only has this fixed a number of issues, but it also makes everything conceptually easier for users and maintainers.
Don’t worry: what’s awesome is the fact that we kept the existing user API even if a lot changed under the hood. So this change shouldn’t break your project!
SMAA 1x support
Sometimes, addons are so good that they get promoted and included directly in the engine. This just happened to the Godot-SMAA addon.
Subpixel Morphological Antialiasing (SMAA) is a modern post-processing-based anti-aliasing solution, to get rid of those pesky jaggies. It provides sharper AA than FXAA at the tradeoff of being more resource intensive.
This is one step in our quest to improve the built in post-processing effects in Godot!
Mobile renderer now using half-precision floating-point format explicitly
Even the smallest float can change the course of the Mobile renderer
If a computer can only understand 0s and 1s, how can it calculate non-integer numbers? That’s where floating-point arithmetic comes in. It’s a method to represent these kind of numbers in binary.
A mobile GPU not only needs to process pixels as fast as possible, but it needs to do it in an energy-efficient way. Quite recently, the industry realized that even the standard single-precision floating-point (F32) format can sometimes be overkill in terms of size and processing power, even for rendering purposes.
With this new update, the Mobile renderer now explicitly asks for half-precision floating-point (F16) format if the hardware supports it—most devices commonly used should, especially if they are new. If so, games should now see rendering performance increase, run smoother overall (better frame pacing), and require less power usage.
Support for D3D12 OpenXR backend
We added a new backend for OpenXR! You can now render your XR projects using D3D12 on Microsoft platforms.
Foveated rendering on Vulkan Mobile
In order to push great visuals on a VR headset, a little cheating is often necessary. The human eye sees more detail at the center of your gaze, and less around your peripheral vision. So, why should we render the edges of the viewport at full resolution?
This is called “foveated rendering” and it’s something Godot has supported with OpenGL or Vulkan on desktop (via the “Fragement Shading Rate” extension) for a long time.
However, now support for the “Fragment Density Map” Vulkan extension has been added which also enables this on the Vulkan Mobile renderer, making it a more viable option for standalone VR headsets.
Application SpaceWarp, reporting for duty
Mobile headset resources can be sparse, so it’s important to know how to optimize the compute budget. Because XR requires a high refresh rate, developers are left with a limited timeframe to render. But what if we could use frame synthesis to our advantage? We could render at half-rate while the GPU synthesizes the next frame, keeping the targeted framerate as a whole while giving ourselves effectively much more time.
That’s exactly what Meta’s Application SpaceWarp does on Meta and Pico headsets. We now support this technology with the latest release of our OpenXR vendors plugin, thanks to the implementation of motion vectors in the Mobile renderer.
As OpenXR just released the multi-vendor Frame Synthesis extension, we expect support for more headsets in the future.
Yet another gargantuan release, totalling nearly 2,500 commits (excluding merge commits)!
Our focus on integrating accessibility options really shines through this release, with the express intent of creating an environment and experience that anyone can wield to the fullest. We'd like to thank the team behind the AccessKit project, and everyone else who helped integrate their systems and others like it.
More than 400 contributors were involved in this new feature release, and we want to thank them all for their amazing contributions, as well as all users who sponsor the Development Fund, reported bugs, opened proposals, or supported each other on our community platforms.
— Thaddeus Crews, Release Manager
Release page credits
- Web development and texts by Adam Scott.
- Texts revised by A Thousand Ships, John Veness, and Malcolm Anderson.
- Media content by Adam Scott.
- Additional media content by tagged content creators.
- Release thumbnail by Tibo.
- Header background by Lander Van Regenmortel.
- Design template by Luis Carli.