Godot 4.5 RELEASE

Making dreams accessible

From mind-blowing effects now made possible by the stencil buffer to accessible descriptions of your GUI elements that opens up the possibility for people with disabilities to play your game — we are proud to present to you Godot 4.5. With this new release, we made meticulous efforts in order to amplify what is possible to do with our engine, guided by our goal of making gaming and game development for everyone.

Before you update

Before transitioning your existing projects to Godot 4.5, carefully read through our migration guide to learn about breaking changes.

Header background by Lander Van Regenmortel
Download and experience Godot 4.5 for yourself
(android) Godot Engine – Play Store
4.5

Play Store · arm64 · arm32 · x86_64 · x86_32 · 5 September 2025

(android) Godot Engine – APK
4.5

APK download · arm64 · arm32 · x86_64 · x86_32 · 5 September 2025

(android) Godot Engine – Horizon Store
4.5

Horizon Store · Meta Quest 3 & Pro · arm64 · 5 September 2025

(linux) Godot Engine
4.5

x86_64 · 5 September 2025

(linux) Godot Engine – .NET
4.5

x86_64 · C# support · 5 September 2025

(macos) Godot Engine
4.5

arm64 (Apple Silicon) · x86_64 (Intel) · 5 September 2025

(macos) Godot Engine – .NET
4.5

arm64 (Apple Silicon) · x86_64 (Intel) · C# support · 5 September 2025

(windows) Godot Engine
4.5

x86_64 · 5 September 2025

(windows) Godot Engine – .NET
4.5

x86_64 · C# support · 5 September 2025

Made possible by your donations

Stencil buffer support

Open your eyes for new effects

This shiny new feature has been a long time coming, partly because it relied on some other necessary changes in the engine.

A stencil buffer is a special buffer that meshes can write to for later comparison. It is similar to the existing depth buffer, except arbitrary values can be written and you have more control over what you do with comparisons.

Typically, you write into the stencil buffer using a special shader. Afterwards, another shader can compare with the stencil if a specific pixel covers it and decide if it needs to render (or not) at that position.

We’ve all encountered the issue of a character hidden behind a wall. How do we visually “drill a hole” in that wall in order to peep at the player on the other side?

That’s pretty simple to do with stencil buffers. Imagine an invisible sphere that surrounds our character. Even if geometry is not rendering itself on screen, we insert its shape into the stencil buffer. Then, we make our wall shaders only render if the target pixel is not covered by the stencil. Voilà.

This opens the door to many (many!) more effects as you can see in the example video, such as impossible geometry and portals.

Screen reader support

Show, don’t tell

Accessibility should be every developer’s top priority, full-stop. Excluding someone from an experience for factors outside of their control is an area that video games and applications have the potential to circumvent entirely.

One feature often overlooked that is a must-have in computer software is screen reader support. Such readers are an essential tool for people who are visually impaired, illiterate, or have a learning disability.1 It enables them to understand the context given visually. It does, however, take a solid framework to develop such accommodations. That’s because each platform has its own way to handle accessibility. This obviously makes it difficult to support every platform.

After 32,000 lines of code, hundred of comments, and countless hours of feedback and testing, we are proud to introduce the integration of AccessKit in the engine. It is a framework that launched 2 years ago in order to offer a way to bridge most of the platforms (macOS, Windows, and Unix/Linux using D-Bus) over a common API.

Thanks to AccessKit, we added screen reader support to Control nodes. We also added screen reader bindings in order to customize the behavior of any type of Node.

As this feature is quite new, please note that its integration is still in its experimental phase. And screen reader support for the Godot Editor itself is not complete yet—it is only implemented for the Project Manager, standard UI nodes, and the inspector. Expect follow-ups in future updates.

Script backtracing

You stay in Wonderland, and I show you how deep the rabbit hole goes

Those who launched a game using Godot can attest: it is often hard to debug why an error occurs on users’ devices. Is it a problem caused by the developers’ code, or a bug from the engine itself?

