Godot 4.3, a shared effort – Godot Engine

NavigationObstacle2D and NavigationObstacle3D now include two new properties to affect baking:

1. affect_navigation_mesh makes the obstacle contribute to the navigation mesh during baking
2. carve_navigation_mesh additionally makes the shape unaffected by offsets of the baking. The obstacle now basically acts as a stencil and cuts into the final navigation mesh surface. It will still be affected by further postprocessing.

In practice, this means obstacles now discard other source geometry inside them. In 3D, this helps discard unwanted navigation meshes inside objects like walls or roofs.

Shoutout to the game development streamers in our community, since they were the first to raise this issue!

With the new path simplification option on NavigationAgent nodes, it is now possible to remove less critical path points algorithmically.

This helps resolve some issues that come along with agent movement in large areas. It also benefits agents that use navigation points to steer as only the critical path points remain as targets.

The algorithm is also exposed from the NavigationServer where it can be used to simplify any generic Vector2/Vector3 array.

Compositor effects let users hook into the built-in Godot rendering pipeline to add custom rendering code. This is an advanced feature that does require intimate knowledge of how rendering works. Yet, it enables those specialists to create a variety of effects more efficiently.

We're already seeing some great examples from early adopters who utilize this feature to create god rays, implement motion blur, and more!

We refactored RenderingDevice, specifically how it manages device contexts, in order to annihilate some stubborn bugs in this area.

As a bonus, this lets us create new rendering devices whenever needed, which paved the way for finally baking lightmaps in the Compatibility renderer (which we recommend when targeting low-end devices and the Web platform at the moment).

RenderingDevice, the part of the engine that powers the Forward+ and Mobile rendering backends, was improved by the introduction of a directed acyclic render graph.

As newer GPU APIs (Vulkan, D3D12, and Metal) give developers more direct access to graphic cards, the burden for making sure everything works correctly falls on the user. The acyclic graph permits the engine to reorder and optimize commands in order to minimize the overhead of the graphics API while ensuring that everything happens in the right order.

Without making any changes to your 3D scene, you should expect to see a frame rate improvement of 5% to 15% (and more if you heavily use GPUParticles)!

The Compatibility rendering backend received a lot of attention this release cycle. It is now considered feature complete.

Keywords to look out for in this release are

• MSAA
• Resolution scaling
• Glow
• ReflectionProbes
• LightmapGI
• Adjustments
• Color correction

Since Direct3D is preferred by Windows, the addition of this new rendering driver improves compatibility with any Microsoft platform. Moreover, with Windows coming to ARM recently, this means you can use the Godot Engine on those devices from now on, as well as export your games for them.

Until now, you had to build a custom Godot version yourself and include the DXIL.dll library in your project in order to use Direct3D 12. This complication stemmed from the file being proprietary, which prevented us from bundling it with the Godot Engine. Thanks to Microsoft open-sourcing the DXIL validator hash last month, this is not a problem anymore, enabling us to support the Direct3D 12 rendering driver directly in official builds.

This feature is currently experimental and requires opting in

Wayland is a modern display server protocol that can be used on Linux and some BSD-derived operating systems. It aims to be a replacement for the X11 window system protocol and architecture. With built-in Wayland support, we allow developers to access a much cleaner API and new Wayland features as they are released.

To correct for lens distortion, visuals in 3D space have to be modified by the XR compositor. This extra processing can cause 2D content to become a little blurry and harder-to-read, especially the small text found in user interfaces.

By putting your UI in an OpenXRCompositionLayer node, you can force the XR compositor to directly render a viewport, leading to crisper and clearer 2D content.

In this release, we introduced a new standardized system for XR hand tracking, which allows developers to use one kind of node (and code) to create a hand tracking experience that will work in multiple XR eco-systems. This is currently supported by both OpenXR and WebXR.

On top of that, we introduced brand-new systems for body and face tracking, that are built in the same standardized way, but currently only supported in OpenXR on Meta Quest headsets.

Due to countless improvements made to this part of the engine, XR applications are now more stable and performant.

Highlights include:

• Improved timing of tracking data
• Foveated rendering has been tweaked on the Mobile and Forward+ renderers
• Glasses-based AR & passthrough-based AR have been unified

By supporting audio samples on the Web platform, we leverage their API to deliver seamlessly low-latency and high-quality audio.

This addition was needed to combat persistent audio issues experienced when exporting single-threaded Web builds.

The splash screen feature has been pretty established on all other platforms, and is now coming to the Web as well. As always, it is entirely optional for you to set one, and you are welcome to customize it to your liking.

Additionally, the Web progress bar has been reworked. We refrained from adding a fake time estimation.

Generic classes and methods are a staple in many programming languages. They defer the specification of parameter types until runtime, therefore making your code more reusable, type safe, and efficient.

While you could use generics previously, the editor potentially threw exceptions when reloading your code. This is now fixed.

In order to compile any C# project, the engine requires the .sln and .csproj files. If they were missing during export, you ended up with a broken executable - but without attempting to run it, you would not notice the problem.

To prevent this from happening, the editor does not allow exporting your project without them anymore and shows you a matching error instead.

Instead of writing
if not my_node is Node3D:

You can now simply write
if my_node is not Node3D:

This rather small change should help keep your code readable, by being closer to the natural language equivalent of what you are attempting to do: the test checks whether my_node is not of the type Node3D.

This change affects both methods and utility functions. We made it so that when you try to call these functions as you would with a Callable, an internal conversion happens to allow that to work.

For instance print() can now be called like so: print.callv(my_array)

This is particularly useful for variadic functions.

This feature is for the plugin developers amongst you.

Using the new @export_storage annotation allows you to store hidden values in a scene.

A common use case for this could be storing addon information in a node and preventing users from (accidentally) editing it in the inspector.

Another plugin development feature.

You can now use @export_custom to export a value suited to your needs. This means you can define prefixes and suffixes, custom hint strings, usage flags, and more.

We improved the autocompletion of several components, including enums, subscripts, and get_node().

Regressions in this area are hard to detect, so we began automated testing to verify the quality of these results. As always, you can help by opening a GitHub issue whenever you find a wrong or missing autocomplete suggestion.

Circular dependencies (also known as cyclic dependencies) happen when two scripts call upon one another. While this might be considered an anti-pattern in software engineering, in reality it is a rather common occurrence.

We fixed some known issues in GDScript that would show up in connection with such circular dependencies, to allow you to worry less about them in your projects. These changes will make your scenes more resilient and stable in general.

A virtual method (also known as virtual function) is declared within a base class, but implemented only by the derived class. This means the actual method call depends on the object type during runtime.

GDExtension classes were already able to implement virtual methods registered in Godot. Since this release, GDExtensions classes can also register their own virtual methods, which scripts attached to them can implement.

As a plugin developer, this allows you to expose your own virtual methods to your users now, in the same way that Godot exposes _ready(), _process(), or _draw() to you.