Godot Engine Official

Dev snapshot: Godot 4.4 dev 7

2024-12-19T18:00:00+00:00

Season’s greetings, everyone! As our team winds down for the holiday season, we present you with one last gift before the new year: our final development build of the year!

After having a few notable regressions in dev 6, we intended to do a quick turnaround for dev 7 with high priority bug fixes. But we got greedy and ended up making dev 7 another feature-packed new release so you will have plenty of things to check out while we are on holidays.

Keep in mind that while we try to make sure each dev snapshot is stable enough for general testing, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.

Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor, XR editor, or the Android editor for this release (join the Android editor testing group to get access to pre-release builds).

The cover illustration is from Pest Apocalypse, a hyper-realistic post apocalyptic physics based pizza delivery action rogue-lite! It is developed by Kikimora Games. You can purchase the game on Steam, and follow the developers on BlueSky and Discord.

Highlights

In case you missed them, see the 4.4 dev 1, 4.4 dev 2, 4.4 dev 3, 4.4 dev 4, 4.4 dev 5, and 4.4 dev 6 release notes for an overview of some key features which were already in those snapshots, and are therefore still available for testing in dev 7.

Here are highlights of a few new features in dev 7 that you might find particularly exciting!

Jolt Physics module

Ever since its inception in late 2022, godot-jolt has become the de-facto 3D physics engine for many of our developers. Much of the history behind why this was the case is documented in this proposal by Adam Scott, but the main takeaway was a strong push for this tool to be recognized as an official addon. In doing so, users would be able to find this amazing resource in a way that was promoted by the engine itself; an exciting prospect!

The Godot Jolt maintainers, Mikael Hermansson and Jorrit Rouwe, took this idea one step further: integrating the tool as part of the engine directly. There was already a symbiosis between their team and the Godot engine, with many features being added to Godot and Jolt to accommodate both, but the integration of an official module was no small feat; their pull request (GH-99895) ended up adding over 500 files and 115 thousand lines of code! So while this was one of the most rigorously tested PRs relative to the amount of time it’s been up, it’d be impossible for any team to account for everything this behemoth introduced, so we eagerly await your feedback (and bug reports) on one of the most highly-requested features of 4.x.

Note: At time of writing, this does not replace Godot Physics as the default 3D physics engine. The Jolt Physics integration in Godot is considered experimental, and may change in future releases. It also lacks some features of Godot Physics so isn’t a full drop-in replacement. If your interests/use-case are supported, the tool can be enabled by changing the physics/3d/physics_engine project setting to Jolt Physics.

.NET 8.0

Paul Joannon and Raul Santos have put the final pieces in place for moving both the GodotSharp library and user projects to .NET 8 (GH-92131 and GH-100195). All new projects will use .NET 8 by default and existing projects will automatically update to .NET 8 once opened with this release or any newer 4.4 build.

Improved Scene Tree editor performance

The amount of performance boosts that have been crammed in between dev 6 and dev 7 has been staggering. Of note are the recent improvements to the engine’s core including many optimizations throughout the String class, spearheaded by Ivorforce. But perhaps the most obvious improvement comes from HP van Braam and their modifications to the SceneTree system (GH-99700). While this will prove beneficial across all projects, these changes result in especially complex scenes having a tenfold performance in the editor when moving or renaming nodes in the SceneTree.

Documentation tooltips

Thanks to Danil Alexeev the GDScript code editor will now display a tooltip containing information about functions, variables, classes, etc. when you hover over them, including the documentation you have written using our documentation system (GH-91060). This makes using the integrated documentation system even more powerful as you no longer have to bounce between the code editor and the related docs to quickly get information.

Baked shadowmasks for lightmaps

Until now, you have always had to choose between fully baked or fully dynamic shadows when using LightmapGI. However, sometimes you want to have dynamic shadows up close where detail matters, but use static shadows in the distance where a low resolution is acceptable. Finally it is possible thanks to the hard work of BlueCube3310 in GH-85653. You can now enable shadow masks while baking your LightmapGI to combine dynamic and static shadows for the best quality.

Additionally, this allows you to drastically shorten the range of your dynamic shadows which is a very important optimization, especially for mobile devices.

This feature is still experimental and it will change in response to feedback, so please test it out and let us know what you think!

Updated toolchains for official builds

We updated some of the toolchains we use for official builds in build-containers#150, notably macOS and iOS SDKs from Xcode 16.2, and MinGW 12.0.0 with GCC 14.2.1 for Windows builds.

Toolchains for Linux, Android, and Web are still the same versions as for Godot 4.3.

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