That’s why we’re introducing custom loggers and script backtracing.

Custom loggers allow developers to intercept log messages and errors. That makes it possible to create a tool for reporting bugs within your game.

Script backtracing, on the other hand, gives developers the exact details on where an issue happened in the code.1 Even in “Release” builds.

Developers will now be able to report issues to the issue tracker more accurately, making Godot more stable for them and their users.

  1. Just make sure that the Debug > Settings > GDScript > Always Track Call Stacks project setting is enabled. 

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!

Internationalization live preview

Hello

This new feature is key to our ideal of making gaming accessible for everyone.

From now on, developers will be able to preview translations directly from the editor viewport.1 This will ease the burden of testing the GUI in multiple languages.

How does your new UI react to being in French or Dutch? Or how does it look in simplified or traditional Chinese, or even in Hindi?

  1. The layout direction only follows the main locale currently. We’re working on fixing this issue. 

Chunk tilemap physics

Fusion… HA!

Ever since 2D tilemaps were first implemented, physics always relied on the concept of “one tile, one body”. While this works for most games, it can easily lead to performance issues in 2D scenes relying on physics as the number of bodies is extremely wasteful.

The system has been reworked from the ground up. Now, TileMapLayer physics merge cell shapes into bigger collision shapes whenever possible.

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

  1. See the Array, Dictionary, and Resource API documentation. 

Tailor fit the engine for your projects with these build profile improvements

Build profiles are a largely unknown feature, but they are incredibly useful. Especially with the latest improvements brought with 4.5.

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, preventing searching for a needle in a haystack.

  1. If you didn’t know about this feature, this is probably due to the fact that the documentation was somewhat lacking until now; mea culpa. 

Mute game toggle

Debugging can be tedious, especially if it exposes the developer to the same music over and over. One could turn off the speakers entirely, but that’s not really practical, is it?

To keep everyone’s sanity, we introduced the new mute game toggle, located in the Game view.

May your ears enjoy these new opportunities of quietude.

Drag and drop Resources in scripts to preload by UID instead of by path

With Godot 4.4, we extended UID support to more resource types in order to prevent broken paths.

Scripts can now take advantage of this by preloading resources via their UID.

By using UIDs instead of paths for preloading, your scripts will be more resilient, wherever the resources you’re preloading are in your project.

Allow selecting multiple remote nodes at runtime

The new embedded game window introduced in 4.4 highlighted an issue the editor had for many years now: the remote node list didn’t support selecting more than one item.

This is now a thing of the past. Developers can now select multiple nodes and even edit common properties.

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!

Toggleable inspector sections

Go Go Inspector Section!

As a user experience upgrade, we replaced the enabled property within groups with an intuitive checkbox beside the section name. You can now easily see which sections are enabled, even collapsed ones.

Plugin developers can use this feature in their projects using the new PROPERTY_HINT_GROUP_ENABLE.

Export variables as Variant

With this new update, it is now possible to export variables as Variant.

Previously, a variable could only be exported as a Variant if it had an initialized value. Also, the editor would stick to the actual type of said value, making it impossible to change the value to another supported Variant type, such as a String or Color.

Now, if the exported variable is of type Variant, the editor reacts accordingly, permitting the user to assign any compatible Variant value. There’s even a nifty type selector that changes the input widget accordingly.

Script color picker

Not everyone can read colors. So we added a little color preview next to every Color value.

We even pushed the idea further: if you click that preview icon, you can edit the value on the spot using a color picker.

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.

“Paste as unique” option

When copying and then pasting a resource in an editor inspector slot, it usually pastes a reference to the copied resources. If you wanted a unique copy instead, you had to manually click on “Make Unique” afterwards.

Now, the new “Paste as Unique” option, available in the resource picker dropdown, makes the operation way less tedious.

Duplicate projects straight from the Project manager

There’s now a dedicated “Duplicate” button in the Project manager, making it easy to back up an existing project, or to fork a new one.

We also figured that it would be a great tool to prevent losses if you update the engine version during development. If we detect that irreversible changes would occur due to the update, we’ll ask if you want to back up your project first.

Append signal source automatically

This will really help unbinding signals from their source and make code reuse far easier.

When connecting signals in the editor, you’ll notice a new “Append Source” option in the advanced settings. If this checkbox is enabled, the source object will be appended right after the original arguments of the signal.

Animation player quality-of-life upgrades

The animation player has received some much needed love!

  • You can use the selection box to select and scale Bézier editor points. Now it’s a piece of cake to perform batch changes.
  • When creating Bézier points, you can auto-tangent new points in a balanced or mirrored manner.
  • You can sort the animation player’s animations alphabetically.
  • It is also possible to filter animations by their names!

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.

Label stacked effects

Style labels as much as you want with Godot 4.5. We added support for stacked layers of effects; no cumbersome workarounds required.

You want it outlined with complex shadows? Done.

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’s 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.

Added “required” qualifier

But Thou Must!

When extended, some classes need some virtual methods to be overrided in order to work. But it wasn’t always obvious in the documentation.

This won’t be an issue moving forward, as now the new required qualifier will come right after virtual where applicable.

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.

Native Wayland sub-window support

One step closer to Wayland game embedding

Game embedding is coming for Wayland. But the support for sub-windows was an important (and not a small) hurdle to cross in order to achieve this in the future.

Sub-window support means that Godot can now spawn new independent windows when running on Wayland natively.

Game embedding support on macOS

macOS Godot users can now enjoy the embedded game window introduced for some platforms in 4.4.

Export to visionOS

You can now export for Apple’s XR platform, visionOS, making Godot projects compatible with the Apple Vision Pro.

Godot 4.5 marks the first step of visionOS’ native integration. For this, we would like to thank Apple’s visionOS engineering team for their contributions adding support for their operating system to the Godot Engine.

This is a big deal: visionOS is the first platform supported natively by Godot since the project was open-sourced!

Currently, it is only possible to export a project as a “windowed app”. Your game will appear as a window, floating in the user’s 3D space. We expect to support fully immersive experiences in the future.

Modify metadata without rcedit

So long, rcedit!

Windows .exe file metadata (such as a custom icon, the product name, and the company information) is stored internally as “resources”.

For years, in order to modify these resources, the Windows exporter needed to access an external Windows program: rcedit. That made it really difficult to export for Windows on a non-Windows machine.

But now, the Windows exporter now knows how to handle the resources natively, so you can edit Windows export metadata without a hitch, on every platform.

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.

NativeAOT on Android

Fluent in your device’s language

“NativeAOT” refers to the ability for .NET applications to compile directly to a device’s native code, bypassing the need for the .NET runtime entirely.

It notably enables faster startup times and has a smaller memory footprint.

Thanks to the newly added linux-bionic RID export support, we’re able to bring that feature to Android devices.

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

Abstract classes and methods

U Can’t Touch This

You can now declare GDScript classes to be abstract. Declaring a class abstract means that the class is not meant to be instantiated directly. That means that you can prevent instances of a class, let’s say, Animal, that doesn’t have any purpose on its own other than to be extended by “concrete” classes like Cat and Dog.

Abstract classes can also have abstract methods. This means that the method must be implemented in any class that extends it.

animal.gd
@abstract
class_name Animal extends Node


@abstract
func cry() -> void
cat.gd
class_name Cat extends Animal


func cry() -> void
  # Must be implemented, otherwise an error will be thrown.
  print("Meow!")
Image of the Add Node window displaying the dimmed out abstract Animal node, and its two extending classes Cat and Dog.

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.

Allow calling Object::set_script_instance() from GDExtension”

Great news for scripting language support in Godot!

This new feature makes it easier to implement GDExtensions that add scripting language support. This improves parity with adding scripting languages via a Godot module.

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.

Dedicated 2D navigation server