3D: Add 3D translation sensitivity to Editor Settings (GH-81714).
3D: Add ruler mode to 3D (GH-100162).
Animation: Add animation node extension (GH-99181).
Audio: Add Web MIDI support (GH-95928).
Buildsystem: Add loongarch64 support for Linux/*BSD (GH-97822).
Buildsystem: Make Godot compile on FreeBSD (GH-100047).
Core: Fix JSON.{from,to}_native() issues (GH-99765).
Core: Optimize StringBuilder by using LocalVector instead of Vector (GH-99775).
Core: Optimize String construction from statically known strings by evaluating strlen at compile-time (GH-100132).
Core: Add move assignment and move constructor to Variant (GH-100426).
Documentation: Document _process() and _physics_process() delta behavior at low FPS (GH-94636).
Editor: Add ability to create a new inherited scene from code (GH-90057).
Editor: Add profiler autostart indicator to EditorRunBar (GH-97492).
Editor: Allow dragging to specific folders in filesystem dock (GH-99453).
Editor: Make the Script Editor’s parser execute sooner on edit after error was found (GH-87542).
Editor: Show String properties’ text in a tooltip in the inspector (GH-76231).
Export: Use temp dirs instead of cache dirs for export (GH-100150).
GDExtension: Fix Variant modulo operation (GH-99559).
GDScript: Add @warning_ignore_start and @warning_ignore_restore annotations (GH-76020).
GUI: Change default Arabic font to Vazirmatn (GH-100053).
GUI: Fix Tree drag-and-drop scrolling having low FPS at low Physics Ticks per Second (GH-98766).
GUI: Improve emoji SVG parsing by caching (GH-100300).
GUI: Save color palette as resources to reuse later (GH-91604).
Import: Consider all texture types for resource thumbnail generation (GH-100247).
Input: Add Tablet/Trackpad 3D navigation preset (GH-97985).
Navigation: Despaghettify NavigationServer path queries (GH-100129).
Plugin: Export EditorInspector::instantiate_property_editor for use by plugins (GH-87375).
Rendering: Add Blend Distance property to ReflectionProbe (GH-99958).
Rendering: Allow changing the anisotropic filter level at run-time per Viewport (GH-88313).
Rendering: Further performance improvements from The Forge (GH-99257).
Rendering: Automatically compress new lightmap textures (GH-100327).
Rendering: Optimize PointLight2D shadow rendering by reducing draw calls and RD state changes (GH-100302).
Rendering: Implement RD::buffer_get_data_async() and RD::texture_get_data_async() (GH-100110).
Shaders: Avoid error spam when shaders fail to compile by freeing shader_data version when compilation fails (GH-100128).
XR: Allow locking the camera to the XROrigin3D for benchmarking or automated testing (GH-99145).
XR: OpenXR: Add support for binding modifiers (GH-97140).

Changelog

113 contributors submitted 263 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev6 snapshot.

This release is built from commit 46c8f8c5c.

Downloads

Download Godot 4.4 dev7

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

.NET 8.0 or newer is required for this build, changing the minimal supported version from .NET 6 to 8.

While engine maintainers try their best to ensure that each preview snapshot and release candidate is stable, this is by definition a pre-release piece of software. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.

Known issues

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

There are currently no known issues introduced by this release.

Bug reports

As a tester, we encourage you to open bug reports if you experience issues with this release. Please check the existing issues on GitHub first, using the search function with relevant keywords, to ensure that the bug you experience is not already known.

In particular, any change that would cause a regression in your projects is very important to report (e.g. if something that worked fine in previous 4.x releases, but no longer works in this snapshot).

Support

Godot is a non-profit, open source game engine developed by hundreds of contributors on their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!

If you’d like to support the project financially and help us secure our future hires, you can do so using the Godot Development Fund platform managed by Godot Foundation. There are also several alternative ways to donate which you may find more suitable.

Godot XR community - December 2024

2024-12-18T12:00:00+00:00

Godot has a very active XR-focused community on the XR channel of the official Godot Discord server. Today, we want to put a spotlight on a number of community projects.

Godot XR community Game Jams

To showcase the engine capabilities and the ingenuity of the Godot XR community, game jams are now being organized twice a year. It’s a fun way for participants to get introduced to Godot’s XR capabilities.

Godot XR Game Jam #1

The first Godot XR Game Jam was held from 1 December until 4 December 2023. The theme of this game jam was Vapor. We saw both many new faces and long-time community members join, and had a total of 17 entries.

The #1 spot went to Cloud Shepherd which won 3 out of 6 categories, including “Originality”, “User experience”, and “Audio”. In this entry, you herd sheep on clouds in the sky by using fans to create breezes that blow the sheep to their destinations.

The #2 spot was taken by Super Steam Hands which won 2 out of 6 categories (“Fun factor” and “Theme incorporation”). Don’t let the thumbnail of this entry fool you. It’s a great game where you can feel like Iron Man by using jets of steam to parkour around a level.

The #3 spot went to Pipe Stream which ranked the best in the “Haptics” category. It’s a great little puzzle game where you need to chip away a path for vapor to reach a target. Very challenging!

There were far more great entries, so be sure to check out the jam page for more!

Godot XR Game Jam #2

The second Godot XR Game Jam was held from 8 July until 15 July 2024. We decided to give participants a full week to complete their game. The theme this jam was Relaxation. There were a total of 26 entries and this time we scored them on the average points in all categories.

The #1 spot went to Who’s a good boy with 4.042 points. This cute little game has you play fetch with a dog in a park. It features some excellent interactions both from the player’s and dog’s points of view.

The #2 spot went to Constellation Coach VR with 3.974 points. This game has you find constellations in the night sky by holding up a picture of the constellation and aligning it with the relevant stars. Excellent haptic feedback lets you know when you’ve gotten close, and successfully aligning the constellation lights it up.

The #3 spot went to Summer Pottery VR with 3.938 points. This game lets you do some clay pottery sculpting. It’s a great and very well-executed use of physically interacting with the clay to shape and paint your creation.

Again, many of the other entries were of great quality and we highly recommend checking them out.

Godot XR Game Jam #3

The 3rd game jam will be held in the week starting 10 February 2025. You can read all about it and sign up here.

Universal Godot VR plugin

Inspired by the Universal Unreal Engine VR Mod, community member TeddyBear082 has created a mod to inject VR capabilities into existing 3D games made with Godot.

TeddyBear082 previously made a name for himself with the excellent VR port of the popular game Cruelty Squad and has used the knowledge gained with that and similar projects to create a more universal mod.

You can find the plugin on teddybear082’s GitHub profile.

Body tracking and motion capture plugins

Core contributor Malcolm Nixon has created various plugins for Godot that use the new body tracking feature to make tracking data available from various sources.

He has support for Rokoko, Axis Studio and Movella. He also has a plugin for VMC (Virtual Motion Capture), which is a standard used by a number of motion capture systems.

You can find the plugins on his GitHub profile.

Meta platform plugin

Community member Decacis has released a few of his games on the Meta Horizon store and implemented part of the Meta platform SDK in support of this. He has implemented support for things like in-app purchases, leaderboard, challenges, and much much more.

The plugin he created is open source and can be found on his GitHub profile.

Godot XR Tools

We’ve showcased XR Tools before, but with version 4.4 of the plugin nearly ready for release, it’s worth quickly looking at what’s coming.

Improved support for Godot 4.2+ features such as pass through logic with both OpenXR and WebXR.
New objects to make games suitable for both VR and non-VR use.
A new gaze interaction component for controller-less experiences.
Various improvements to snap points.
Improvements to hands interacting with physics.

Godot ARCore support

ARCore support in Godot has been a long time coming. From an early working prototype in Godot 3, to moving this into a community maintained plugin, there have been plenty of hurdles along the way. Thanks to the persistance of Patrick Exner, Luca Junge, and Chambefort Maxime, we have nearly reached the finish line.

Supporting changes were recently merged into the master branch of Godot and you can find the plugin itself on the plugin’s GitHub.

Meet the creator behind the Godot Game Awards

2024-12-09T18:00:00+00:00

If you’ve watched Godot-related content on YouTube, StayAtHomeDev needs no introduction. He’s been sharing his passion for game development and the Godot Engine through his channel. As the creator of the popular “This Week in Godot” series, and the Godot Game Awards, he’s helped showcase the amazing work of the Godot community. We had the chance to talk with him about his journey, what inspired the awards, and his efforts to support the community.

What inspired you to create the Godot Game Awards, and how long has it been running?

I started the “This Week in Godot” series over two years ago on my channel. At first it started as a compilation of cool projects or games I found throughout each week. About 7-8 videos in, I thought it would be cool if people could vote for their favorite each week and the engagement exploded. People would comment every week and eventually I compiled every winner into a final vote for the “Best Godot Project of the Year” in 2023.

This year I wanted to expand that into multiple categories, highlighting certain achievements like art design and music, and give attention to other things like plugins, tutorials, even devlogs. From that came the Godot Game Awards, a compilation of the best Godot-based games, plugins, and projects as voted by viewers on my channel.

How can people get involved in this year’s edition?

People can get involved from now until December 15th by voting on the 20+ different categories with an official 2024 🗳️ Godot Game Awards Ballot.

The winners will be announced in a premiere video on December 28th at 2:00pm EST on my channel so that everyone can watch together and help support the great work by these developers.

Tell us about your YouTube channel—what kind of content do you focus on, and what motivated you to start creating videos?

I started StayAtHomeDev over two years ago to share my passion for creating through game development. At the time, I had a potential job offer to be the Web Coordinator for a professional football team in the US. But I had just been given a grant by Meta for some VR development work with their Oculus Quest 2 headset so I used that to launch the channel. It really was an exercise to create independent income so I could stay at home with my kids. That was a lifestyle choice I knew I wanted to make for them, so I took a shot at YouTube.

I’m very interested in sharing knowledge so the channel has had an element of teaching with tutorials or game development concept videos. With the “This Week in Godot” series, the channel started to steer more towards enriching the Godot community and showcasing what people were creating with the engine. Now, it’s a mix of tutorials, QAs about general game development topics, and the newest format, interviews. I am actually most excited about the interview videos because they really give a chance for viewers to peek into real game dev life with stories and advice from developers actively breaking through the industry or those who are already successful, and of course doing it with the Godot Engine.

How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?

If you look at the earliest videos on the channel, you’ll notice they were all focused on the Unreal Engine. I actually worked within Unreal first. Long ago…like long ago…I started making little games with an engine called 3D GameStudio.

When I started the channel, I knew of Godot (which I thought was called GoDot) but never tried it. After spending more time on YouTube and lurking around other game dev content, Godot kept popping up, so I took it for a test drive. I ended up making a video about it which went “viral” for a small channel while my first kid was being born. There was clearly a lot of interest in the engine so I kept playing around with it and fell in love. Not only with how streamlined it felt but also because it was open source and had such a strong sense of community and pride. I decided I wanted to help support that with the channel.

What advice would you give to someone starting out as a game developer or content creator in the Godot community?

I would say the WORST thing you can do is stop yourself before you even try. Game development and content creation are both difficult. They are also largely self-motivated so telling yourself you can’t do them means you likely won’t.

The BEST thing you can do is just try. If you are interested in making games, download the engine and try. You are going to hit walls and fail at a number of things but that’s part of the learning process. The information and tools are out there, you just need to start the climb.

In more applicable terms…start small, remake Pong or level 1 of Mario Bros. If something seems too difficult to understand, break it into smaller pieces. Don’t try to make an entire 2D platformer controller, make it move left and right first. And don’t think you’re going to sell your first game and make tons of money. You’ll put too much pressure on yourself and it won’t be fun anymore, you’ll get frustrated, and you’ll quit.

For content creation, it’s a marathon so the most important thing is don’t worry about the views. Make content that you want to make. If a video gets more views than normal, analyze why, and do it again with a small change. YouTube is sort of a constantly moving target and you won’t get a good idea of your style, your interest, or what people want to watch for a while. And even then, those things can always change. Consistency is the important variable…keep doing it and consistently try to get better. Better sound, better speaking, better editing, better pacing, better thumbnails, better topics, better storytelling. There is always something you can improve. If you create videos consistently and improve with every video, you’ll get to where you want to go and build a ton of new skills along the way.

Do you plan to continue organizing the Godot Game Awards in the future?

Absolutely! There have already been nearly 1000 ballots submitted, which is crazy to me. People comment how they enjoy finding new Godot projects every week with the weekly video series and tell me that they feel inspired to make something themselves. That is the best thing I could hope for, that people feel inspired to create. I’m also a music therapist so I have seen the effect creativity and expression can have on a person’s well-being. To me, games are an art form and within that lies the ability to create powerful feelings in other people through interactive play. If one person continues to be inspired by the games showcased in the awards, then I’ll keep making the videos.

🗳️ Vote now! 👈

If you want to support StayAtHomeDev you can visit his Patreon, subscribe to his channel, or vote for your favorite Godot projects each week.

Good luck to all the nominees, and thank you StayAtHomeDev for all your work organizing the awards!

Dev snapshot: Godot 4.4 dev 6

2024-12-05T17:00:00+00:00

Safety goggles on, people! Features and Quality-of-Life are being integrated at blinding speeds; precautions must be taken to view them head-on. Once secure, we can dive into what’s shaping up to be one of the final development snapshots before 4.4-beta builds roll out!

The cover illustration is from Malware, an installation simulator where players must navigate a minefield of circa-1999 malware! It is developed by Odd Games. You can purchase the game on Steam.

Highlights

In case you missed them, see the 4.4 dev 1, 4.4 dev 2, 4.4 dev 3, 4.4 dev 4, and 4.4 dev 5 release notes for an overview of some key features which were already in those snapshots, and are therefore still available for testing in dev 6.

Here are highlights of a few new features in dev 6 that you might find particularly exciting!

Camera3D preview in inspector

Previously, adjusting the view of a Camera3D in a scene could be a chore to handle. It required activating the camera you wanted to preview, and then reverting it back if it wasn’t the main camera. You could pin a preview of a camera in a dedicated viewport, but that meant reducing the real-estate of your main viewport.

Now, with Haoyu Qiu’s feature (GH-90778), every selected 3D camera shows a preview inside the inspector. No switching cameras needed to preview anymore.

CollisionShape3D debug color customization

3D collision shapes now have parity with their 2D counterparts with the newly added debug_color and debug_fill properties, which lets you customize the appearance of debug collision shapes in the editor, or at runtime if “Visible Collision Shapes” is enabled in the Debug menu. Thanks to first-time contributor BattyBovine for implementing this much-requested proposal (GH-90644).

Replace internal CSG implementation with Manifold library

Godot added support for CSG, or Constructive Solid Geometry, back in 3.1. This is a great tool for rapidly prototyping level geometry or even simple props and characters by combining 3D primitives with various boolean operations (union, intersection, subtraction).

Our implementation suffered from a number of bugs and stability issues, with no dedicated maintainer to tackle them. Thankfully, a great open source library has been released since then which can be used as a well-maintained replacement for our CSG internals: Emmett Lalish’s Manifold.

Ernest Lee did an amazing work implementing Manifold in Godot, with help from Emmett to ensure that the library fits our requirements (GH-94321). As this is a fairly big change to how Godot’s CSG works internally (but with minimal impact on the user API), you might notice differences in your projects using CSG. Please report any change that appears to have a negative impact on your usage.

Runtime WAV file loading

First-time contributor cherry implemented the long-requested support for runtime loading of WAV files (GH-93831). This adds parity with OGG Vorbis audio tracks, and will be a welcome addition for users who want to load user-generated content at runtime (including non-game audio applications).

Extend Curve to allow for domains outside of `[0, 1]`

Have you ever wished that you could edit a Curve in a domain that goes beyond the normalized [0, 1] range? ocean finally got their implementation of this feature merged (GH-67857), which should give you greater flexibility in how to map your functions and data to Godot’s ubiquitous Curve resource.

Temporary file and directory utilities

Tool creators, Adam Scott cooked a little something that could be interesting for you. A brand new API lets you create and dispose of temporary files. Handy if you need to write content on disk, but without worrying about polluting user data. These temporary files and directories even dispose of themselves after use by default. For more information, see (GH-98397).

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

2D: Change how multi selection scale is applied to canvas item (GH-99506).
2D: Ensure primitive meshes are created before connected to changed signal (GH-99740).
3D: Add ShadowCastingSetting to MeshLibrary / GridMap items (GH-85443).
3D: Add CollisionShape3D custom debug colors (GH-90644).
3D: Add Camera3D preview in Inspector (GH-90778).
3D: Allow tool scripts to alter transform of Node3DEditorViewport camera (GH-93503).
3D: Fix mesh corruption of CSG by using elalish/manifold (GH-94321).
3D: Adjust VoxelGI gizmo opacity (GH-99969).
Animation: Add persistent folding to Animation Library Editor (GH-86481).
Animation: Fix crash when re-importing model with AnimationPlayer panel open and node selected (GH-95795).
Animation: Add RetargetModifier3D for realtime retarget to keep original rest (GH-97824).
Animation: Prioritize proximity to green arrow when selecting overlapping transitions in AnimationNodeStateMachine (GH-98401).
Audio: Add runtime file loading to AudioStreamWAV (GH-93831).
Audio: Fix AudioStreamPlayer2D/3D’s get_playback_position returning 0 right after calling seek (GH-99759).
C#: Preserve no-hint behavior for unmarshallable generics in dictionaries (GH-99485).
Core: RegEx: Fix handling of unset/unknown capture groups (GH-73973).
Core: FileAccess: Return error codes from store_* methods (GH-78289).
Core: Avoid duplicating signals from scene instances into packed scenes (GH-97303).
Core: Make loading translations from threads safe (GH-99527).
Core: Do not generate *.uid files for JSON, certificates, and translations (GH-99540).
Core: Convert line breaks to \n and strip line break from the end of string returned by OS::read_string_from_stdin/OS::get_stdin_string (GH-99542).
Core: Fix OS::has_feature() skipping custom features (GH-99864).
Core: Add temp utilities (alias OS::get_temp_dir(), FileAccess::create_temp(), and DirAccess::create_temp()) (GH-98397).
Editor: Extend Curve to allow for domains outside of [0, 1] (GH-67857).
Editor: Implement zooming and panning in the profiler (GH-76055).
Editor: Fix jumping to editor help does not scroll correctly sometimes (GH-96449).
Editor: Show file names in remove files confirmation dialog (GH-98539).
Editor: Add editor setting to stop the bottom panel from switching to the Stack Trace (GH-98657).
Editor: Don’t tint editor bottom panel icons when hovered or pressed (GH-98765).
Editor: Add copy button to toast notification (GH-98778).
Editor: Enable editing of controls inside viewports in editor (GH-99401).
Editor: Improve appearance of external links in built-in docs (GH-99480).
Editor: Make the alt selection menu available for all modes (GH-99795).
Export: Ensure excluded GDExtension files are not included in extension_list.cfg (GH-97216).
Export: Write text server data from memory, instead of using temporary file (GH-99164).
GDExtension: Register Engine, OS, ProjectSettings, and Time singletons in time for INITIZATION_LEVEL_CORE (GH-98862).
GDExtension: Support extension icons in ScriptCreateDialog (GH-98914).
GDScript: Fix crash when division by zero/modulo by zero happen on vectors (GH-95172).
GDScript: Improve GDScript autocompletion for methods (GH-99102).
GDScript: LSP: Fix spec violations that break the VSCode outline (GH-99295).
GDScript: Core: Fix built-in enum constant bindings (GH-99424).
GDScript: Support tracking multiple analyzer and runtime errors in tests (GH-99490).
GUI: Add a Viewport method to get automatically computed 2D stretch transform (GH-80965).
GUI: Make FileDialog filtering case insensitive (GH-85789).
GUI: Make TextEdit autocompletion replace word unless Shift is held (GH-90723).
GUI: Reshape and update button on oversampling change (GH-95511).
GUI: Prevent infinite recursion in first _draw (GH-97328).
GUI: Add theme type variations for secondary Trees and ItemLists (GH-97884).
GUI: RTL: Add support for vertical alignment (GH-97963).
GUI: Introduce a SubViewportContainer config for drag-and-drop target locations (GH-99270, GH-99691).
GUI: Fix SVG font rendering (GH-99459).
GUI: Add tooltip support to meta/url tag (GH-99481).
Import: Generate thumbnails on imported scenes (GH-96544).
Import: Blend file import: Don’t keep original files when not unpacking them (GH-96782).
Import: Betsy: Add BC3 and BC5 support (GH-99537).
Multiplayer: Fix UID support in MultiplayerSpawner (GH-99712).
Navigation: Improve NavMeshQueries3D::polygons_get_closest_point_info performance (GH-97928).
Navigation: Make NavMap objects request sync only on demand (GH-99646).
Network: Add half precision floating point support to StreamPeer and FileAccess (GH-97716).
Network: Allow disabling UPNP implementation on the Web (GH-99597).
Physics: Fix GodotSpace3D::test_body_motion() not setting local_shape (GH-99901).
Porting: Android: Fix immersive mode issue (GH-98917).
Porting: macOS: Change the shortcut for Align Transform with View (GH-94026).
Porting: Unix: Don’t create world-writable files when safe save is enabled (GH-96399).
Porting: Windows: Fix restoring fullscreen window (GH-98631).
Porting: Windows: Fix Inspector tooltips blinking on Windows (GH-99988).
Porting: Windows: Improve frame pacing by busy waiting as needed (GH-99833).
Porting: Implement DisplayServer.beep (GH-99371).
Rendering: Optimize RenderForwardClustered::_setup_render_pass_uniform_set by reducing Vector allocations (GH-94368).
Rendering: Deprecate the pointless unsafe threading model for rendering (GH-98383).
Rendering: Automatically resolve initial and final action for draw lists (GH-98670).
Rendering: Fix occlusion culling for double builds by enforcing float conversion for Embree (GH-98770).
Rendering: Mask out shadows on CanvasItems that don’t have a matching item_shadow_mask (GH-98835).
Rendering: Add lightmap bake cancelling (GH-99483).
Rendering: Add VoxelGI bake cancelling and progress UI improvement (GH-99562).
Rendering: Fix ReflectionProbe AABB (GH-99802).
Shaders: Allow SCREEN_UV to be used in light function of spatial shader (GH-94981).
Shaders: VisualShader: Add LinearToSRGB and SRGBToLinear to ColorFunc node (GH-97388).

Changelog

114 contributors submitted 259 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev5 snapshot.

This release is built from commit 1f47e4c4e.

Downloads

Download Godot 4.4 dev6

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Here are some known regressions introduced in this snapshot:

Occlusion culling randomly occluding things completely in the open (GH-10032).
- A pull request is already open to fix this in the next dev snapshot (GH-100060).
Error “Manifold creation from mesh failed” with Plane and Quad shapes, which do not get rendered (GH-100014).
- Planes and Quads cannot be used with CSG, and just seemed to be usable previously. We’ll improve the usability so they cannot be selected for CSGMesh3D. Instead, use MeshInstance3D to place Planes and Quads.

Bug reports

Support

Beyond #100000: You're breathtaking!

2024-12-04T19:00:00+00:00

This blog post was originally posted on GH-100000.

It’s been over 10 years now that Godot has been developed in the open, with code contributions from 2,800 users.

The total count of people who helped build Godot is actually far greater, as it should include documentation writers, testers, bug reporters, translators, moderators, content creators, users doing community support or talking at events, folks making games that credit Godot visibly, everyone supporting the project financially, and many other types of contributions which I can’t keep enumerating.

All these people brought Juan and Ariel’s little-engine-that-could from this:

Screenshot of the isometric 2D demo in Godot 1.0.

To this:

Screenshot of PVKK: Planetenverteidigungskanonenkommandant in Godot 4.3.

That’s no small achievement, so I encourage all contributors to take a minute to contemplate the progress that we’ve made together over this journey so far!

Amidst the daily churn of fixing issues, reviewing PRs, making releases, etc., it’s important to remind ourselves of where we are, and how we got there.

GIF of Cozy Space Survivors where asteroids form the word “GO♥DOT”.

Some stats about Godot usage on GitHub

Between our usual traditions of either making silly jokes or sharing some inspiring stats for round issue numbers, I picked the latter for this 100,000th issue¹, and wanted to look a bit closer at our issue and PR numbers over time.

A lot of people coming to Godot’s repository to see over 10,000 open issues and 3,000 open PRs might rightfully wonder whether this is normal, or a sign of a maintenance issue. I will make the case that it is a bit of both :)

Issues

Visualization from OSS Insight showing issue count over time, see the interactive version.

The two accumulated curves show the total number of issues created over the lifetime of the repository (topmost curve), and the subset of those which have been closed (as fixed or invalid). The difference between the two curves represents the number of issues still open at a given point in time - currently exactly 11,000, out of 53,648 issues total, so roughly 20%.

This is a fairly normal percentage of yet-unresolved issues in software projects of this scale, but it can definitely be better.

I annotated the graph with some key events of Godot’s development which match peaks in either reported bugs (usually at the start of a beta phase, or shortly after a stable release), or closed issues (when we do a “spring cleaning” going through old issues to check if they are still reproducible in a newly released Godot version). You can see notably two big peaks of closed issues around the 3.2 release, when we had a coordinated effort from maintainers to go through the whole backlog and ask reporters to confirm whether their issues were still valid, or had been fixed. This reduced the percentage of open issues from 29% to 19%, and it’s been mostly stable since, with minor fluctuations.

We are preparing a new “spring cleaning” to properly reassess a lot of the old issues which have been opened before the 4.0 release, or in the early days of 4.0 or 4.1, and may no longer be relevant nowadays with 4.3 and soon 4.4 beta.

As the volume of issues keeps increasing steadily, but the number of active bug triagers doesn’t really grow as fast, we are working on improving and documenting our workflows so that we can:

Onboard new volunteers to help triage new and old issues;
Spread the workload and be more consistent with our issue triage;
Be confident that while doing so, we do increase the quality of our open issues, which isn’t something that can be easily tracked in numbers.

We will share more details here and on the Godot blog when this process is ready to welcome new volunteers.

In the meantime, you can already do some simple things which help greatly the existing bug triage team:

Regularly re-assess your own issues (you can bookmark that URL). Make sure that they are reproducible in the latest stable release and dev snapshots, and that there is a minimal reproduction project that contributors can use to reproduce and fix the issue. If your issue is no longer relevant, please close it with a comment explaining why.
Feel free to apply the same process to other people’s issues that you stumble upon, especially if their last update was a long time ago. In this case you can’t close issues yourself, but you can suggest it by commenting that the issue is no longer reproducible in the version you tested. Bug triagers will get a notification and can double check.

Pull Requests

Visualization from OSS Insight showing pull request count over time, see the interactive version.

I didn’t annotate this one, but a few takeaways:

Godot gets almost the same number of new pull requests per month as new issues, roughly 600 of each per month (that’s 20 PRs and 20 issues per day).
The PR volume increased a lot over the lifetime of the project to culminate at over 700 PRs per month at the end of the 4.0 development. Since then, as the Godot userbase grew a lot and we are more careful with compatibility and API design, reviews can take a bit longer and the total monthly volume seems to have plateaued around 500-600. That’s still plenty enough for a fairly small group of reviewers.
Someone should plot this data with relative percentages, but it seems like the size/complexity of pull requests is slightly increasing recently. Whether that trend gets confirmed or not, I can attest that reviewing 600 PRs per month is hard, and that we need more help for interested contributors and users to both test and review the PRs that get opened on a daily basis.

That’s all for now, I was already way too long and verbose while drafting this at the last minute to (try to) snatch the 100,000th issue number ;)

Aside from showing some cool numbers, I mostly want to convey that we are well aware that we have a significant backlog, though it’s not as dire as it might look from the outside.

To deal with it, we need better triage and review processes (which we are designing now), more volunteers involved in these processes, but also importantly more funding. Volunteer contributors do a ton of work, but many critical parts of the workflow depend on a few paid contractors, and we need to grow that group to better manage the increasing scale of the project.

I’ll make a quick note that 100,000 is the combined number of issues and PRs, which share the same index system on GitHub.

At the time of writing, we’ve actually had 53,648 issues and 45,213 PRs created. Astute minds will notice that the sum is not 100,000; the difference comes from spam issues or PRs which have been deleted by GitHub. ↩

Godot Foundation Update December 2024

2024-12-02T17:00:00+00:00

The Foundation has been working on a number of things behind the scenes that are important for the organization and for the Godot ecosystem more broadly. We wanted to take the chance to highlight a few of them in this post.

Key policies and procedures

The Foundation was formed in August 2022, but we only began operating in a full capacity in July 2023. We initially adopted the member project policies of the Software Freedom Conservancy. Doing so allowed us to operate exactly as we had when we were a member project of the SFC, and maintain very high standards.

In September, we adopted a modified version of those policies that is more specific to our organization. You can read the updated version on the Godot Foundation website.

We are very happy with the policies and we hope you are too. They hold us to a very high standard and ensure that the Foundation will always operate in a way that supports Godot.

Contractors

The Foundation currently has 10 contractors working on the engine directly (6 full time, 4 part time) and 3 contractors working on administration and infrastructure.

This is the most contractors we have had at once, and even so, we feel understaffed as there is always more work that needs to be done than we can do. Accordingly, we would like to continue hiring once funding allows for it.

Upcoming projects

The Foundation is working on 4 major projects in addition to working on Godot itself:

An official asset store
An official job board on the Godot website
A public project priorities page
A public trademark policy

Asset store

We have been working towards an initial version of the asset store for a while now. It has taken us some time to get the legal aspects into place and a design agreed upon.

We expect to have an early access version of the site up and running this month and we will begin inviting testers to help us polish it and get it ready for a full release sometime in 2025.

Job board

We aim to have a place for people to post that are looking to hire Godot developers to add to their game team or Godot contributors to fix high priority bugs that may be impacting your team.

In addition to a job board, we will be curating a list of service providers who have shown that they offer services in the Godot ecosystem to make it easy to find someone to contract with if you need support or any other services.

Much of the foundational work for this has been finished, but it will likely be released after the asset store so we can focus our efforts more on that first.

Project priorities

Soon we will be adding a project priorities page to our website to give the community more clarity on the direction of development.

We have avoided providing a roadmap as we don’t want to promise more than we can deliver, or put too much pressure on volunteer contributors. However, the Godot Project maintainers have agreed that it is time to at least write down what the largest tasks are that we are working towards. This won’t be like a traditional roadmap where we have specific tasks with expected dates. However, we believe it will answer a lot of questions that the community has about the future of the project.

Trademark policy

We registered the Godot trademark and the Godot logo trademark while still a member project of the SFC. Last year, the SFC granted the Godot Foundation ownership over the trademarks. Now we need to have a public policy that says how and when others can use the trademarks to protect them.

We are working with our lawyers to craft a policy that is fair to existing users, as permissive as possible, and still able to protect our trademark.

We will have a blog post soon with more information.

The Foundation’s role in the project

We also wanted to take this chance to muse about the Foundation’s role in the project. In particular, we want to contrast the size of the Foundation with the size of the Godot project contributor pool. As explained above, the Foundation currently hires 13 contractors to work on Godot, while the total number of contributors to Godot is over 2,500 (the 4.3 release alone had over 500 contributors)! This large group of contributors is the reason why Godot is able to improve so quickly and do so much for a fraction of the funding that the other large engines have.

The Foundation (meaning the Board of Directors and the people hired by the Foundation) does not determine the priorities of the project in a top-down way. In other words, the Foundation does not dictate to individual volunteers what they should work on. Instead, it influences the project implicitly by making hiring decisions and hiring people for specific tasks that aren’t being done by the community.

Ultimately, it is the Godot community that deserves the most credit for the growth and development of Godot. While we hope to see the Foundation grow and take on a stronger role in the project, it should be seen as a central pillar of the project that volunteers can rally around. Donating to the Foundation is one avenue to contribute, but there are many more and Godot needs contribution in all areas in order to continue growing at this pace. Please consider contributing however you are able!

Support

Godot is a non-profit, open source game engine developed by hundreds of contributors in their free time, as well as a handful of part or full-time developers hired thanks to generous donations from the Godot community. A big thank you to everyone who has contributed their time or their financial support to the project!

Statement on GodLoader malware loader

2024-11-28T11:00:00+00:00

Security researchers at Check Point Research have published a report about GodLoader, a malware loader using Godot as its runtime to execute malicious code and infect unaware users with known malware. Based on the report, affected users thought they were downloading and executing cracks for paid software, but instead executed the malware loader.

As the report states, the vulnerability is not specific to Godot. The Godot Engine is a programming system with a scripting language. It is akin to, for instance, the Python and Ruby runtimes. It is possible to write malicious programs in any programming language. We do not believe that Godot is particularly more or less suited to do so than other such programs.

If you downloaded a Godot game or the editor from a reliable source, you don’t have to do anything. You are not at risk. We encourage people to only execute software from trusted sources – whether it’s written using Godot or any other programming system.

For some more technical details:

Godot does not register a file handler for .pck files. This means that a malicious actor always has to ship the Godot runtime (.exe file) together with a .pck file. The user will always have to unpack the runtime together with the .pck to the same location and then execute the runtime. There is no way for a malicious actor to create a “one click exploit”, barring other OS-level vulnerabilities. If such an OS-level vulnerability were used then Godot would not be a particularly attractive option due to the size of the runtime.

This is similar to writing malicious software in Python or Ruby, the malicious actor will have to ship a python.exe or ruby.exe together with their malicious program.

Good security practices

We would like to take this opportunity to remind users about some good security practices when it comes to downloading and executing software.

Only download and execute software (including game mods) from trusted sources:
- Official project website. Confirm it by checking the URL, and verify with a search engine that this seems to be the most frequently referenced website for this software.
- Trusted distribution platform: Steam, Epic Games Store, Windows Store, Google Play, Apple Store, etc.
- People you know, after confirming that they are who they claim to be if the communication is text-based (see below).
On Windows and macOS, verify that the executable is signed (and notarized, on macOS) by a trusted party.
Be wary of executing cracked software, which is a prime attack vector for malicious actors.
Be wary of executing software even from people you know, if you can’t confirm that their account hasn’t been compromised. A very common attack vector targeting specifically game developers is for Discord accounts to get hacked, and then malicious actors use them to send malicious downloads to their friends in private messages (“hey will you try my game?”). Make sure to confirm the identity of your contacts before executing such software.

Reporting security issues

We thank Check Point Research for following the security guidelines of responsible disclosure, which let us confirm that this attack vector, while unfortunate, is not specific to Godot and does not expose a vulnerability in the engine or for its users.

If you would like to report a security vulnerability or concern, please send an email to security@godotengine.org.

Dev snapshot: Godot 4.4 dev 5

2024-11-21T18:00:00+00:00

With GodotCon behind us and our developers recuperated, we’re thrilled to return to a more frequent release-cycle. It’s only been two weeks since we last checked in, yet there’s still so much to talk about! So buckle on in for a breakdown of what you can expect to see in 4.4 dev 5.

Many of the changes in this release are bug fixes that will be backported to Godot 4.3 and released in 4.3.1! So please test this release well so we can be confident with the changes and release 4.3.1 with them as soon as possible.

The cover illustration is from The Rise of the Golden Idol, a mystery game where you unravel the truth behind 20 cases of crime in the 1970s! It is developed by Color Gray Games. You can purchase the game on Steam and follow the developer on Twitter.

Highlights

In case you missed them, see the 4.4 dev 1, 4.4 dev 2, 4.4 dev 3, and 4.4 dev 4 release notes for an overview of some key features which were already in that snapshot, and are therefore still available for testing in dev 5.

Here are highlights of a few new features in dev 5 that you might find particularly exciting!

Universalize UID support

Previously, the UID format was not supported by all Resource types. This proved to be a pain point for users wishing to reference their scripts and other resources in a manner that’s path-agnostic. This, along with a need to refactor their scripts anytime these kinds of files were moved, put a significant duty of care on the end-user that shouldn’t have been necessary.

Starting with dev 5, this will no longer be your burden to bear! Thanks to a long-term effort from reduz, UIDs will now be applied universally in a way the engine can automatically track and account for. This is achieved via .uid files for the resource types that previously didn’t support them, functioning similarly to other metadata files that “track” a main file.

Note that, unlike metadata files, .uid files are strictly for the editor; the information is migrated to the uid database on export. Despite this, users using version control software should add these files, as they’re required to properly sync data (similar to .import files). For more information, see (GH-97352).

Favorite editor items

A common complaint we hear regarding the inspector is the potential for it to get cluttered. Namely, while there’s generally a wide selection of options available for a given class/script, users will usually only care about a particular subsection that suits them. To account for this, YeldhamDev brings us the long-awaited ability to pin one’s favorite properties in the inspector! Check out the implementation from PR (GH-97352) below:

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

2D: Add a way to know when a TileMapLayer’s cell is modified (GH-96188).
2D: Make possible to scale multiple nodes at once in the canvas editor (GH-98534).
3D: Fix Gridmap shortcut conflicts with 3D editor (GH-99170).
3D: Move GridMapEditor to bottom panel (GH-96922).
Animation: Add advance_on_start option to NodeAnimation to handle advance(0) for each NodeAnimation (GH-94372).
Animation: Fix key is deselected by changing key time in KeyEdit in FPS mode (GH-99319).
Animation: Implement LookAtModifier3D (GH-98446).
Animation: Sort blend shapes in the inspector by ID instead of alphabetically (GH-99231).
Audio: Allow waveform resize (GH-97551).
Audio: Fix AudioStreamWAV::save_to_wav adding extra ‘.wav’ to file if existing ext is not lower case (GH-98717).
Buildsystem: Bump minimum version of SCons to 4.0 & Python to 3.8 (GH-99134).
Core: Add typed dictionary support for binary serialization (GH-98120).
Core: Fix Freed Object booleanization (GH-93885).
Core: Fix MissingResource properties being stripped on save (GH-86600).
Core: Fix comparison of callables (GH-99078).
Core: Provide a reliable way to see original resources in a directory (GH-96590).
Dotnet: Add Codium support to C# external editors (GH-89051).
Dotnet: Implement [ExportToolButton] (GH-97894).
Editor: Add a pin toggle to prevent involuntary bottom editor switching (GH-98074).
Editor: Add fuzzy string matching to quick open search (GH-98278).
Editor: Highlight scripts used by current scene (GH-97041).
Editor: Optimize FileSystem Dock filtering (GH-95107).
Export: Add ability for PCK patches to remove files (GH-97356).
Export: Display project settings splash color on web export (GH-96625)
GDExtension: Fix method binds not saying if they are varargs (GH-99403).
GDExtension: Improve macOS library loading/export (GH-98809).
GDScript: Add support for print command in local (command line -d) debugger (GH-97218).
GUI: Fix tooltip appearing in old place, on movement (GH-96721).
Import: Allow passing UID to importer (GH-97363).
Import: Reload cached resources in runtime on file reimport (GH-98710).
Input: Revert “Fix InputEvent device id clash” and add a compatibility function (GH-99449).
Multiplayer: Handle scene UIDs in MultiplayerSpawner (GH-99137).
Navigation: Improve NavMeshGenerator2D::generator_bake_from_source_geometry_data performance (GH-98957).
Navigation: Reduce allocations for NavMap synchronisation (GH-98866).
Network: Split Unix/Windows IP implementation (GH-99026).
Network: Split Unix/Windows NetSocket implementation (GH-98969).
Plugin: Make the method selector dialog available via EditorInterface (GH-98859).
Rendering: Add multimesh_get_buffer_rd_rid method to RenderingServer (GH-98788).
Rendering: Ensure shadow material and mesh are not used with wireframe mode (GH-98683).
Rendering: Normalize normal, tangent, and binormal before interpolating in the mobile renderer to avoid precision errors on heavily scaled meshes (GH-99163).
Rendering: Reduce shader permutations in the compatibility backend (GH-87558).
Shaders: Add renderer state defines to shader preprocessor (GH-98549).
Shaders: Add swap connection option to visual shader graph (GH-99177).
XR: Fix pose recenter signal to be omitted properly (GH-99159).

Changelog

116 contributors submitted 265 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev4 snapshot.

This release is built from commit 9e609843.

Downloads

Download Godot 4.4 dev5

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

Support

GodotCon 24: Berlin Edition

2024-11-13T18:30:00+00:00

📋 Feedback form for visitors 🎤 Talk & workshop recordings 🫙 Jam games

Variety was the name of the game this year. GodotCon keeps going around the globe and adds more activities to the program: the event team made up of volunteers and Godot Foundation staff put a lot work into making this more than a mere meetup occasion for the ever-growing community forming around the Godot Engine.

Judging by the smiley pictures taken all around the Silent Green venue, and the excited chatter about what the next installments might bring to the table, we seem to have hit the sweet spot for our 574 attendees. For those of you that couldn’t be there yourself - considering both ticket batches sold out within an hour - join us on a retrospective walk through GodotCon, highlighting all the wonderful speakers, exhibitors, and sponsors that made this event possible.

GodotCon 2024 wouldn’t have been possible without the generosity of our sponsors, who enabled us to bring this event to life.

Critical Reflex

Having a publisher with experience in Godot on-board was as exciting for us as it seemed for the audience of “Indie Publishing 101” by their business developer Daniel. Additionally, you might have spotted the goodie bags they provided us.

🔗 criticalreflex.com

Endless Foundation

“Block Coding: Making Godot Accessible to Learners Everywhere” was another well-visited talk on the agenda, as was the booth of the biggest exhibitor team onsite. Their tech demonstration drew in fellow educators as well as curious game developers looking to contribute.

🔗 endlessos.org

W4 Games

Port your Godot games to console with ease! The company founded by Godot Engine veterans explained “W4’s role in the Godot Ecosystem” on stage and let you playtest their products and talk business at their busy booth.

🔗 w4games.com

Poki

The provider of free online games also has shown interest in Godot before and is hoping to expand their selection with your projects. We talked with them about improving Godot for the Web together; let’s see what the future might bring!

🔗 poki.com

AWS

After demonstrating “How to quick start a Godot Engine game on AWS”, the cloud provider team spent time answering questions on the exhibition floor.

🔗 aws.amazon.com

If you or your company are interested in supporting the next edition of GodotCon, we’d love to hear from you!
Please reach out to us at godotcon@godotengine.org.

Game exhibition

For the first time ever, we tried curating a selection of projects ahead of time and invited game development teams to a showcase on the venue floors. Decorated booths and sometimes even goodies caught the eyes of many attendees, and provided the exhibitors with valuable playtest information as well as wishlists. Some told us this was the first event they participated in with their project!

Exhibitor list:

Activities

What do you do at a conference, besides watching talks, browsing through the exhibition, or doing business? Have some fun and get to know other attendees in a casual way, of course.

This is exactly what we aimed to facilitate with our onsite activities, especially the sticker challenge tying them all together (since many of you asked: the stickers were designed by community artist Tibo). From networking bingo to graffiti canvas, we saw many people striking up conversations with strangers or having a great time with friends.

One of the most popular activities turned out to be the One PC Jam (taking place at three laptops concurrently) where the conference attendees created a jam game over the course of two days. The twist: everyone only was granted one hour on the project, before having to concede their seat to the next person. This resulted in three separate, actually playable games, which you can find on our GodotCon itch.io site.

Talks and workshops

The Godot community once again came through and submitted more interesting talks than we could fit on the program - resulting in us repurposing the admittedly rather small workshop room to squeeze some more of the talented speakers in. Luckily, we also invited a camera crew onsite, that took great care recording both the workshops and two talk tracks, for you to enjoy on the Godot Engine YouTube channel - some of them already available, the rest being edited as you read this blog post.

🔗 YouTube Playlist

Feedback

Considering the new additions we introduced to the event concept, and to learn from your experiences as visitors in general, we would appreciate it if you took the time to fill out this feedback survey we prepared. It should only take a few minutes.

Thank you!

And that concludes our tour through GodotCon 24. Hope you had fun reminiscing with us!

If you want to be notified about our next one, sign up to our mailing list and be the first to know:

🌐 https://conference.godotengine.org/

👋 See you next year!

Dev snapshot: Godot 4.4 dev 4

2024-11-08T12:00:00+00:00

We are back roughly a month after the release of dev3 to bring you a host of new improvements. Many of our developers traveled to Germany in October for GodotCon and the yearly Godot contributor meeting. There they spent two days discussing some of the biggest technical challenges and puzzling out solutions.

The cover illustration is from Unrailed 2: Back on Track, a chaotic co-op railroad construction game where you build your track across procedurally generated worlds! It is developed by Indoor Astronaut. You can purchase the game in early access on Steam and follow the developer on Twitter.

Highlights

In case you missed them, see the 4.4 dev 1, dev2, and dev 3 release notes for an overview of some key features which were already in that snapshot, and are therefore still available for testing in dev 3.

Here are a few highlights that you might find particularly exciting!

Interactive in-game editing

One of the most requested features is the ability to debug the running game from within the editor including pausing the game, clicking on elements within the scene, and embedding the running game window inside the editor. Dev4 comes with the first two of these workflows thanks to the contribution from YeldhamDev of Lone Wolf Technology & W4 Games, users are now able to explore their project’s world freely!

The actual embedding of the game window into the editor will come later in a subsequent PR.

Check out the PR (GH-97257) and the video below to see exactly what this change enables.

Use collision detection ray to reposition an object already in the scene

ryevdokimov added object snapping for placing 3D objects in the editor (GH-96740).

This is not a drill, see below.

Ubershaders and pipeline pre-compilation (and dedicated transfer queues)

This change combines 2 huge improvements (GH-90400):

Ubershaders: a technique that allows us to completely avoid shader stutter when objects are viewed in a scene for the first time
Dedicated transfer queues: by relying on special hardware functions we can dramatically improve the load time for scenes containing many graphics assets like meshes and textures.

Thanks to DarioSamo for months of hard work on this. The implementation of Ubershaders is something that took a lot of design and implementation to get right, but the end result is something we are very happy with.

“Ubershaders” are a version of each shader that contains all features and are compiled at load time. We pair the ubershader with the ability to compile specialized shader pipelines in the background. This way when we draw a new object, instead of freezing and waiting for the pipeline to compile, we fallback on the ubershader and compile the specialized shader in the background.

Most games will notice the improvement from ubershaders without any content changes. However, there are certain cases where the ubershader won’t work and some content changes will be needed to avoid shader stutter. However, the workarounds for avoiding shader stutter are now very simple and are well documented already in the official docs.

Taking advantage of the new ubershader infrastructure, we can now optimize our shaders by creating specialized variants that skip unused pathways. We have already begin doing so to optimize our existing shaders (GH-98825).

Add Shadow Caster Mask property to Light3D

This long awaited improvement from EMBYRDEV allows users to apply a mask on Light3Ds to select what rendering layers will be considered when casting shadows (GH-85338). Previously it was only possible to disable shadows from a GeometryInstance (for all Light3Ds) or a Light3D (for all GeometryInstances). This allows much more fine-grained control that allows users to further optimize dynamic lights and control where shadows appear in their games.

Always add decimal when converting float to string

Currently when printing float values Godot trims trailing .0s as they are technically unnecessary. However, this could lead to issues for users who need to distinguish between floating point numbers and integers. KoBeWi has now changed the behavior when floats are converted to strings to always add the decimal number, even if it would be .0. This makes floats always recognizable when they are converted to strings (GH-47502).

This change in behavior may break your project if you are relying on the current serialization behavior. If this change breaks your project, please let us know by opening an issue on GitHub.

# Before:
var a: float = 1.0
print(a)
# Prints 1

# After:
var a: float = 1.0
print(a)
# Prints 1.0

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

2D: Revert unintentional rounding change when 2D transform snapping (GH-98195).
Animation: Fix error when stopping empty animation player (GH-97760).
Audio: Expose some AudioStreamPlayback methods (namely mix_audio()) (GH-86539).
Buildsystem: CI: Add MinGW/GCC build to Windows GHA (GH-97446).
Core: Implement array based hash map AHashMap (GH-92554).
Core: Expose Geometry2D.bresenham_line() method (GH-74714).
Core: Add Object support for String.format (GH-65962).
Dotnet: Change generated On{SignalName} to EmitSignal{SignalName} (GH-97588).
Dotnet: Generate ReadOnlySpan<T> Overloads for GodotSharp APIs (GH-96329).
Editor: Improve UI of sun angle in the sun/preview env popup (GH-97747).
Editor: Add submenu support to EditorContextMenuPlugin (GH-97292).
Editor: Improve display for lightmap probes in the editor (GH-83863).
Editor: Add missing audio bus button styles #(GH-93443).
Editor: Add Markdown syntax highlighting to the script editor (GH-78312).
GDExtension: Fix loss of gdextension on editor startup (GH-98041).
GDScript: GDScript: Fix cached parser error when using typed Dictionaries (GH-98400).
GDScript: GDScript: Fix annotation parsing adding new annotation entries (GH-98146).
GUI: Add hover state to Tree items display (GH-88530).
GUI: Handle scroll events in RichtTextLabel (GH-97730).
Import: Rewrite index optimization code for maximum efficiency (GH-98801).
Import: LOD: Remove “Raycast Normals” and associated “Normal Split Angle” settings (GH-98620).
Import: Betsy: Implement BC4 compression (GH-97295).
Import: Emit filesystem_changed only once per frame (GH-98584).
Navigation: Optimize some parts of NavMap::sync (GH-90182).
Porting: Implement native file picker support for Android (GH-98350).
Porting: Implement has_hardware_keyboard method for Android and iOS (GH-97743).
Rendering: Fix various issues and minor performance optimisations in 2D renderer (GH-98652).
Rendering: Fix volumetric fog artifacts when inside the fog (GH-86103).
Rendering: Fix updating dynamic objects in LightmapGI (GH-97925).
Rendering: Add draw indirect to Rendering Device (GH-97247).
Rendering: Add Swappy & Pre-Transformed Swapchain (GH-96439).
Shaders: Implement instance uniforms in Compatibility renderer (GH-96819).
Shaders: Implement custom function overloading in shading language (GH-92441).
XR: OpenXR: change bindings to ‘flatten’ source paths (GH-98163).
XR: Add support for external camera feed from external plugin on Android (GH-96705).

Changelog

131 contributors submitted 339 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev3 snapshot.

This release is built from commit 36e6207bb.

Downloads

Download Godot 4.4 dev4

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

Support

Dev snapshot: Godot 4.4 dev 3

2024-10-03T12:00:00+00:00

We are back with another big dev update with over 330 commits merged in the last few weeks! Contributors continue to work on amazing new things while we continue to merge our backlog of important features that missed the 4.3 cutoff. The combined result is a lot of great stuff compressed into a short amount of time.

The cover illustration is from Fogpiercer, a turn-based card battler where your deck is a train! It is developed in Godot 4.3 by Mad Cookies Studio. You can wishlist the game on Steam and follow the developers on Twitter.

Highlights

In case you missed them, see the 4.4 dev 1 and dev 2 release notes for an overview of some key features which were already in that snapshot, and are therefore still available for testing in dev 3.

Here are a few highlights that you might find particularly exciting!

`@export_tool_button` annotation

Being able to create a button in the inspector from tool scripts was a highly requested feature, and many contributors took it upon themselves to make it happen in GH-96290: new contributors jordi-star and Macksaur, and maintainers Ernest and Danil!

This new feature allows you to be even more expressive with the dev tooling that you can easily create with @tool scripts.

Let’s take a look at an example:

@tool
extends Sprite2D
# With a callable (could also be a local function).
@export_tool_button("Toot", "Callable")
var print_action = print.bind("toot")
# With a lambda.
@export_tool_button("Randomize Color", "ColorRect")
var color_action = func(): self_modulate = Color(randf(), randf(), randf())

Massively optimized scene startup for large projects

Work has not slowed down on improving the scene startup experience, still thanks to amazing contributions by Hilderin. This dev snapshot introduces a massive improvement to editor load speed for large projects (GH-95678). Large projects can expect up to a 3× speed improvement when loading the project and a similar speedup when doing any operations that scan the filesystem.

Vertex shading

This dev release re-introduces the long-awaited vertex shading option for materials (GH-83360), thanks to contributor ywmaa landing their second major feature in Godot, after export support for Blender Geometry Nodes. Vertex shading is used primarily to achieve an early PSX style and to optimize performance on older and lower-end devices.

You can enable vertex shading either from within an existing StandardMaterial3D, ORMMaterial3D, ShaderMaterial, or by force enabling it on all materials using the rendering/shading/overrides/force_vertex_shading project setting.

Add batching to RendererCanvasRenderRD

After tackling the Metal rendering backend merged in an earlier snapshot, Stuart took on another impressive rendering contribution: 2D batching!

Batching has been implemented in the Compatibility renderer since the release of 4.0. This release brings the same performance benefits to the other backends by implementing batching when using the Forward+ and Mobile backends (GH-92797). Now 2D performance is comparable between all backends.

Batching is a performance optimization that drastically reduces the number of draw calls in a scene. The benefits of batching will be particularly noticeable in scenes with a lot of text rendering or repeated sprites that share a texture (e.g. when using tilemaps or making a bullet hell).

We have further improvements planned for batching on the RD backends that should allow it to be even faster than the Compatibility backend. Stay tuned for updates in later dev releases!

Expression evaluator (REPL) in the debugger

The expression evaluator adds a new tab to the bottom panel that allows you to evaluate expressions using the local state of your scripts while stopped at a breakpoint. Many users are familiar with this workflow from other REPL debuggers.

This feature has been a work in progress for awhile and was recently finished and merged in (GH-97647), thank you to Oğuzhan, Erik, and Tomek for bringing it across the finish line.

Implement autostart for all profilers

A common complaint from users is that they need to go back to the editor once they start their game in order to enable the profiler. This made it hard to measure performance in the first few seconds of loading a scene and was an overall hassle for developers.

Hendrik introduced a checkbox that allows you to set the profiler to automatically start when you run the engine and capture valuable profiling data immediately (GH-96759).

Add markers to Animation

Markers allow you to create sub regions of an animation that can be jumped to, or looped without playing the entire animation.

Markers are even supported inside the Animation Tree, where you can easily select animation markers for looping or to begin playback.

For more details check out the pull request GH-91765, which was one of the first Godot contributions of ChocolaMint!

Linux camera support

Previously, Godot only supported accessing the device camera on macOS and iOS devices. pkowal1982’s long-running pull request GH-53666 was finally merged and adds support for the Linux platform, allowing developers to access connected cameras from within their game.

Fallback to OpenGL 3 if other rendering drivers are not supported

Currently when trying to run Godot with the Forward+ or Mobile backend on a device that doesn’t support Vulkan, D3D12, or Metal, the engine will provide the user with an OS alert notifying them that they don’t have support for the needed graphics API and they need to try again with the Compatibility backend. This alert has proven to be confusing for users and the process of opening the scene ends up being cumbersome.

Now with GH-97142, first contribution from SheepYhangCN, the engine will automatically fall back to using OpenGL (the Compatibility backend) when the other backends are not available. This should provide the smoothest possible experience for users on older devices.

Since the Compatibility backends can look different from the other backends, game developers may not want Godot to automatically fall back. In that case, they can disable the rendering/rendering_device/fallback_to_opengl3 project setting to avoid falling back, and users with OpenGL-only devices would then get notified that their hardware is not supported.

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

2D: Fix pink GradientTexture2D (GH-94744).
2D: Fix polygon node losing its UV toolbar (GH-96466).
3D: PathFollow3D update transform immediately by default (GH-96140).
Animation: Update AnimationPlayer in real-time when bezier curve properties or bezier editor changes (GH-96753).
Audio: Fix one frame overflow at the end of WAV files (GH-96768).
Audio: Use a LocalVector to store data to optimize AudioStreamMp3 (GH-97026).
Buildsystem: CI: Update clang-format pre-commit hook to 19.1.0 (GH-97483).
Core: Add callable support for find and rfind Array methods (GH-95449).
Core: Fix inability to use ResourceLoader in C# after threaded load in GDScript (GH-92888).
Core: Add translation domain (GH-95787).
Core: WorkerThreadPool: Revamp interaction with ScriptServer (GH-96959).
Core: StringName: Fix empty hash (GH-96586).
Dotnet: Generate strongly-typed method to raise signal events and fix event accessibility (GH-68233).
Editor: Fix MeshInstance3D gizmo redraw performance for PlaneMesh with larger subdiv value (GH-96934).
Editor: Fix error reopening non existing scene on startup (GH-97028).
GDExtension: GDExtension: Allow class names to be unicode (GH-96501).
GDScript: Fix issue with GDScript binary tokens being non-deterministic (GH-96855).
GDScript: Fix Dictionary.merge() type validation (GH-96864).
GDScript: Fix operator[] for typed dictionaries (GH-96797).
GUI: GraphEdit: Improve dotted pattern grid performance (GH-96910).
GUI: Fix TabContainer minimum size (GH-97132).
Import: Add BC1 compression support to Betsy (GH-95915).
Navigation: Fix AStar2D, AStar3D, AStarGrid2D from not returning a path when the destination is disabled/solid even with allow_partial_path option (GH-94246).
Physics: Move Godot Physics 2D into a module; add dummy 2D physics server (GH-95261).
Physics: Move Godot Physics 3D into a module; add dummy 3D physics server (GH-95252).
Physics: Add forgotten get_space() check in GodotArea3D::remove_soft_body_from_query() (GH-97130).
Porting: Fix project manager stealing focus on i3 (GH-96829).
Rendering: Use distance to AABB surface to calculate Mesh LOD instead of using supports (GH-92290).
Rendering: Fix BaseMaterial3D refracting objects located in front of the material (GH-93449).
Rendering: Fix incorrect Reinhard tonemap operator (GH-93324).
Rendering: Use temporal accumulation to improve the quality of shadows (GH-97428).
Rendering: Fix region_filter_clip_enabled to avoid sprite bleeding for interpolated sprite sheets (GH-97602).
Visual Shaders: Add vector operations to Remap node (GH-97314).
Thirdparty: mbedTLS: Enable TLS 1.3 support (GH-96394).
XR: Fix launching XR apps from the Android editor (GH-96868).

Changelog

136 contributors submitted 332 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev2 snapshot.

This release is built from commit f4af8201b.

Downloads

Download Godot 4.4 dev3

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

“Attempting to use an uninitialized RID” error is printed when opening the editor (GH-97694). This is a harmless error, and should have no noticeable impact on your project.

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

Support

Godot XR update - October 2024

2024-10-02T12:00:00+00:00

It has been a very busy year on the XR front and seeing we haven’t given a proper update for well over a year, it’s time to look back at what has happened since our last update post. We touched on some of these in the Godot 4.3 release blog but we’re doing a bit of a deep dive here.

We’re planning on publishing more articles about XR in the near future. We recently announced the XR editor but we have more news on the way!

Improvements in Godot’s XR architecture

A lot of work has gone into improving the XR implementation in Godot.

Improved frame timing logic

When OpenXR was originally implemented in Godot 3 there were limitations on the order in which certain actions took place. Most of the communication with OpenXR was tied into the rendering engine resulting in Godot relying more on predictive algorithms to position tracked entities such as controllers. Originally Godot 4 inherited this approach.

As part of the Godot 4.3 release much of this logic was redone to interface with OpenXR correctly. Godot now correctly informs OpenXR when it starts processing a new frame and obtains pose data for tracked entities with predicted positioning for the current frame.

Preparing to support rendering on a separate thread

As part of implementing the improved frame timing logic, we did a large cleanup of the XR code to make sure it runs properly when rendering happens on a separate thread. Especially for XR applications this brings us closer to ensuring a steady framerate, even on stand alone devices.

There is more work that needs to be done in Godot 4.4 to make this fully viable but the foundations are in place.

Standardisation for AR and passthrough

Passthrough is a mechanism where video cameras on a VR headset record the real world and present this real world view as the background inside of our HMD turning the headset into an AR device. Different headsets implement this feature in different ways and this caused difficulties for developers who were targeting multiple devices.

While passthrough allows some neat things not possible with optical AR devices, for most AR focussed application developers should not be tasked with writing different code to support all these devices.

We have thus standardized this approach through utilising OpenXRs environment blend modes and moving platforms specific code into the OpenXR vendors plugin.

Standardisation of hand, face and body tracking

Hand tracking has been supported in Godot for a long while now, however improvements have been made to ensure better cross platform support, including standardisation between OpenXR and WebXR. The OpenXRHand node has been deprecated, in favour of the new XRHandModifier3D node which is designed to work with any XR system - not just OpenXR.

Face tracking support has been added with face tracking data being sourced from several devices. Godot now supports the Unified Expressions standard for handling face tracking data.

Body tracking support has been added using Godots Humanoid Skeleton as a base which allows various body tracking devices to leverage Godots retargeting logic.

While these 3 systems have been implemented under the XR name, their use cases are not limited to XR. Already several plugins have been created using this system to bring in body tracking data from various body tracking solutions ranging from optical Mocap to full body tracking suits.

Improved WebXR support

WebXR support in Godot is seeing continuous improvement, most notably the addition of hand tracking support, but also support for MSAA and a number of smaller bug fixes and improvements. Our WebXR implementation now also supports AR applications.

Improved OpenGL support

While technically not specific to XR, several improvements to the compatibility renderer directly impact the ability to create XR experiences using Godot.

The new MSAA implementation in the compatibility renderer has support for OpenGL extensions specifically targeting TBDR GPUs found on modern standalone headsets. When available enabling MSAA 2x or 4x has a very low cost while providing worth while improvement in the visuals.

The new lightmapping capabilities of the compatibility renderer, where the Vulkan implementation is leveraged to bake the lightmaps, provides a viable solution for improved lighting on standalone XR hardware.

Improved foveated rendering support in the Vulkan engine

The compatibility renderer uses OpenXRs foveated rendering support directly but this comes with various limitations and is not applicable outside of OpenXR.

In the Vulkan renderer we have had Variable Rate Shading support for a while which allows foveated rendering to be applied in Godot without the same drawbacks.

In the latest release various improvements have been applied that provide more control over the density map used and allow for eye tracking to impact the density map and ensure quality rendering at the users focal point.

Collaboration between W4 Games & Meta

The past year saw W4 Games and Meta join forces to improve Godot’s support for the Quest line of devices.

Core functionality improvements

The team at W4 has worked closely together with several core Godot XR contributors to improve the core functionality in Godot, improving the experience not just for Meta Quest users, but also for other XR systems. Several of the items mentioned in the previous sections benefited greatly from the help provided here.

These improvements also include various rendering optimisations and fixes.

Enhanced passthrough and hand-tracking support

On top of the standardisation of passthrough and hand-tracking in Godot, support for many extra features Meta provides was implemented in the Godot OpenXR Vendors plugin.

For passthrough, this includes applying various filters to the passthrough imagery, like adjusting the brightness, contrast and saturation, mapping the colors to other values, or even projecting passthrough onto custom geometry, in order to bring only specific objects from the user’s physical environment into an otherwise VR experience. See the Meta Passthrough tutorial for more information.

For hand-tracking, developers can now access hand meshes, collision shapes for the hands, and do some simple gesture tracking, like detecting pinches between the user’s thumb and any of the other fingers. See the Meta Hand Tracking tutorial for the full details about these features.

Composition layer support

Composition layers are a standard feature in OpenXR, that allow developers to add floating “panels” (either flat or curved) that have 2D content rendered onto them from a Godot SubViewport.

The result of this approach is far sharper detail of the 2D content compared to applying this same content as a texture on a 3D mesh.

This is ideal for in game menus, media viewing, or heads up displays. Small text is especially more readable when using this technique.

W4 Games added both the core implementation and Meta-specific extensions, which allow applying further sharpening or supersampling, advanced alpha blending or marking particular composition layers as containing “secure content”. See the Meta Composition Layers tutorial for more information about these Meta-specific features.

Scene discovery and spatial anchors

These two closely related features are possibly the most exciting part of the work done so far. Meta’s Scene Discovery allows the Quest to scan your environment and provide your game with information about the real world.

This can allow you to place objects on your walls, on furniture, or have NPCs interact with the real environment.

Spatial anchors allow you to make this persistent. Create a spatial anchor that references a place on your wall, and you can show a virtual screen there anytime your user comes back to your application.

See the Meta Scene Manager and Meta Spatial Anchors tutorials for more information.

New/Improved platform support

PICO 4

Godot has had support for PICO headsets for while but in the past year improvements were made to this. PICO has fully adopted the official Khronos Android Loader for OpenXR and deprecated their custom loader. Godot fully supports the new approach.

HTC Focus 3 and XR Elite

HTC provided the team with HTC Vive XR Elite units allowing us to ensure Godot runs on HTC standalone devices. We’re also working together with HTC to improve the experience on these devices.

Magic Leap 2

Support for the Magic Leap ecosystem was recently added to the vendor plugin as well. Magic Leap stands apart from other standalone Android devices being an optical AR device and running AMD hardware. On these devices you need to use the Vulkan mobile renderer.

Qualcomm spaces

This is still under development, we’re supporting Qualcomm’s OpenXR runtime on the Lynx R1 but we’re looking into supporting more devices in this eco system. Watch this space.

Logitech MX Ink

Not a new headset, but a pheripheral, the MX ink is a positionally tracked stylus that can be used with a Meta Quest. Support was merged into master recently and this device will be supported in the upcoming Godot 4.4 release. We’re looking into supporting this in a future 4.3 patch release.

What’s next

Stay tuned for further blog posts focusing on XR as we start looking ahead and as new features become available.

Godot SDK Integrations

2024-09-24T14:30:00+00:00

Third party services SDKs and their circumstances

Developing and publishing games often involves relying on third-party services, middleware, or platforms. Numerous vendors offer commercial products like advertising networks, backend services, sound engines, user authentication, and more. These tools simplify the process of monetization, expanding player reach, storing data on servers, and performing other functions beyond what a game engine typically provides.

To facilitate integration, these vendors often supply SDKs tailored for specific game engines, allowing developers to easily install them and interact with their products.

Godot, while rapidly growing in popularity, is still relatively a newcomer. As such, while some vendors are beginning to support the engine, many others have not yet invested on it, given the necessary development and maintenance costs.

For some, this is due to the significant resources required (finding the right developers to hire to make the SDKs), while for others, it’s simply a matter of being unaware of Godot’s growing market or dealing with internal bureaucracy that slows down the process of supporting the engine.

As the Godot Foundation is committed to using donations solely for creating FOSS and prioritizing open standards, it does not allocate resources from the general pool of donations to integrate proprietary SDKs into the engine.

While officially incorporating monetization SDKs into Godot might not align with the project’s goals, for example, there is still a widely recognized need within the community for such support to help developers make a living. As there is a need for many other SDKs.

Community to the rescue

To tackle this challenge, many in the Godot community have taken matters into their own hands, developing proper integrations for third-party services. Talented developers have done an incredible job to bring the most popular services into Godot, enabling the community to publish games on their desired platforms using the necessary third-party tools.

However, this approach still presents several issues for the community:

Not everyone is committed to creating and maintaining a full SDK integration. Often, developers only implement the features they need for their specific game.
Developers may not have the time or inclination to support other users’ issues as long as their integration works for their project. Likewise, they may not continue developing the integration after their project has been published.
As a result this means that, over time, multiple forks of the same integration can be found on GitHub, maintained by different individuals who needed it at different times, leading to fragmentation.

Adding to this, some vendors who provide SDKs for other game engines have expressed interested in supporting Godot but are not ready to allocate internal resources to develop an integration due to costs or other constraints. They might be willing to donate their integration (or donate the money to do an integration) to the Godot Foundation and collaborate with the community.

While this is amazing, the Foundation doesn’t want to become responsible for maintaining such integrations using general funds once the specific donation runs out.

The Godot Engine Community SDK Integrations GitHub organization

After extensive discussions with the community and various vendors, the Godot Foundation has decided to maintain its stance on not directly developing SDKs. However, recognizing the need for a more organized approach, the Foundation has established an official centralized GitHub organization for hosting SDK integrations, thereby encouraging community contributions.

This organization eases the burden on developers who create their own SDK bindings, as they will now be able to accept contributions without bearing the sole responsibility for maintaining the integration. It also provides a clear and official platform for companies that wish to donate their SDK integrations, offering a centralized location for these contributions.

The new Godot SDK Integrations organization has its own GitHub page already. Developers who have been working on SDK integrations are invited to move their work here, if they desire so. You can join the new sdk-integrations channel to discuss this transfer.

Likewise, vendors interested in donating integrations for their first-party SDKs are also welcome to move them to this new organization, if they deem it preferable to hosting SDKs themselves. Please contact the Godot Foundation in order to make arrangements. Likewise, if you would like to finance the development of Godot integrations for your SDKs, the Godot Foundation can help facilitate contacts with trusted community maintainers or companies who can take on such work.

Please note that this organization is a public space for centralizing SDK integration efforts and collecting repositories. The Foundation will not manage or update the integrations, so ongoing development will depend on the community and vendor contributions. This initiative is intended to be a collective effort.

Contributing to the Godot SDK Integrations organization

As we mentioned, the Godot Foundation is hosting this new space, but doesn’t intend to spend its resources on maintaining it.

We are therefore calling for motivated community members to get in touch and help organize the structure of this new organization, and help support developers and vendors who want to provide new SDK integrations for Godot.

Aside from the actual work of developing and maintaining SDK integrations, we foresee the need for contributors with a production profile who can help write common contribution guidelines, instructions on how to “recruit” new maintainers, or generally ensure some quality and fitness for purpose of the various SDKs offered by and to the community.

For the time being, we are going to discuss and organize the work of this community organization on the #sdk-integrations channel of the Godot Contributors Chat. See you there!

Godot Rendering Priorities: September 2024

2024-09-23T15:45:00+00:00

It’s time again to update everyone on the activities of the rendering team. We have been hard at work fixing countless bugs and improving the renderer. Now that 4.3 is out, we have taken the chance to re-assess our priorities.

Get Involved

As a reminder, we are always in need of more help. The rendering team is very small and none of us are working on the renderer full-time. If you are interested in helping out, please consider joining the #rendering channel on chat.godotengine.org, joining the weekly meetings that place, or just opening a pull request!

In addition to the priorities listed here, you can get started contributing by fixing bugs. We have been categorizing bugs by complexity and priority in the new Rendering Issue triage project to make it easier for new contributors to discover bugs that need attention.

For a less organized overview on rendering priorities, you can also check out the 4.x Rendering Roadmap Github project. This project lists a lot of the long term tasks we would like to do that don’t fit nicely in bug reports or in the blog post format. If you are performance-minded, there are also plenty of potential performance optimizations described in that project.

Update on Previous Priorities and 4.3

The below are the priorities we identified in the last rendering priorities blog post. Some of these come from earlier blog posts as well. We are happy to report that almost all priorities from the previous posts are either finished, or ready to merge.

Background pipeline compilation + Proper multi-threading in the RenderingDevice (GH-90400) (Ready to merge)

This work was finished during the 4.3 dev cycle, but we deferred merging it to 4.4 because of its size and complexity. As a reminder, this PR implements the concept of an “ubershader” which is basically a version of the shader that contains all features and is compiled at load time. We pair the ubershader with the ability to compile specialized shader pipelines in the background. This way when we draw a new object, instead of freezing and waiting for the pipeline to compile, we fallback on the ubershader and compile the specialized shader in the background.

The early results are very promising. We are seeing reduced load times for large games as well as a reduction in shader pipeline compilation stutter when objects are seen for the first time. In fact, so far we are seeing no shader pipeline compilation stutters at run-time.

BUGS (in progress, always)

We fixed over 300 rendering related bugs in 4.3! We expect to fix a few hundred more in 4.4 :)

GL Compatibility renderer - 3D (Done)

We merged support for MSAA, LightmapGI (including baking), resolution scaling, glow, ReflectionProbes, post process adjustments and color correction in time for 4.3. At this point we consider the Compatibility renderer feature complete which means it now has all the features we planned for it when we first designed the renderer. We will continue adding some new features to achieve closer parity with the Mobile renderer, but new features will have less of a priority now.

D3D12 rendering driver (GH-70315) (Done)

This was merged early in the 4.3 release cycle, but was improved steadily throughout the release cycle. The D3D12 rendering driver is now available for widespread use. This is especially important for ARM64 Windows devices which don’t support OpenGL or Vulkan.

RenderingDeviceDriver refactor (GH-83452) (Done)

This was very important foundational work that has allowed us to simplify our rendering code and ease the future maintenance burden as we port to more rendering backends.

Acyclic render graph optimization (GH-84976) (Done)

As expected we merged the new Acyclic Render graph in 4.3. It significantly improved stability of the engine and resolved many hard to fix errors as well as moderately improved performance. To read more see the blog post.

Compositor Effects (Rendering Hooks) (GH-80214) (Done)

The new CompositorEffects API allows you to register callbacks that will be called in the middle of the rendering process. This lets you insert custom RenderingDevice commands in the middle of the render frame to customize rendering.

Right now the API is functional and exposes almost all internal render state so you can access all the intermediate information.

There is already an official demo so you can see how it works!

Metal rendering driver GH-88199 (Merged for 4.4)

This was a work in progress for much of the 4.3 release cycle and was finished slightly too late to include in 4.3. We merged it immediately for 4.4 so we can get widespread testing before release. It’s ready to try in 4.4-dev1 or later releases.

Metal enhances both performance and stability on Apple silicon devices. Please test it out and let us know if you run into any issues!

SDFGI refactor / HDDAGI (GH-86267) (In progress)

This is still a work in progress, but results are already quite good. Both performance and quality are better than SDFGI. Juan still has many ideas he wants to apply, so this work may continue for some time before it is ready.

New Priorities

We have completed almost all of our previous priorities, so now we get to set out new goals for the next few release cycles. Right now rendering contributors are most excited about two things:

Unblocking advanced users (especially for advanced VFX).
Improving performance.

These are rising to the top of the priority list as Godot becomes increasingly stable and the core user-experience feels quite good.

In particular the following are areas where you can expect to see changes in the next couple of releases. Bear in mind that we don’t have dedicated people working on any of these priorities. If you are interested in contributing, please consider contributing in one of these areas.

Performance

Performance is our number one priority. Now that Godot 4 has been out for over a year we are seeing more games releasing with Godot and users are starting to create bigger and higher-fidelity games. A natural consequence is that Godot’s renderer is starting to become a limiting factor for some users. Accordingly, it’s time for us to prioritize speed and to start implementing all the optimizations we have been putting off for later. You can find a list of a number of them listed in our 4.x Rendering Roadmap Github project.

Lightmapping improvements

We have had a lot of recurring requests to improve the quality and ease-of-use of LightmapGI. So far in 4.4 we have had a few major improvements (including bicubic sampling and a GPU-based texture compressor), but there is a lot of work still to do to ensure that baking and using LightmapGI is as seamless as possible.

Improving VFX workflow

Godot 4 has brought many quality of life features to particles like animated velocities and turbulence. However, particles still fall short in term of the broader workflow. VFX artists have to come up with their own structure for VFX (often script + animation player), figure out ways to check timings of their effects outside the engine (using screen capture software, for example), modify billboarding logic manually when moving to custom particle shaders, and so on. Despite improvements to the flexibility of the engine, artists still need advanced technical knowledge to do many things (like writing post-processing effects with the new CompositorEffect API).

We still have a lot of work to make Godot more accessible for people that are less interested in learning shaders or programming but still want juicy effects and immersive environments in their games.

If you want to help, there are plenty of things to do. From helping by gathering knowledge and evaluating solutions from multiple perspectives, to implementing agreed new features and bug fixes, finally, by joining us in the VFX Discord server.

Customized rendering

As Godot adoption increases, it is being used for more niche and specialized projects. However, we can’t provide everything that every user needs out of the box without becoming bloated, slow, and hard to use. So we need to provide more tools to customize rendering for projects that need more specialized effects. We started that process in 4.3 with the CompositorEffects API. We want to continue that effort by implementing more things in the Compositor API to allow users to control the order of rendering, override shader templates, etc.

Significantly improve screen-space effects (SSAO, SSIL, SSR, SSS)

All of the screen-space effects in Godot 4 were designed to run without using temporal reprojection for 2 reasons: 1) we didn’t want to force anyone to enable TAA in order to have a good looking game and 2) we didn’t properly calculate motion vectors for moving objects until Godot 4.2. Temporal reprojection allows us to make our effects much higher quality for a lower base performance cost.

Now that we have proper motion vectors, we want to provide versions of all the screen-space effects that take advantage of motion vectors to increase their quality and reduce performance cost.

We still won’t require TAA for any of the built-in effects as we want users to be able to choose whether to enable TAA or not, but we will likely use temporal reprojection by default for most of these effects.

This is an area that is really easy to contribute to if you are already familiar with rendering but want to get more familiar with Godot!

Support

Godot Editor on the Meta Horizon Store

2024-09-20T16:00:00+00:00

A year ago, I introduced the Android port of the Godot Editor. To date, it has had over 500K+ downloads on the Google Play store, and has enabled developers to create and develop Godot apps and games using Android tablets, foldables and phones. Since then we have been hard at work refining the experience, improving the development workflow via picture-in-picture (PiP) support, providing the ability to build and export Godot binaries, and improving the Editor performance and reliability.

Building on that foundation, and thanks to the Meta grants in support of that work and with help from W4 Games, I was able to complete the proof of concept started by Bastiaan Olij a couple years ago, to add support for using the Android editor in an XR context using Godot’s first class OpenXR integration!

Today, I am proud to release the first mobile XR port of the Godot Editor on Meta Quest devices!

https://www.meta.com/experiences/godot-game-engine/7713660705416473/

The Godot Editor is now available on the Horizon Store for Meta Quest 3 & Meta Quest Pro devices running Horizon OS version 69 or higher.

This is an early access version of the Godot Editor running natively on Meta Quest devices, enabling the creation and development of 2D, 3D and immersive XR apps and games directly on device without the need for an external computer.

As usual, this work is entirely free and open source, and already merged in Godot 4.4’s development branch (GH-96624). The version we publish on the Horizon Store can also be downloaded as an APK directly from the Godot website.

Features & Highlights

This version of the Godot Editor is a Hybrid App with the ability to open and transition back and forth between multiple panel (2D) and immersive (XR) windows. This is used to support the Editor features as described below.

Access to all Godot Engine capabilities

The Project Manager and the main Editor are rendered into panel windows as done on desktop and Android platforms. This makes the Editor readily available and usable either in the Home environment or overlaid onto a XR experience.

This approach allows us to deliver on a core tenet of this port which is to provide developers with a familiar development interface and access to the full set of capabilities and features that the Godot Editor provides on desktop and Android platforms. This includes access to the asset library, keyboard & mouse shortcuts, GDScript code editing / highlighting / completion support, access to the documentation, live scene editing, live script reloading support, live debugging, live profiling and many more!

Developing XR apps and games!

When developing a XR project, the immersive (XR) window is used for playtesting the project directly in the device as if it was a released app already. In that mode, the Editor panel can be summoned as an interactive overlay, which allows the developer to iterate, debug or profile the XR project while it’s running.

Support for exporting XR project binaries will be made available via a plugin.

Developing 2D and 3D apps and games!

Support for creating and developing 2D and 3D apps and games is available out of the box.

The experience is improved by leveraging the Android editor’s multi-panel capability which on Horizon OS allows to playtest the project in a new panel next to the Editor panel. This allows the Editor to remain accessible for iterating, debugging or profiling the project in real-time.

As with the Android editor, this version provides the ability to export 2D & 3D project binaries for all supported platforms.

Leveraging Horizon OS platform capabilities

Support for keyboard and mouse

External keyboard and mouse support allows developers to achieve the same levels of productivity as they do on desktop and laptop computers.

Virtual keyboard, touch controllers and direct touch are also supported for quick interactions, or when physical keyboard and mouse devices are not readily available.

Seamless multitasking

Introduced in Horizon OS v69, seamless multitasking enables the Editor panel to be visible and interactable while playtesting a XR project in virtual space.

This gives developers the ability to do live editing, debugging or profiling of XR projects in real-time, with the benefit of the depth cues and sense of scale unique to XR.

Panel Resizing & Theater View support

The Editor panel can be resized at will via drag and drop to fit the developer’s needs.

Using the Theater View button, developers can maximize the Editor panel and bring it front-and-center.

An important step for the XR & Game communities

Besides the technical achievements required to make this port feasible, we believe this is a significant milestone as it impacts the XR & Game community in a few but critical ways:

Turns the Meta Quest into a true Spatial Computer
- The Meta Quest gains the ability to create (and distribute) its own native apps without the need for a PC or laptop computer!
- Being able to run a full game engine on a mobile XR device should serve as inspiration for the type of apps that can be brought to the mobile XR ecosystem.
Grows the OpenXR ecosystem by providing a seed for building feature rich apps
- Godot Engine is a free and open-source software (FOSS) project which means that, in partnership with the Godot Foundation, OpenXR vendors can bring similar capabilities to their devices to grow the OpenXR ecosystem.
Reduces XR development friction
- XR development on PC and laptop devices has significant friction due to the need to switch back and forth between the development device and the target XR device (i.e. taking the headset off for development, putting back on for playtesting).
- This is not an issue when using the Godot Editor natively on XR devices since the development and target device are now the same device!
Lowers the barrier of entry for XR and Game development
- This version of the Godot Editor turns devices like the Meta Quest into an easily accessible development device with the ability to natively create, develop and export 2D, 3D or XR apps and games for all Godot-supported platforms.
Provides a more flexible development experience
- Developers can leverage the virtual space to gain more screen estate than a laptop could provide.
- The virtual floating panels provide a more flexible layout than a traditional desktop + multi-monitors setup.
- The ability to playtest and modify XR projects in-headset in real-time is a capability that can’t be replicated on PC and laptop computers.

Next Steps, Feedback & Contributions

This is only the beginning!

As mentioned in the previous section, we believe this is an important milestone for the XR, GameDev, and Open Source communities and we aim to build on this foundation to make Godot Engine a powerful, flexible and cross-platform tool for XR and Game development.

To that end, we welcome feedback and contributions from partners, members of the community and interested parties.

Dev snapshot: Godot 4.4 dev 2

2024-09-10T16:00:00+00:00

It’s barely been a month since the 4.3 release, but we had so many goodies queued up in the PR backlog that it’s been an early Christmas (or other gift-heavy holiday season) for contributors and testers.

We merged more than 200 PRs for the first dev snapshot, and just two weeks later, here we are with another batch of 350+ improvements for you to test and provide feedback on!

Jump to the Downloads section, and give it a spin right now, or continue reading to learn more about improvements in this release. You can also try the Web editor or the Android editor for this release. If you are interested in the latter, please request to join our testing group to get access to pre-release builds.

The cover illustration is from Megaloot, an addictive inventory management roguelike, developed in Godot 4.3 by axilirate and published by Ravenage Games. It was recently released on Steam with big success. You can follow the development on Twitter.

Highlights

In case you missed it, check the 4.4 dev 1 release notes for an overview of some key features which were already in that snapshot, and are therefore still available for testing in dev 2.

This new snapshot adds a lot more features which had been queued during the stabilization phase for Godot 4.3, and were thus ready for merging early on in the 4.4 development cycle.

Introducing…

Typed dictionaries!

Godot 4.0 introduced supported for typed arrays, but lacked support for typed dictionaries. This rapidly became one of the most requested features to add to the engine, and thanks to Thaddeus Crews, it is now implemented for Godot 4.4! This feature impacts the core engine, GDScript, and all other scripting languages when interfacing with Godot’s Dictionary type. You can now export typed dictionaries from scripts and benefit from a much improved Inspector UX to assign the right keys and values.

@export var typed_key_value: Dictionary[int, String] = { 1: "first value", 2: "second value", 3: "etc" }
@export var typed_key: Dictionary[int, Variant] = { 0: "any value", 10: 3.14, 100: null }
@export var typed_value: Dictionary[Variant, int] = { "any value": 0, 123: 456, null: -1 }

As a related improvement, support for StringName dictionary keys has also been optimized by Rune (GH-70096).

Error-less first project import

It is commonplace for Godot users using version control systems to exclude the .godot folder from their repositories, as it contains files which can be re-created by Godot the first time you edit the project.

One drawback of this system is that this first launch of the editor without .godot folder is typically quite noisy, with hundreds of errors spammed about missing resources, and various scripts failing to compile due to class_names not being known yet, addons not being registered yet, or yet unknown GDExtension classes.

Hilderin valiantly fought their way through this labyrinth of dependencies and multi-threading pitfalls, and brought us back the long awaited grail: error-less first import of projects, which should work without requiring an editor restart! This took a lot of effort with GH-92303 (for GDScript class_names, included in 4.3) and now GH-93972 (for GDExtensions) and GH-92667 (for plugins).

Moreover, with this newfound knowledge over the depths of EditorFileSystem, Hilderin also further improved that first project import experience to make the FileSystem dock more responsive while resources are being scanned (GH-93064).

Editor window state is now persistent

Another long-awaited quality of life improvement was implemented by Samuele Panzeri in GH-76085, adding support for keeping track of the editor window’s state (fullscreen/windowed mode, screen, size, position) to restore it across sessions. This should be particularly welcome for users with big monitors or multi-monitor setups who want a different default behavior than fullscreen on the first screen.

Visual shader goodies

A few popular quality of life improvements have been implemented by Yuri Rubinsky for the visual shader editor:

New material preview side dock (GH-94215):

Drag & drop of Mesh to create MeshEmitter in visual shaders (GH-93017):

Initial Android editor support for XR devices

Thanks to Godot’s unique feature of having an editor made with the engine itself, we’ve been able to bring the Godot editor to unconventional places, such as the web and Android devices. Building upon the latter, Fredia Huya-Kouadio completed the proof of concept started by Bastiaan Olij years ago, to add support for using the Android editor in an XR context using OpenXR (GH-96624)! You can test the current version by sideloading the APK, currently supported on Meta Quest 3 or Quest Pro.

And more!

There are too many exciting changes to list them all here, but here’s a curated selection:

2D: Implement multiple occlusion polygons within each TileSet occlusion layer (GH-93029).
2D: Enable SpriteFramesEditor to “guess” the amount of rows and columns of a sprite sheet when loading it for the first time (GH-95475).
3D: Add option to bake a mesh from animated skeleton pose (GH-85018).
3D: Add full customization of 3D navigation controls (GH-85331).
3D: Fix CSGShape3D debug collision shapes being visible in editor (GH-86699).
3D: Add ability to hide editor transform gizmo (GH-87793).
Animation: Update AnimationPlayer in real-time when keyframe properties change (GH-91599).
Animation: Optimize AnimationMixer blend process (GH-92838).
Animation: Allow keying properties when selecting multiple nodes (GH-92842).
Animation: Allow jumping to previous/next keyframe in animation player (GH-96013).
Animation: Use antialiased line drawing in animation Bezier editor (GH-96559).
Audio: ResourceImporterWAV: Enable QOA compression by default (GH-95815).
Audio: Fix leak when using audio samples instead of streams (GH-96572).
Buildsystem: Add support for compiling with VS clang-cl toolset (GH-92316).
Core: Ability to convert native engine types to JSON and back (GH-92656).
Core: Batch of fixes for WorkerThreadPool and ResourceLoader (GH-94169).
Core: WorkerThreadPool: Fix end-of-yield logic potentially leading to deadlocks (GH-96225).
Core: ResourceLoader: Add thread-aware resource changed mechanism (GH-96593).
Editor: Remember editor window mode, screen, size and position on restart (GH-76085).
Editor: Fix script overwriting with external editor (GH-96007).
Editor: Disable export template downloading in offline mode (GH-96331).
Editor: FileSystem: Add option to show some unsupported files in the dock (GH-96603).
Export: Allow adding custom export platforms using scripts / GDExtension (GH-90782).
Export: Android Editor: Add support for exporting platform binaries (GH-93526).
Export: macOS: Use per-architecture min. OS version for export (GH-95885).
Export: Reenable macOS .app export from Windows, add warnings about Unix permissions (GH-96669).
GDExtension: Allow ClassDB to create a Object without postinitialization for GDExtension (GH-91018).
GDExtension: Implement GDExtensionLoader concept (GH-91166).
GDExtension: Fix editor needs restart after adding GDExtensions (GH-93972).
GDScript: StringName Dictionary keys (GH-70096).
GDScript: Implement typed dictionaries (GH-78656).
GDScript: Autocompletion: Improve autocompletion for indices (GH-79378).
GDScript: Allow live reloading of built-in scripts (GH-94012).
GDScript: Autocompletion: Reintroduce enum options on assignment (GH-96326).
GUI: Implement fit content width in TextEdit (GH-83070).
GUI: Improve SpinBox interaction, split arrows, add theme attributes (GH-89265).
GUI: TextServer: 2x performance improvement by removing redundant lookups (GH-92575, GH-92581).
GUI: CodeEdit: Improve render time by 2x (GH-92865).
GUI: Improve Tree performance (GH-94748).
GUI: Fix StyleBoxFlat rectangles skewing independently (GH-96285).
Import: Import/export GLTF extras to node->meta and back (GH-86183).
Import: Fix FileSystem dock won’t show any file folders while loading large projects (GH-93064).
Import: Fix slow import when window is unfocused (GH-93953).
Import: Add 3D Skeleton Preview to Advanced Importer (GH-96094).
Import: Add “Use Node Type Suffixes” 3D scene import option (GH-96745).
Navigation: Improve pathfinding performance by using a heap to store traversable polygons (GH-85965).
Navigation: Improve AStarGrid2D performance when jumping is enabled (GH-93319).
Network: mbedTLS: Fix incorrect cert pinning with client_unsafe (GH-96172).
Network: Fix division by zero in network profiler (GH-96464).
Particles: Add cone angle control to particle emission ring shape (GH-91973).
Plugin: Fix addon requires editor restart to become functional (GH-92667).
Porting: Windows: Respect integrated GPU preference in Windows Settings (GH-93985).
Plugin: Add support for custom items to editor right-click context menus (GH-94582).
Porting: Windows: Always use absolute UNC paths and long path aware APIs, add “long path aware” flag to the application manifest (GH-91902).
Porting: Add support for non-blocking IO mode to OS.execute_with_pipe (GH-94434).
Porting: Android Editor: Add support for launching the Play window in PiP mode (GH-95700).
Porting: Android: Fix JavaClassWrapper so it actually works (GH-96182).
Rendering: Tune TAA disocclusion scale to avoid rejecting all samples during motion (GH-86809).
Rendering: Various fixes for transmittance effect (GH-93448).
Rendering: Avoid indexing instances without a base in scene cull phase (GH-95503).
Rendering: LightmapGI: Pack L1 SH coefficients for directional lightmaps (GH-96114).
Rendering: Metal: Enable for betsy and lightmapper modules in compatibility mode (GH-96351).
Rendering: Fix GPUParticles are not rendered for older AMD GPUs with OpenGL+Angle (GH-96413).
Rendering: Compatibility: Enable MSAA support for all non-web platforms (GH-96455).
Shaders: Allow drag & drop Mesh to create MeshEmitter in visual shaders (GH-93017).
Shaders: Add basic support to evaluate operator value in shader language (GH-93822).
Shaders: Add a material preview to visual shader editor (GH-94215).
Shaders: Add a context menu for the shader editor file list (GH-95738).
Thirdparty: mbedTLS: Update to 3.6.1, fixing regressions (GH-96385).
Thirdparty: thorvg: Update to 0.14.9, fixing regressions (GH-96658).
XR: Android editor: Improve support for XR projects (GH-96624).

Changelog

139 contributors submitted 376 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the previous 4.4-dev1 snapshot.

This release is built from commit 97ef3c837.

Downloads

Download Godot 4.4 dev2

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

Typed dictionaries: Different typed keys/values are wrongly allowed when using the [] operator (GH-96772). A fix is already in the pipeline for the next dev snapshot.
Windows: Detecting newly added assets (GH-96828), export variables (GH-96810), and the last modification dates for projects (GH-96812) is not working in this snapshot, due to a toolchain bug exposed by a recent FileAccess change on Windows. This was already fixed by GH-74830.

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

Support

Godot 3.6 finally released!

2024-09-09T11:00:00+00:00

After 2 years of development, Godot 3.6 is finally out and it comes fully packed with features and quality of life improvements! This includes 2D physics interpolation and hierarchical culling, and 3D mesh merging, level of detail, tighter shadow culling, ORM materials, and more.

While most of the development focus today is on 4.x releases, enthusiasts have been busy improving the 3.x branch: fixing bugs, optimizing and increasing reliability, providing quality of life improvements, and adding new features.

As well as providing support for existing 3.x games, Godot 3 has developed into a mature and stable codebase, which is well suited to development for low-end hardware. The development emphasis is on backward compatibility. Any new features are optional and we strive to not break or alter existing functionality.

Godot 3.6 is compatible with Godot 3.5.x projects and is a recommended upgrade for all 3.5.x users.

Please read on to learn about the most exciting additions in Godot 3.6, or click the links below to download the engine and jump straight into action!

Download Godot 3.6 stable

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Personal note from Rémi Verschelde (Project Maintainer): I started the work on 3.6 back when 4.0 was still in development, but it proved quite difficult to maintain so many branches in parallel. lawnjelly thankfully volunteered to take over the release management work for 3.6 and brought it to the finish line. Kudos to him, and timothyqiu who also did countless cherry-picks from 4.x to 3.6.

In fact, most big new features in this release were developed by lawnjelly himself, but he’s too humble to give himself a shoutout – so I do it for him with this note sneakily introduced in his blog post ;)

Giving back

As a community project, Godot is maintained by the efforts of volunteers. Thanks to user and company donations we are able to hire and sponsor a number of core contributors to work full-time and dedicate their undivided attention to the needs of the project.

Please consider supporting the project financially with a recurring monthly donation, if you are able. Godot continues to grow with each passing month, and we are committed to bringing you reliable and feature-rich releases as often as we can, to facilitate creative work of game developers of all levels. Recurring donations make sure the project is sustainable and its development can be planned for years ahead.

Besides financial support, you can also give back by: writing detailed bug reports, contributing to the code base, writing documentation, writing guides (for the Godot docs or on your own website), and supporting others on various community platforms by answering questions and providing helpful tips.

Last but not least, making games with Godot and crediting the engine goes a long way to help make it more popular and convince more people to contribute and improve Godot for everyone. Remember, we are all in this together and Godot requires community support in every area to thrive.

Highlights

Many new features have been added in Godot 3.6, both small and large. The following is a list of a few of the larger features that we are excited about in no particular order. For a complete list of all changes you can check out our curated changelog, as well as the raw changelog from Git (chronological, or sorted by authors).

2D physics interpolation (GH-76252)

Godot 3.5 introduced 3D physics interpolation with great success, and users have been awaiting its 2D counterpart, so here it comes! 2D physics interpolation supports most objects, including CPUParticles2D, but note that (GPU) Particles2D is not yet supported.

Be sure to read the physics interpolation documentation to get started. Note that physics interpolation is disabled by default, refer to the docs for how to enable it via project settings.

2D hierarchical culling (GH-68738)

2D items that are off-screen don’t need to be drawn. Previously, each item was checked individually to see whether it was off-screen (this is referred to as “culling”). With hierarchical culling, entire branches of the scene tree can be culled at once, which can significantly increase performance on large 2D maps that contain a lot of off-screen items.

Hierarchical culling defaults to on, but can be switched back to the legacy (“Item”) mode with the project setting rendering/2d/options/culling_mode, in case of regressions.

Tighter shadow culling (GH-84745)

Godot shadow mapping involves taking a simplified camera shot from the point of view of each shadow casting light, when objects move within this light volume. This happens every frame when objects are moving, and this can add up to a lot of draw calls for each light.

Tighter shadow culling reduces this workload considerably by eliminating draw calls for shadow casters that cannot cast a shadow that is visible from the main camera view. This involves some clever geometry, but the upshot is you should often see significantly better frame rates when using shadows.

This happens automatically.

Mesh merging (GH-61568)

Godot 3.6 now offers a comprehensive system for mesh merging, both at design time and at runtime. OpenGL can be severely bottlenecked by draw calls and state changes when drawing lots of objects. Now you can blast through these barriers and potentially render any number of similar objects in a single draw call.

As well as allowing you to optimize existing maps and moving objects, this also makes new procedural game types possible, as thousands of procedurally placed objects can be merged at runtime so as to render efficiently (think vegetation, rocks, furniture, houses, etc.).

See the MergeGroups documentation for details.

Discrete level of detail (LOD) (GH-85437)

The new LOD node provides simple but powerful LOD capabilities, allowing the engine to automatically change visual representation of objects based on the distance from the camera. An example would be simplifying trees in the distance in open world games.

This implementation of LOD differs dramatically from how LOD is implemented in Godot 4 as we chose to use a different implementation that better fits the architecture of Godot 3. In particular, we have removed the LOD settings from GeometryInstances and instead provide an LOD node which controls the LOD behavior of its children.

See the LOD documentation for details.

ORM materials (GH-76023)

Ansraer adds support for ORM materials, which is a standard format where occlusion, roughness, and metallic are combined into a single texture. This means these standard PBR textures can be used without modification, and rendering performance will likely be increased where they are used (compared to the old workflow).

Vertex cache optimization (GH-86339)

In the mesh import options (e.g. obj, gltf, dae) you will find a new setting for vertex cache optimization, enabled by default. This may increase rendering performance for high poly models on low-end hardware.

You can usually take advantage of vertex cache optimization in an already completed project, simply by deleting the hidden .godot folder (which contains imported data), and this imported data (including optimized meshes) will be recreated next time you open the editor.

Light probes and directional shadows performance improvements

Among a number of other bugfixes, a couple performance improvements have been added for BakedLightmap light probes (GH-80764, by mrezai) and directional shadows (GH-75468, by Ansraer).

View selected mesh stats (GH-88207)

The 3D view menu now offers a new (long overdue) option, “View Selected Mesh Stats”. This will display total triangle, vertex, and index counts for the selected meshes (and multimeshes).

This is incredibly useful information for diagnosing performance and checking imported meshes, and for use in conjunction with mesh merging and level of detail.

SceneTree dock’s filter improvements (GH-67347)

Mickeon backported a number of SceneTree dock improvements from the 4.x branch. The search/filter bar now supports multiple terms, as well as filtering by node type or group using the type: (or t:) and group: (or g:) prefixes.

Text-to-Speech support (GH-61316)

bruvzg backported the Text-to-Speech (TTS) implementation which they originally developed for Godot 4.0, which is supported on all Godot platforms using core system APIs (with the exception of Linux, which depends on the speech-dispatcher library being installed).

A demo is included in GH-61316 so that you can test the functionality on your target platforms.

In-editor documentation for Editor Settings (GH-48548, GH-64896)

Calinou added support for documenting Editor Settings, and wrote documentation for all the exposed ones. This notably adds useful tooltips when hovering the settings to better describe what they affect, and how what the possible values mean.

Updated toolchains for official builds

We’ve updated the toolchains (compiler, platform SDKs, etc.) for this release to match the versions used for Godot 4.2 (build-containers#135). This notably gives us the following toolchains:

Base image: Fedora 39
Mono version: 6.12.0.198
SCons: 4.5.2
Linux: GCC 13.2.0 built against glibc 2.28, binutils 2.40, from our own Linux SDK
Windows: MinGW 11.0.0, GCC 13.2.1, binutils 2.40
HTML5: Emscripten 3.1.39 (standard builds), Emscripten 1.39.9 (Mono builds)
Android: Android NDK 23.2.8568313, build-tools 33.0.2, platform android-33, CMake 3.22.1, JDK 11
macOS: Xcode 15.0 with Apple Clang (LLVM 16.0.0), MacOSX SDK 14.0
iOS: Xcode 15.0 with Apple Clang (LLVM 16.0.0), iPhoneOS SDK 17.0
UWP: Visual Studio 2017 (unchanged)

In practice this shouldn’t change much, aside from getting some better compile and linking-time optimizations thanks to newer toolchain versions, leading to potential size or performance improvements. And some bug fixes which may or may not affect our builds.

Official Linux ARM builds

Just like added in Godot 4.2, we now have official Linux ARM builds (arm32 and arm64) of Godot 3.6. This should allow both running the Godot editor on ARM devices (such as Raspberry Pi) and Chromebooks with the Linux subsystem, and exporting Godot projects to them. The Linux export template now lets you select the architecture at export time among the four options supported in 3.6: x86_64 (default), x86_32, arm64, arm32.

Update supported versions for Android, iOS, and macOS

The target version for Android was updated to SDK 34 (Android 14). This also implied changing the Java version used for exporting to Java 17 (versus 11 previously). The path to the Java SDK can be configured in the Editor Settings.

To ensure compatibility with current Apple SDKs, we had to increase the minimal supported version from iOS 10 to iOS 12 (GH-87359), and from macOS 10.12 to macOS 10.13 for x86_64 (GH-76394).

Other notable changes

2D

Make autotiles fall back to the most similar bitmask (GH-71533).
Fix AnimatedSprite normal map loading (GH-80406).
Fix viewport behaviour with physics interpolation (GH-92152).

3D

Fix OccluderPolyShape handles disappear after release click (GH-79947).
Add rotation ability to material editor preview (GH-49466).
Add TorusMesh (GH-64044).
Make Camera3D gizmo clickable (GH-68003).
SurfaceTool: Efficiency improvements (GH-69723).

Audio

Backport text-to-speech support (GH-61316).
Backport panning strength parameters (GH-64579).
Fix trim when importing WAV (GH-78048).
PulseAudio: Remove get_latency() caching (GH-80294).

C#

Support explicit values in flag properties, add C# flags support (GH-59328).
Print error when MethodBind call fails (GH-79433).

Core

Add boot splash minimum display time setting (GH-41833).
Add a use_hdr property to GradientTexture to allow storing HDR colors (GH-48372).
Fix nested resources being cached if no-cache argument used (GH-62408).
Faster queue free (GH-62444).
Optimize String.repeat() (GH-64995).
Add optional readahead to VariantParser (GH-65079, GH-69963).
Add ability to pick random value from array (GH-67444).
Add Color + alpha constructor for Color (GH-74973).
Make MessageQueue growable (GH-75527).
Backport some multi-threading goodies (GH-72251).
Expose determinant in Transform2D (GH-76323).
MessageQueue: Fix max usage performance statistic (GH-76533).
Fix size error in BitMap.opaque_to_polygons (GH-76544).
Fix rendering tiles using nested AtlasTextures (GH-76703).
Make acos and asin safe (GH-76902).
Fix overwriting of Spatial’s local transform (GH-78439).
Fix physics tick counter (GH-92941).
Fix pausing behavior with physics interpolation (GH-93382)

Editor

Add support for documenting most editor settings in the class reference (GH-48548).
Add vector value linking (GH-59125).
Backport locale selection improvements (GH-61878).
Mark Script button if it’s tool in Scene Tree Editor (GH-65088).
Add navigation controls to the spatial editor viewport for mobile (Android editor) (GH-67681).
Add built-in action toggle in Input Map settings (GH-69331).
Make create folder popup support nested folders (GH-76424).
Faster editor grid (GH-92725).

GDScript

Fix local variables not showing in debugger when break-pointing on final line (GH-58201).
Improve parser speed for very long scripts (GH-74782, GH-74794).
Suggest class_name in autocompletion (GH-76346).

GUI

Support multiline strings in buttons (GH-41464).
Support AtlasTexture in radial modes of TextureProgress (GH-68246).
Add alignment options to flow container (GH-68556).
Add allow_search property to ItemList and Tree (GH-76753).
Fix GridContainer max row/column calculations not skipping hidden children (GH-76833).
Stop dragging when Slider changes editability (GH-77245).
Add tab Metadata to Tabs & TabContainer (GH-75959).
RichTextLabel: Cache text property when toggling BBCode (GH-77403).
Fix PopupMenu’s automatic max height (GH-77691).
Backport video loop property and fix for initial black frame (GH-77979).

Import

Add 16-bits TGA support (GH-65717).
glTF imports & exports material texture filters (GH-66856).
Backport the GLTFDocumentExtension system (GH-70411).
Expose more compression formats in Image (GH-76016).
Implement physics support in the GLTF module (GH-76453).
Add vertex color support to OBJ importer (GH-76671).
Bounds fixes in TextureAtlas import (GH-77428).

Input

Add support for multiple virtual keyboard types (GH-58537).
Add MOUSE_MODE_CONFINED_HIDDEN to MouseMode enum (GH-63643).
Add double_tap attribute to InputEventScreenTouch (GH-67607).
Fix just pressed and released with short presses (GH-77040).
Prevent double input events on gamepad when running through steam input (GH-79706).
Add support for pointer capture (GH-68441).
Augment the InputEvent class with a CANCELED state (GH-76715).
Fix mouse speed not changing fast enough (GH-56765).
Fix InputEventAction’s is_match method ignoring exact_match parameter (GH-63109).

Particles

Add options for sorting transparent objects (GH-63040).
Fix 2D MultiMesh hierarchical culling (GH-80106).
Improve visibility rect/AABB generation usability in Particles (GH-50180).
Allow negative scale in Particles and CPUParticles (GH-53852).

Physics

Add ShapeCast and ShapeCast2D nodes (GH-63659).
Fix RigidDynamicBody gaining momentum with bounce (GH-76216).
Add area monitor callback error checking (GH-64079).

Porting

Android: Clean-up and refactor of the input implementation (GH-65398).
Android: Bump the target SDK version to 34 (Android 14) (GH-87588).
iOS: Swift runtime support for iOS Plugins (GH-49828).
macOS: Simplify code signing options, add support for rcodesign tool for signing and notarization (GH-66093).
Windows: Enable ANSI escape code processing on Windows 10 and later (GH-66216).
Add benchmark logic (GH-71875).
Android: Enable granular control of touchscreen related settings (GH-73692).
Android: Update the gradle build tasks to generate play store builds (GH-74583).
Android: Fix UI responsiveness to touch taps (GH-75699).
Android: Fix null in Android text entry system (GH-75992).
Android: Downgrade Android gradle plugin to version 7.2.1 (GH-76329).
Android: Allow concurrent buffering and dispatch of input events (GH-76400).
Android: Fix input ANR in the Godot Android editor (GH-76981).
Linux: Don’t use udev for joypad hotloading when running in a sandbox (GH-76961).
Add audio/general/text_to_speech project setting to enable/disable TTS (GH-77352).
Android: Improve touchpad and mouse support for the Android editor (GH-77497).
Android: Add Android editor setting to control the window used to run the project (GH-77677).
Linux: Cache TTS voice list (GH-77775).
Linux: Use current keyboard layout in OS_X11::keyboard_get_scancode_from_physical (GH-78169).
Fix ProjectSettings::localize_path for Windows paths (GH-80072).

Rendering

Take FXAA samples from half-pixel coordinates to improve quality (GH-66466).
Fix GLES 2 SpotLight bug with shadow filter mode (GH-69826).
Consistent render ordering for CanvasLayers (GH-69952).
Batching: Add MultiRect command (GH-68960).
Fix Polygon2D skinned bounds (for culling) (GH-75612).
Canvas item hierarchical culling (GH-68738).
2D Fixed Timestep Interpolation (GH-76252).
Physics Interpolation: Add support for CPUParticles2D (GH-80176).
Fix scene shader regression (GH-92070)
Fix 2D skinning with physics interpolation (GH-93309)
Backport additional spatial shader built-ins (GH-63971).
Fix NODE_POSITION_VIEW shader built-in (GH-76226).

Miscellaneous

Assetlib: Add support for svg images in the asset library (GH-70502).
Buildsystem: Add support for single compilation unit builds (GH-78113).
Export: macOS: Backport notarytool, provisioning profile and PKG export options (GH-80239).
GDNative: Add Core API 1.4, move Transform2D::determinant there (GH-77387).
Network: ENet: Better handle truncated socket messages (GH-79704).
XR: Disable blending before blitting to framebuffer from WebXR (GH-76072).
Documentation and translation updates.

Thirdparty library updates

As usual, we’re keeping thirdparty libraries updated, especially the ones which may be subject to security vulnerabilities.

This dev snapshot includes updates to:

Mozilla CA certificates from March 2024
SDL GameControllerDB from April 2024
brotli 1.1.0
bullet 3.25
embree 3.13.5
enet c44b7d0f7
libpng 1.6.43
libwebp 1.3.2
mbedtls 2.28.8
miniupnpc 2.2.7
minizip 1.3.1
pcre2 10.42
recast 1.6.0
tinyexr 1.0.8
wslay 0e7d106ff
zstd 1.5.5

Hundreds of other improvements

A ton of other improvements are also included in Godot 3.6. We advise interested users to dive into the curated changelog to know more, or the interactive changelog for an overview of all changes in 3.6.

Reporting issues

Godot is a complex piece of software and is not bug-free. Our contributors do their best to fix issues as they are being reported, but there’s a lot of surface to cover and you might encounter situations which we aren’t aware of yet, or couldn’t fix in time for this release. There will be 3.6.x maintenance releases focused on fixing bugs in coming weeks and months, so make sure to report any issue you encounter on GitHub, so that we can make sure to fix it for our future releases.

The illustration picture is a render of the GDQuest Gobot model (MIT license) in the Amazon Lumberyard Bistro scene (CC BY 4.0 license), made by Adam Scott.

Submissions open for Godot 2024 showreel!

2024-09-05T15:00:00+00:00

Showcase your Godot Engine 2024 creations! We invite you to submit videos featuring your published or in-progress games or tools so we can make the Godot 2024 Showreel.

The showreels are an informative and celebratory showcase, to highlight the wide array of projects developed using the Godot Engine. If you want to participate and share your Godot-made game, app or tool submit your entry starting today.

How to submit

You can submit your entry in our Godot Showreel website. You can use your Godot account or any other account (GitHub, Discord, etc.) to log in. Before submitting, please read the submission guidelines.

✅ Submit your entry
📋 Submission guidelines
📅 Submissions close on November 1st 2024 at 10:00 UTC

Changes from previous years

This year, the Godot Foundation will be selecting some games to be featured as well as the ones submitted by the community. This will be done due to the confusion caused by big titles not being present in past showreels because the developers forgot to submit or were not aware of our efforts. It shouldn’t change anything for the submission process, but we wanted to make sure we are transparent about the changes.

Need inspiration?

Check out our showreel playlist for some creative sparks and see what makes a great submission!

Good luck! We can’t wait to see your creations!

About Official Console Ports

2024-09-03T18:30:00+00:00

With this post we aim to address the community’s questions about the lack of official console ports through the Godot Foundation. Unfortunately, there has been a lot of mixed messaging on this topic in the past. The truth is that a lot of important information is locked behind vendor-specific NDAs, so even those in the know are often unable to fully explain the situation. Nonetheless, here we attempt to describe the current blockers to the best of our ability, and detail what that means for you as developers looking to port to console.

The Foundation does not plan on providing console ports at this time

First and foremost, with the situation being as it is, the Godot Foundation does not have active plans to work on console platform ports.

This may change in the future, especially if it becomes possible to share console ports that are truly Free and Open Source (i.e. not locked behind any NDAs or paywalls).

However, this does not mean you cannot bring your game to these platforms, see here for a list of unofficial vendors providing porting services.

Barriers to providing console ports

We wrote a blog post a few years ago explaining the barriers to providing console ports: https://godotengine.org/article/godot-consoles-all-you-need-know/. We want to expand on that post and include more detail about what led to our decision not to produce console ports through our non-profit organization.

From a high level, here are three barriers we are facing:

Legal liability
Disproportionate cost
Open source licensing issues

Of these three issues, only the inability to license ports as open source is a deal breaker for the Godot Foundation. The other two simply make it very expensive and undesirable for us to consider providing ports officially. Let’s look at these issues one by one.

Legal Liability

Broadly speaking, there are two types of console ports:

Games developed with approved middleware (e.g. Unity, Unreal)
Games developed with custom ports

Using approved middleware is ideal for game developers as they can trust that the game they develop will work on the target platform. A crucial part of approved middleware is that the engine provider accepts liability for any problems with the port. In other words: if there is a problem with the engine itself in regards to security, licensing, etc. then the middleware provider takes the liability and the game developer is safe.

The Godot Foundation is not able to take such liability, as it does not provide commercial support for any of its projects. In fact, this refusal to accept liability is core to the MIT license that Godot uses (more on licensing later).

From a liability perspective alone, anyone could provide source code for console ports in a closed environment only available to NDA holders that fully disclaims all sources of liability. The great news is that the first ports of this sort are surfacing already! They are difficult to find as you often need to have the relevant NDAs to discover them. In the case of a Nintendo Switch port, RAWRLAB Games was able to publicly announce their open-source Nintendo Switch port for Godot Engine users. This sort of community effort is amazing and is something that the Godot Foundation heavily encourages!

While we are very excited about this progress, we aren’t going to put our limited Godot Foundation resources behind developing such ports either, for the following reasons.

Disproportionate Cost

The Godot Foundation as an entity receives donations from the community to spend on the development of the Godot Engine as a project. That being said, these resources — which currently pay for about 10 people to work on anything from release management to writing code to organizational tasks — are nothing in comparison to the amount of voluntary time that you as a community invest in making the Godot Engine as successful as it has become in the recent years. At the time of writing, 2,634 volunteer contributors are listed as authors of the project!

We are gifted with a huge community of such passionate contributors, and put a lot of weight on enabling and encouraging new people to join into the process. Sadly, the number of potential contributors with console experience, access to console vendor NDAs, and devkits is very small in comparison.

This would flip our current situation on its head. With console ports, nearly all the work would have to be done by the Godot Foundation, which means the cost per platform would be disproportionately higher than for all other platforms we officially maintain (i.e. Windows/Linux/Mac, web and mobile). Even more so if we want the console ports to be the same quality as the rest of our code base, including maintenance and catering to new hardware.

This is both inefficient, and unfair to community members who don’t plan to release on consoles. A significant portion of their donation would go towards maintaining platform ports for closed systems which they don’t have access to (and can’t have access to without spending a significant amount of money).

It is also worth keeping in mind that Godot is a very large and fully featured game engine compared to other open source game engines out there. We have extensive third party libraries, dedicated 2D and 3D renderers, networking, multiple scripting language support, external plugins, etc. It would be an undertaking of immense effort and time to create a console port that fully supports all Godot has to offer.

Finally, because we do have limited resources, diverting any resources away from the core product to work on consoles would require slowing down development of Godot itself to create and maintain the console ports.

Licensing

The board of the Foundation strongly feels that we should only be using funds to develop Free and Open Source Software (FOSS). We are committed to being a fully FOSS project. Further, we credit our FOSS stance with a lot of our success. When you contribute to Godot, you become a part owner of the project and you don’t sign away your rights to your code in a CLA (contributor license agreement). This way, every contributor has assurance that they have worked to benefit all users, and that their contribution won’t be yanked away from them by the entity controlling development.

In short, we want to develop Godot in a way that ensures that anyone who downloads Godot can be assured that they own the copy of Godot that they are using. We do that by remaining dedicated to two things:

Using the MIT license
FOSS principles

MIT license

We use the MIT license to distribute Godot. Unfortunately, the MIT license is incompatible with providing official middleware because it very clearly states that we won’t take on liability for the code (i.e. you can’t sue us if it turns out that Godot doesn’t work for you, or has a bug that costs you money — which is important since we only operate on your donations to begin with). Further it is incompatible with non-middleware ports as well because such ports would have to be limited in their distribution to authorized console developers only.

Accordingly, any console port would have to be distributed under a modified MIT license or another license that allowed us to limit who the code could be distributed to (and potentially limit the distribution in other ways). In either case, we would have to compromise our FOSS ideals, which we feel are our strength.

FOSS principles

Further, and more importantly, we do all of our development in the open. Everything is on GitHub or our developer chat (chat.godotengine.org, which is open to all who want to discuss development of the project or just listen in). We don’t want to put ourselves in a situation where our development has to happen behind closed doors and away from the eyes of the community, and this is exactly what would be required by the console vendors.

Right now, anyone can see the volume of work that is happening on Godot by visiting Godot’s GitHub page. They can also hang out on the chat and get a feel for the process of development or ask questions directly to the developers. If we shift our development behind closed doors, then you have to take our word that things are progressing and that the donations are being put to good use (unless you have the relevant NDAs).

Finally, we want to assure every contributor and every donor that their contribution benefits all Godot users. If we put donations towards a console port that is hidden behind closed doors, then we are taking resources away from everyone and putting them into something that only benefits a select few and that isn’t something we want to do.

Summary

For the above reasons, the Foundation has decided not to provide console ports for now. Not because we categorically do not want to, quite the opposite actually, but because it currently is not feasible for us and would require to compromise the things that make Godot great. In the future, if console manufacturers become more open about the licensing of console ports in particular, and maybe even agree to support that endeavor financially, then we will happily reconsider. We would love to have official console ports alongside the existing ones from third-party vendors for all of our community to use.

Meeting the community at gamescom 2024

2024-09-02T18:30:00+00:00

Gamescom is more popular than ever. It used to be that you could hide from the masses flooding the entertainment halls by going to the indie area, and playtest one of the few games exhibiting in that much calmer space. Squeezed between the retro, education, and job-market booths, I recall not that many people even knew of its existence - the entire hall was classified as the family-friendly one. Nowadays, the Indie Arena Booth alone featured 170 developers, and found competition in multiple other indie groups occupying similar amounts of floor space.

Between these conglomerates and the country/state booths, we managed to count 9 Godot games, some familiar faces as well as a few surprises among them. Regrettably, we are sure to have missed some - if only events would release the exhibitor list with a note on engine technology used. One can only dream… Unless?

Since most gamescom demos are still online, here our incomplete list for you to playtest:

Did you too exhibit a Godot game at gamescom and want to be added to this list? Email nat@godotengine.org with a link to your demo.

Another thing we discovered in the trade area: the big players in this industry are starting to take us more seriously than ever. This is in line with our GDC experience back in March. Let’s see which of the meetings lead to future collaborations; however, even just hearing about publishers and tool providers that they are looking into supporting Godot, upon request from their developers, is amazing news.

On Thursday evening, we hosted our own off-site Godot mixer, and attendance was great! Sitting on the outside patio of the Haxenhaus, an old GDC Europe staple location as we were told, we got to enjoy plenty of food and drink - courtesy of our longtime sponsor W4 Games.

It is always a pleasure to meet our community face to face, and we are flattered that many of you seem to agree. Thank you to all attendees for sharing your personal Godot Engine stories with us, we learn a lot from these conversations every time. For the next events, we might need more sponsors to be able to accommodate more than “just” 50 of you.

To meet a few more community members, we also assembled Friday afternoon at the aforementioned Indie Arena Booth. Despite having to yell-talk and running out of goodies to distribute, we had a lot of fun helping fellow developers network and mingling ourselves. Considering the amount of people that showed up, we were almost concerned the Germans would come after us for “unlawful assembly” or “blocking the exit paths” - luckily for us, nothing of that sort happened and instead we got to take a big happy group picture:

What event would you like to see us attend next? Tell us on our official forum! Bonus points if you know a local user group or creators who would help us staff a booth, and a sponsor to help with the related expenses.

Dev snapshot: Godot 4.4 dev 1

2024-08-26T13:00:00+00:00

This is the first dev snapshot for 4.4! During the beta and release candidate stages of 4.3, we accumulated a lot of PRs that were of great quality, but deemed too risky to include in 4.3. We have begun merging those PRs now and have quickly gathered a lot of changes that warrant a dev release!

The cover illustration is from Gourdlets, an easygoing sandbox game about building towns for cute vegetable folks. Developed in Godot 4 by AuntyGames, it was recently released on Steam to critical acclaim. You can follow the developer on Twitter, TikTok, and Instagram.

Highlights

After just 10 days of development, we are bringing you a bunch of fixes and improvements, some of which are fairly massive new features!

Metal rendering backend

We hinted that a Metal backend was in the works and it is finally here (GH-88199), thanks to the exceptional work of Stuart Carnie!

Metal is a low-level graphics API similar to Vulkan or D3D12. Godot currently supports using Vulkan or D3D12, but neither of those are available on macOS and iOS, so we use a library called MoltenVK to run Vulkan over Metal. MoltenVK is great and has worked well for us. However, having our own Metal implementation is more efficient and allows us to have a greater control over what features we support and what performance tradeoffs we make.

Early results show that the Metal backend on macOS is at least as fast as the Vulkan backend and in many cases, much faster.

Right now, we only support Metal on Apple Silicon (ARM) devices. That includes all iOS devices and the M1/M2/M3 Macs. Intel-based Apple devices will continue to work with the MoltenVK backend. Currently, this limitation is due to the fact that few contributors working in this area have access to non-Apple Silicon devices.

3D physics interpolation

Godot 4.3 came with physics interpolation for 2D nodes, and now the 3D counterpart has been merged (GH-92391), with Ricardo Buring continuing the forward-porting of lawnjelly’s Godot 3.x implementation. Not only that but support for MultiMeshes has also been merged (GH-91818)!

Physics interpolation is a technique that allows you to run your physics update at a very low FPS while maintaining smooth movement. This allows you to both save CPU overhead and make your game look much smoother.

Lightmap bicubic sampling

Bicubic sampling is a method for reading from a lightmap that smooths our sharp edges. It is especially useful when you bake lightmaps with shadows at a low texture resolution. We supported this in Godot 3, and have now brought it back in GH-89919, courtesy of BlueCube3310.

Bicubic sampling comes with a small run-time performance cost on the GPU, so it can be disabled in a project setting if needed.

Combined with new antialiasing for direct light samples (GH-95828), low resolution static shadows now look much better in lightmaps.

Betsy texture compressor

The Betsy texture compressor is a tool to compress images into various GPU texture formats. Currently, compressing images for the GPU (in Godot using the “VRAM Compressed” import setting) can be quite slow. Betsy is a texture compressor that runs on the GPU and is able to compress images significantly faster than our current compressors. This reduces import time dramatically.

While Betsy was written a few years ago by Matias N. Goldberg, we are just beginning to integrate it into the engine now (GH-91535), thanks to the effort of BlueCube3310. Currently it is only implemented for HDR images set to “high quality”. However, soon we will extend it to many more compression types and begin to use it internally for things like lightmaps.

The improvement is most obvious when importing HDRIs, here are a few examples from the PR:

Image	CVTT	Betsy
Symmetrical garden 8k .hdr with mipmaps	92.4s	475ms
Cobblestone Street Night .hdr 4k with mipmaps	26.5s	217ms
Laufenurg Church 8k .hdr with mipmaps	99.3s	440ms
Little Paris 8k .hdr with mipmaps	92.7s	467ms

Dev1 also brings optimizations to other stages of loading HDRIs that should make them much faster across the board:

Optimize converting half float and full float formats (~10× improvement) (GH-92291).
Optimize loading HDRIs (~25× improvement) (GH-95291).

Optimizations

Contributors have been hard at work on various optimizations across the engine. Now that Godot 4 is being used more and the core feature set is feeling stable, we can turn our minds to optimizing the existing features. Many optimizations were finished and tested before the 4.3 release but were too late to merge. So now we get them all in one big batch.

Here are a few:

Core: Reduce memory allocations when formatting strings (GH-94558). This makes formatting strings about 2× faster.
Core: Optimize Array.insert (GH-94353). This makes inserting new elements into an Array about 10× faster on average.
Core: Optimize String.insert (GH-92555).
Core: Optimize String.join (GH-92550).
Core: Optimize String.replace (GH-92546).
Import: Disable normal raycaster by default (GH-93727). This makes importing meshes with LODs approximately 2× faster. We expect that the quality of imported LODs will be the same. If you notice any issues, please let us know. You can re-enable the raycaster in the object’s import settings under lods/raycast_normals.
Editor: Optimize editor grid recalculation (GH-92734).
Editor: Optimize closing the editor settings (GH-95704).
Rendering: Optimize meshes for vertex cache (GH-94241). In scenes with a lot of geometry, this can result in a 20% improvement in frame time.
Rendering: Optimize materials with ambient_light_disabled (GH-92213).

And more!

There are too many exciting changes to list them all here, but here are a few more.

Editor: Fix uid:// paths fail to load at editor startup (GH-95689).
Editor: Correct rotation gizmo plane math for off-center perspective view (GH-95402).
Editor: Make viewport grid visible on all three planes in orthogonal camera view (GH-93869).
Editor: Expose GDScript syntax highlighter to editor plugins (GH-95764).
Rendering: Fix generated light probes placing too close to manual light probes (GH-83497).
Rendering: Antialias direct light samples in LightmapperRD (GH-95828).
Rendering: Add fixed fog to the sky in the Compatibility renderer (GH-95662).
Rendering: Implement visual layers for DirectionalLight3D (GH-95379).
Rendering: Fix LightmapGI not taking environment sky rotation into account when baking (GH-95000).
Import: Add support for loading less common DDS formats (GH-86204).
Import: Add option to export Geometry Nodes Instances in Blender importer (GH-87735).
Android: Memory cleanup and optimization (GH-94799).
Core: Handle the smoothstep degenerate case of empty range (GH-93149).
Navigation: Add triangulation partition option to 2D navigation mesh baking (GH-92560).
XR: OpenXR: Add support for visibility mask (GH-91750).
Physics: Fix SoftBody3D pinned points breaking when reloading scene (GH-86310).

Changelog

99 contributors submitted 228 improvements for this new snapshot. See our interactive changelog for the complete list of changes since 4.3-stable.

This release is built from commit 28a72fa43.

Downloads

Download Godot 4.4 dev1

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

Known issues

There are currently no known issues introduced by this release.

With every release we accept that there are going to be various issues, which have already been reported but haven’t been fixed yet. See the GitHub issue tracker for a complete list of known bugs.

Bug reports

Support

Godot 4.3, a shared effort

2024-08-15T11:00:00+00:00

With over 3,500 commits authored by over 500 contributors, the latest Godot Engine release comes packed full of new features and improvements.

Design of the Skeleton Modifier 3D

2024-08-12T10:00:00+00:00

In Godot 4.3 we are adding a new node called SkeletonModifier3D. It is used to animate Skeleton3Ds outside of AnimationMixer and is now the base class for several existing nodes.

As part of this we have deprecated (but not removed) some of the pose override functionality in Skeleton3D including:

set_bone_global_pose_override()
get_bone_global_pose_override()
get_bone_global_pose_no_override()
clear_bones_global_pose_override()

Did the pose override design have problems?

Previously, we recommended using the property global_pose_override when modifying the bones. This was useful because the original pose was kept separately, so blend values could be set, and bones could be modified without changing the property in .tscn file. However, the more complex people’s demands for Godot 3D became, the less it covered the use cases and became outdated.

The main problem is the fact that “the processing order between Skeleton3D and AnimationMixer is changed depending on the SceneTree structure`.

For example, it means that the following two scenes will have different results:

If there is a modifier such as IK or physical bone, in most cases, it needs to be applied to the result of the played animation. So they need to be processed after the AnimationMixer.

In the old skeleton modifier design with bone pose override you must place those modifiers below the AnimationMixer. However as scene trees become more complex, it becomes difficult to keep track of the processing order. Also the scene might be imported from glTF which cannot be edited without localization, so managing node order becomes tedious.

Moreover, if multiple nodes use bone pose override, it breaks the modified result.

Let’s imagine a case in which bone modification is performed in the following order:

AnimationMixer -> ModifierA -> ModifierB

Keep in mind that both ModifierA and ModifierB need to get the bone pose that was processed immediately before.

The AnimationMixer does not use set_bone_global_pose_override(), so it transforms the original pose as set_bone_pose_rotation(). This means that the input to ModifierA must be retrieved from the original pose with get_bone_global_pose_no_override() and the output must be retreived from the override with get_bone_global_pose_override(). In this case, if ModiferB wants to consider the output of ModiferA, both the input and output of ModifierB must be the override with get_bone_global_pose_override().

Then, can the order of ModifierA and ModifierB be interchanged?

–The answer is “NO”.

Because ModifierB’s input is now get_bone_global_pose_override() which is different from get_bone_global_pose_no_override(), so ModifierB cannot get the original pose set by the AnimationMixer.

As I described above, the override design was very weak in terms of process ordering.

How does the new skeleton design work with SkeletonModifier3D?

SkeletonModifier3D is designed to modify bones in the _process_modification() virtual method. This means that if you want to develop a custom SkeletonModifier3D, you will need to modify the bones within that method.

SkeletonModifier3D does not execute modifications by itself, but is executed by the parent of Skeleton3D. By placing SkeletonModifier3D as a child of Skeleton3D, they are registered in Skeleton3D, and the process is executed only once per frame in the Skeleton3D update process. Then, the processing order between modifiers is guaranteed to be the same as the order of the children in Skeleton3D’s child list.

Since AnimationMixer is applied before the Skeleton3D update process, SkeletonModifier3D is guaranteed to run after AnimationMixer. Also, they do not require bone_pose_global_override; This removes any confusion as to whether we should use override or not.

Here is a SkeletonModifier3D sequence diagram:

Dirty flag resolution may be performed several times per frame, but the update process is a deferred call and is performed only once per frame.

At the beginning of the update process, it stores the pose before the modification process temporarily. When the modification process is complete and applied to the skin, the pose is rolled back to the temporarily stored pose. This performs the role of the past bone_pose_global_override which stored the override pose separate from the original pose.

By the way, you may want to get the pose after the modification, or you may wonder why the modifier in the later part cannot enter the original pose when there are multiple modifiers.

We have added some signals for cases where you need to retrieve the pose at each point in time, so you can use them.

AnimationMixer: mixer_applied
- Notifies when the blending result related have been applied to the target objects
SkeletonModifier3D: modification_processed
- Notifies when the modification have been finished
Skeleton3D: skeleton_updated
- Emitted when the final pose has been calculated will be applied to the skin in the update process

Also, note that this process depends on the Skeleton3D.modifier_callback_mode_process property.

For example, in a use case that the node uses the physics process outside of Skeleton3D and it affects SkeletonModifier3D, the property must be set to Physics.

Finally, now we can say that SkeletonModifier3D does not make it impossible to do anything that was possible in the past.

How to make a custom SkeletonModifier3D?

SkeletonModifier3D is a virtual class, so you can’t add it as stand alone node to a scene.

Then, how do we create a custom SkeletonModifier3D? Let’s try to create a simple custom SkeletonModifier3D that points the Y-axis of a bone to a specific coordinate.

1. Create a script

Create a blank gdscript file that extends SkeletonModifier3D. At this time, register the custom SkeletonModifier3D you created with the class_name declaration so that it can be added to the scene dock.

class_name CustomModifier
extends SkeletonModifier3D

2. Add some declarations and properties

If necessary, add a property to set the bone by declaring @export_enum and set the Skeleton3D bone names as a hint in _validate_property(). You also need to declare @tool if you want to select it in the editor.

@tool
class_name CustomModifier
extends SkeletonModifier3D
@export var target_coordinate: Vector3 = Vector3(0, 0, 0)
@export_enum(" ") var bone: String
func _validate_property(property: Dictionary) -> void:
if property.name == "bone":
var skeleton: Skeleton3D = get_skeleton()
if skeleton:
property.hint = PROPERTY_HINT_ENUM
property.hint_string = skeleton.get_concatenated_bone_names()

The @tool declaration is also required for previewing modifications by SkeletonModifier3D, so you can consider it is required basically.

3. Coding calculations of the modification in `_process_modification()`

@tool
class_name CustomModifier
extends SkeletonModifier3D
@export var target_coordinate: Vector3 = Vector3(0, 0, 0)
@export_enum(" ") var bone: String
func _validate_property(property: Dictionary) -> void:
if property.name == "bone":
var skeleton: Skeleton3D = get_skeleton()
if skeleton:
property.hint = PROPERTY_HINT_ENUM
property.hint_string = skeleton.get_concatenated_bone_names()
func _process_modification() -> void:
var skeleton: Skeleton3D = get_skeleton()
if !skeleton:
return # Never happen, but for the safety.
var bone_idx: int = skeleton.find_bone(bone)
var parent_idx: int = skeleton.get_bone_parent(bone_idx)
var pose: Transform3D = skeleton.global_transform * skeleton.get_bone_global_pose(bone_idx)
var looked_at: Transform3D = _y_look_at(pose, target_coordinate)
skeleton.set_bone_global_pose(bone_idx, Transform3D(looked_at.basis.orthonormalized(), skeleton.get_bone_global_pose(bone_idx).origin))
func _y_look_at(from: Transform3D, target: Vector3) -> Transform3D:
var t_v: Vector3 = target - from.origin
var v_y: Vector3 = t_v.normalized()
var v_z: Vector3 = from.basis.x.cross(v_y)
v_z = v_z.normalized()
var v_x: Vector3 = v_y.cross(v_z)
from.basis = Basis(v_x, v_y, v_z)
return from

_process_modification() is a virtual method called in the update process after the AnimationMixer has been applied, as described in the sequence diagram above. If you modify bones in it, it is guaranteed that the order in which the modifications are applied will match the order of SkeletonModifier3D of the Skeleton3D’s child list.

Note that the modification should always be applied to the bones at 100% amount. Because SkeletonModifier3D has an influence property, the value of which is processed and interpolated by Skeleton3D. In other words, you do not need to write code to change the amount of modification applied; You should avoid implementing duplicate interpolation processes. However, if your custom SkeletonModifier3D can specify multiple bones and you want to manage the amount separately for each bone, it makes sense that adding the amount properties for each bone to your custom modifier.

Finally, remember that this method will not be called if the parent is not a Skeleton3D.

4. Retrieve modified values from other Nodes

The modification by SkeletonModifier3D is immediately discarded after it is applied to the skin, so it is not reflected in the bone pose of Skeleton3D during _process().

If you need to retrieve the modificated pose values from other nodes, you must connect them to the appropriate signals.

For example, this is a Label3D which reflects the modification after the animation is applied and after all modifications are processed.

@tool
extends Label3D
@onready var poses: Dictionary = { "animated_pose": "", "modified_pose": "" }
func _update_text() -> void:
text = "animated_pose:" + str(poses["animated_pose"]) + "\n" + "modified_pose:" + str(poses["modified_pose"])
func _on_animation_player_mixer_applied() -> void:
poses["animated_pose"] = $"../Armature/Skeleton3D".get_bone_pose(1)
_update_text()
func _on_skeleton_3d_skeleton_updated() -> void:
poses["modified_pose"] = $"../Armature/Skeleton3D".get_bone_pose(1)
_update_text()

You can see the pose is different depending on the signal.

Download

skeleton-modifier-3d-demo-project.zip

Do I always need to create a custom SkeletonModifier3D when modifying a Skeleton3D bone?

As explained above, the modification provided by SkeletonModifier3D is temporary. So SkeletonModifier3D would be appropriate for effectors and controllers as post FX.

If you want permanent modifications, i.e., if you want to develop something like a bone editor, then it makes sense that it is not a SkeletonModifier3D. Also, in simple cases where it is guaranteed that no other SkeletonModifier3D will be used in the scene, your judgment will prevail.

What kind of SkeletonModifier3D nodes are included in Godot 4.3?

For now, Godot 4.3 will be containing only SkeletonModifier3D which is a migration of several existing nodes that have been in existence since 4.0.

But, there is good news! We are planning to add some built in SkeletonModifier3Ds in Godot 4.4, such as new IK, constraint, and springbone/jiggle.

If you are interested in developing your own effect using SkeletonModifier3D, feel free to make a proposal to include it in core.

Support

Release candidate: Godot 4.3 RC 3

2024-08-08T14:00:00+00:00

Third time’s the charm! A few more regressions have been found and fixed thanks to our previous two Release Candidates for Godot 4.3, so we are now going for a third round to validate those last minute fixes.

All issues and PRs which were still on the 4.3 milestone but not critical have now been retriaged and postponed, which means the release should be good to go! Of course we haven’t fixed all known bugs in the engine, but we believe we’ve addressed the ones that could prevent users from having a better experience in 4.3 than in the current 4.2 stable branch.

Godot is a big piece of software and it’s hard for contributors and even unit tests to validate all areas of the engine when developing new features or bug fixes. So we rely on extensive testing from the community to find engine issues while testing dev, beta, and RC snapshots in your projects, and reporting them so that we can fix them prior to tagging the 4.3-stable release.

Please, consider supporting the project financially, if you are able. Godot is maintained by the efforts of volunteers and a small team of paid contributors. Your donations go towards sponsoring their work and ensuring they can dedicate their undivided attention to the needs of the project.

The cover illustration is from Pixelorama, an increasingly popular open source pixel art editor made with Godot by Orama Interactive and contributors. They just released their 1.0 version, and Pixelorama is now available both on itch.io and on Steam, where you can purchase it to support developers. And of course, the full source code is available on GitHub.

Highlights

We covered the most important highlights from Godot 4.3 in the previous 4.3 beta 1 blog post, so if you haven’t read that one, have a look to be introduced to the main new features added in the 4.3 release.

Especially if you’re testing 4.3 for the first time, you’ll want to get a condensed overview of what new features you might want to make use of.

This section covers changes made since the previous RC 2 snapshot, which are mostly regression fixes, or “safe” fixes to longstanding issues.

Here’s a selection of the some of most relevant ones:

Animation: Snap current position to the edge on animation finished (GH-95023).
Animation: Fix crash on reimport scene with animations (GH-95084).
Animation: Make Skeleton3D bone simulator an internal child (GH-95239).
Core: ResourceLoader: Add check to prevent double free crashes (GH-95186).
Editor: Various fixes to the project manager create/import dialogs (GH-95062, GH-95086, GH-95245).
Editor: Don’t drop PackedScene as property (GH-95090).
GDScript: Fix unnecessary calls to remove_parser (GH-95115).
GUI: PopupMenu: Increase mouse button release timeout and reset it from post_popup (GH-95232).
Import: Fix performance issue reimport file reload scene (GH-95225, GH-95264).
Input: X11: Use motion event button state instead of async state (GH-95008).
Input: Windows: Reject WM_POINTER(UP/DOWN) messages for non pen pointer type (GH-95155).
Multiplayer: ENet: Better handle disconnected peers in DTLS server (GH-95067).
Multiplayer: Avoid error spam in relay protocol when clients disconnect (GH-95192).
Multiplayer: Fix relay protocol routing with negative targets (GH-95194).
Network: WS: Fix set_no_delay on Windows (GH-95233).
Porting: Windows: Check if transparency is enabled in the project setting before applying DWM blur (GH-95009).
Porting: macOS: Attempt to terminate process normally before using forceTerminate (GH-95191).
Porting: macOS: Load OpenGL.framework by path to avoid issues with non-Latin executable names (GH-95235).
Rendering: D3D12: Avoid cases of redundant render target clears (GH-95064).
Rendering: D3D12: Avoid crash on exit (GH-95074).
Rendering: Fix LightmapGI causes crash when using --headless (GH-95103).
Shaders: VisualShader: Reduce size changes of nodes when connecting/disconnecting (GH-95061).

Changelog

18 contributors submitted 40 improvements for this new snapshot. See our interactive changelog for the complete list of changes since the 4.3-rc2 snapshot. You can also review all changes included in 4.3 compared to the previous 4.2 feature release.

This release is built from commit 03afb92ef.

Downloads

Download Godot 4.3 rc3

Linux

macOS

Windows

Export templates and other downloads Make a Donation

Standard build includes support for GDScript and GDExtension.

.NET build (marked as mono) includes support for C#, as well as GDScript and GDExtension.

See also C# platform support.

If you want to test the new Windows ARM64 builds, you will now find them listed in the usual download page.

Known issues

During the Release Candidate stage, we focus exclusively on solving showstopping regressions (i.e. something that worked in a previous release is now broken, without workaround). You can have a look at our current list of regressions and significant issues which we aim to address before releasing 4.3. This list is dynamic and will be updated if we discover new blocking issues after more users start testing the RC snapshots.

With every release, we are aware that there are going to be various issues which have already been reported but haven’t been fixed yet, due to limited resources. See the GitHub issue tracker for a complete list of known bugs.

Godot Engine Official

Dev snapshot: Godot 4.4 dev 7

Highlights

Jolt Physics module

.NET 8.0

Improved Scene Tree editor performance

Documentation tooltips

Baked shadowmasks for lightmaps

Updated toolchains for official builds

And more!

Changelog

Downloads

Known issues

Bug reports

Support

Godot XR community - December 2024

Godot XR community Game Jams

Godot XR Game Jam #1

Godot XR Game Jam #2

Godot XR Game Jam #3

Universal Godot VR plugin

Body tracking and motion capture plugins

Meta platform plugin

Godot XR Tools

Godot ARCore support

Meet the creator behind the Godot Game Awards

What inspired you to create the Godot Game Awards, and how long has it been running?

How can people get involved in this year’s edition?

Tell us about your YouTube channel—what kind of content do you focus on, and what motivated you to start creating videos?

How did you discover Godot? When did you start using it? Do you have prior experience with other game engines?

What advice would you give to someone starting out as a game developer or content creator in the Godot community?

Do you plan to continue organizing the Godot Game Awards in the future?

Dev snapshot: Godot 4.4 dev 6

Highlights

Camera3D preview in inspector

CollisionShape3D debug color customization

Replace internal CSG implementation with Manifold library

Runtime WAV file loading

Extend Curve to allow for domains outside of [0, 1]

Temporary file and directory utilities

And more!

Changelog

Downloads

Known issues

Bug reports

Support

Beyond #100000: You're breathtaking!

Some stats about Godot usage on GitHub

Issues

Pull Requests

Godot Foundation Update December 2024

Key policies and procedures

Contractors

Upcoming projects

Asset store

Job board

Project priorities

Trademark policy

The Foundation’s role in the project

Support

Statement on GodLoader malware loader

Good security practices

Reporting security issues

Dev snapshot: Godot 4.4 dev 5

Highlights

Universalize UID support

Favorite editor items

And more!

Changelog

Downloads

Known issues

Bug reports

Support

GodotCon 24: Berlin Edition

Sponsor support

Critical Reflex

Endless Foundation

W4 Games

Poki

AWS

Extend Curve to allow for domains outside of `[0, 1]`

`@export_tool_button` annotation