Ever since its introduction in Godot 4.0, users and navigation nodes interfaced with the NavigationServer2D for all their 2D-pathfinding needs. But what if I told you that NavigationServer2D was hiding something?

Previously, NavigationServer2D was effectively a proxy for NavigationServer3D; it used the 3D navigation logic but with everything constrained to two axes.

However, this had an important caveat. Pure 2D games using navigation required an export template that had 3D support. That would obviously bump the final export size of their game.

We now finally managed to create a dedicated 2D navigation server. Users will be able to tweak their 2D and 3D navigation servers independently.

Process navigation regions asynchronously

The main thread of a computer program is like a project leader. If the project leader handles too many tasks and doesn’t delegate enough, it can affect the overall performance of the team.

Enabling async iterations asks the navigation servers to delegate the navigation process to a background thread, which can improve overall navigation performance.

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!

Specular occlusion from ambient light

Added realism for cheap

Ever wondered why some objects would eerily shine as if they were lit in an occluded area where they shouldn’t? For example, a common stumbling block for users is seeing light from the sky get reflected in the cracks between bricks in a brick wall.

That’s because the calculation of the light reflected off a surface didn’t take ambient occlusion into account.

Fortunately, our renderer now has a cheap option for specular occlusion that should fix this issue.

For existing projects where it could break the look, don’t fret. A toggle is available in the project settings.

Bent normal maps support

Introducing the normalbender

In rendering jargon, a normal is a 3D vector which is perpendicular to a surface. A normal map is a texture where each pixel of it represents a normal—using the red, green, and blue intensity as the vector axis values.

Normal maps are often used on models to add surface details without having to make the meshes super detailed. If the normal map describes a bump, the lighting system will make it look like there is one, even if the underlying polygon is flat.

Bent normal maps are similar, as they are textures representing 3D vectors each pointing at something. The normals are considered “bent” because instead of being perpendicular to the surface, they actually point towards the direction of least occlusion—i.e. the direction with the least amount of stuff blocking the incoming light. For example, if a theoretical bent normal map was created from the insides of a cave, each vector would point towards the opening.

What does it mean? Why should we care about the direction of least occlusion?

This information is extremely valuable to the renderer. It is used to further enhance specular occlusion (darken areas that shouldn’t be receiving a lot of reflections) and indirect lighting (provide more accurate reflections).

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.

Fragment density map support

In order to push great visuals on a VR headset, a little cheating is often necessary. As players tend to turn their head rather than move their eyes too far from the center and as pixels around the edges of the viewport are often distorted by the lens, why should the device render these parts at full resolution?

This is exactly what the “Fragment Density Map” Vulkan extension does: it renders the edges of the viewport at a lower resolution with little noticeable decrease in quality. It makes the Mobile renderer (using the Vulkan rendering driver) more viable for VR on standalone.

It is not necessarily a new feature to Godot, as the “Fragment Rate Shading” Vulkan extension already does something similar. But they differ in terms of device compatibility. Don’t worry though, as Godot will now choose the best supported method for the device. Users will only have to care about “Variable Shading Rate”, which is the term that encompasses both extensions.

OpenXR render models

Godot added support for the XR_EXT_render_model and XR_EXT_interaction_render_model extensions introduced in OpenXR.

These extensions, when enabled and supported, give an application access to fully animated models of the controllers currently held by users, including tracking data for these controllers. This means Meta Quest 3S and Pico 4 Ultra users will see their respective controllers in their hands without extra effort from the developer.

In order to use this feature in your game, you need to add OpenXRRenderModels as a child node of the XROrigin3D node. For more information, please see the docs.

Release authors

Team work makes the dream work

Here you can see all the contributors who had PRs merged into this release. The names are ordered alphabetically, and sized according to their number of contributions.

Special thanks goes out to all the engine teams that collaborated on this release, especially since commits to other related repositories (documentation, godot-cpp, etc.) do not show up in this graphic.

TODO

— Thaddeus Crews, project manager, 4.5 release commit

Release page credits