Godot Engine 3.3

What's new in this version:

Platforms:
Godot editor on the Web:
- Fabio Alessandrelli (Faless) has done a lot of work to enable running the Godot editor on the Web, using the same export code as for Godot-made games (since the Godot editor is developed 100% with the Godot API). These changes have led to countless improvements for Web exports (see below).
- Building upon the initial prototype, we've now reached a state where we're happy to release the Web editor in sync with the native version, so you can find the latest stable version on editor.godotengine.org.
- Web editor running the "Ninja Adventure" demo from the eponymous CC0 asset pack by Pixel-Boy and AAA.

Android: App Bundle, subview, signing:
- Android App Bundle (AAB) is a publishing format that enables more efficient distribution of Android apps. Thanks to Aman Jain (amanj120) and the support of our Android maintainer Fredia Huya-Kouadio (m4gr3d), Godot 3.3 now supports exporting AABs in addition to APKs.
- Google Play recommends publishing AABs since they enable the Play Store to distribute only the preferred native libraries for the ABI of a device, e.g. only armeabi-v7a or arm64-v8a. In the second half of 2021 AABs will become the only supported publishing format for Google Play.
- Additionally, many other features have been implemented such as subview embedding, support for cutout/notches on Android 9+, and implementation of mouse events and external keyboard input.
- To accommodate Google Play requirements, we disable the requestLegacyExternalStorage attribute when there are no external storage permissions enabled. Note that if you do need access to external storage, Godot will currently still need to set this attribute as support for scoped storage hasn't been implemented yet.
- Similarly, we've updated the signing logic to use apksigner instead of the now deprecated jarsigner. This requires you to review your Android SDK setup and editor settings to make sure that Godot can find apksigner in a compatible version. See Exporting for Android for the updated documentation.

iOS: New plugin API:
- Godot 3.2.2 introduced a new API for Android plugins which allow building and distributing them easily to end users.
- For 3.3, Sergey Minakov implemented the same interface for iOS plugins. This made it possible to move iOS plugins such as ARKit, GameCenter, InAppStore, etc. to a separate, first-party godot-ios-plugins repository, so they can be improved independently of Godot itself.
- And the same can be done for third-party plugins which can now be distributed as convenient plug-and-play packages. See iOS plugins for the relevant documentation on creating and using such plugins.

HTML5: Threads, GDNative, AudioWorklet:
- In parallel to working on the Web editor, Fabio did many improvements to the HTML5 platform port which will benefit all users
- One notable change is that there is now support for both threads and GDNative in the HTML5 platform port. However, due to platform limitations, those are mutually incompatible. Additionally, the threads support depends on the SharedArrayBuffer API, which is not yet supported in all browsers (notably Safari on macOS and iOS). As such Godot 3.3 comes with three different export templates, see Exporting for the Web for detailed documentation.
- The "threads" build additionally benefits from support for the AudioWorklet API, which allows better audio output without blocking the main thread.
- Fabio also greatly improved support for gamepads and virtual keyboards in the Web export... and tons of other things which would be impossible to mention exhaustively here. But in short, 3.3 is a massive release for the Web export.

macOS: ARM64 build, code signing:
- Thanks to Pāvels Nadtočajevs (bruvzg), Godot 3.2.3 already had support for compiling Godot for Apple M1 Macs (ARM64 architecture), but we hadn't updated our infrastructure to provide such builds at the time. With Godot 3.3, we now provide a universal binary which supports both x86_64 and ARM64 Macs. As of 3.3, this is only for the standard build, not for the Mono ones, as we still need more work to be able to cross-compile Mono for Apple M1.
- Additionally, we now provide editor binaries which are signed and notarized, so you should no longer need to jump through hoops to run Godot on a Mac. Thanks to Hein-Pieter van Braam-Stewart (hpvb) and his company Prehensile Tales who provide the Mac and signing certificate needed for this. Both standard and Mono builds are notarized.
- The export dialog now has support for signing your builds when you export your game from a Mac, including the configuration of entitlements (this is sadly not possible from other OSes as it depends on macOS-specific tools).

Core:
Modernized multi-threading APIs:
- After doing this work for the master branch (4.0), Pedro J. Estébanez (RandomShaper) backported his modernization of multi-threading APIs to the 3.x branch. This builds upon Godot's recent adoption of C++11 and beyond (now C++17 in the master branch, C++14 in 3.x), which provides us with more reliable cross-platform implementations than the ones we had so far.
- This should help fix some issues which could affect specific platforms, as well as improve overall reliability and performance. It is however a fairly major change so if your projects relied heavily on multi-threading APIs and you encounter any issue with 3.3, please make sure to report it.

Dynamic BVH for rendering and GodotPhysics:
- Our contributor lawnjelly seems to have decided to tackle many much needed optimizations for the 3.x branch, to ease our waiting time for Godot 4.0. One such optimization was the implementation of a dynamic BVH method for spatial partitioning as an alternative to Godot's existing Octree. This aims at solving many performance issues and bugs of the octree implementation, and benefits the rendering and GodotPhysics backends specifically (Bullet already has its own BVH).
- The new BVH is used by default, but there are project settings to change that and go back to the octree method if you notice issues in your project. Make sure to report any problem you encounter on GitHub, so that we can keep improving this for Godot 3.4.

Raise errors when accessing deleted objects in debug:
- Most Godot users are familiar with the infamous situation of attempting to access a reference to an Object after it has been freed. The reference does not evaluate to null, yet it can't be safely dereferenced, leading to the risk of crashes in release builds if such dereferencing is not verified with is_instance_valid(). There were several fixes around this in 3.2.2, and some follow-ups in 3.2.3 but going one step too far: in debug builds in 3.2.3, such references to freed objects would evaluation as null, thus leading to tricky situations where a game runs fine in the editor (debug) but would error out or crash once exported in release mode.
- Godot 3.3 solves this by no longer decaying references to freed objects to null in debug builds, so you should properly get errors in the editor that let you identify which code is problematic.

Rendering:
Unified 2D batching:
- After implementing 2D batching in GLES2 in 3.2.2 and 3.2.3, lawnjelly has overhauled the system with a common intermediate layer allowing it to operate in GLES3 as well as GLES2. In addition batching has been expanded to cover many other primitives (polys, lines, ninepatches) as well as the rects featured in earlier versions.
- New vertex formats allow many more custom shaders and cases to take advantage of batching than before, and optional 2D software skinning has been added which should allow using 2D skeletal animation on a far wider range of hardware than was previously available.
- As always, it is possible to revert to the legacy renderer by turning off batching in project settings

New CPU lightmapper:
- The lightmapper in the previous 3.x releases was quickly put together before the 3.0 release and it had some major issues. It was reusing parts of the code for baking GIProbes, and that made it quick but not great in terms of quality. Back in summer 2019 we already knew Godot 4.0 would feature a completely new GPU-based lightmapper, but it required Vulkan support and 4.0 was still far away, so we tasked Joan Fons (jfons), as part of the GSoC program, to write a new CPU lightmapper for Godot 3.x. After a long hiatus in development and a couple of rewrites here and there, the brand new CPU lightmapper was finally merged into the 3.3 branch at the begining of this year.
- The biggest difference with the old lightmapper is that the new one features proper path tracing, which results in better looking lightmaps. Also, the new lightmapper brings support for denoising using Open Image Denoise, which results in better-looking lightmaps in the same bake time range. On top of that, other quality of life improvements have been added or back-ported from 4.0, such as support for baking environment lighting, lightmap texture atlassing, per-object resolution scaling, cubic filtering of lightmaps at runtime, and last but not least, automatic disabling of baked lights, which eases up the pain of mixing baked and non-baked objects and light in the same scene.
- Note that the new lightmapper uses the Embree raytracing library which is only compatible with x86_64 hardware. It is therefore not available on 32-bit Windows and Linux builds, nor on Apple Silicon (you can use Rosetta emulation to use the x86_64 version for baking lightmaps).
More rendering improvements:
- While there's so much rendering work being done for Godot 4.0, the 3.3 release got its fair share of improvements, thanks to the dedicated of contributors such as lawnjelly, Clay John (clayjohn), Joan, Hugo Locurcio (Calinou), Camille Mohr-Daurat (pouleyKetchoupp), NHodgesVFX, and more!

Some examples are:
- A new software skinning for MeshInstance to replace the slow GPU skinning on devices that don't support the fast GPU skinning (especially mobile).
- Optimized transform propagation for hidden 3D objects. While you might expect that a hidden node would not cost much in terms of performance, analysis showed this was not always the case. One aspect of this was transform calculations and housekeeping, which has now been greatly reduced in hidden nodes.
- Configurable amount of lights per object (and increase default from 8 to 32)
- Improved PCF13 shadow rendering in GLES2 by using a soft PCF filter
- Various light culling fixes
- And more! Search "rendering" in the changelog

Physics:
Many fixes to one-way collisions:
- This has been a long-term undertaking involving multiple PRs from multiple contributors, and a number of additional testers and reviewers, so kudos to them: Marcel Admiraal (madmiraal), Camille, bemyak, Rhathe, and more!
- One-way collisions prior to Godot 3.3 had many issues, some known for years but this code had the tendency to regress whenever a given issue got fixed. To solve this, in addition to some excellent debugging and bug fixing effort, Marcel and Camille designed thorough test cases so that the fixes could be validated in a number of different situations. The end result is a lot more reliable, though there are still a number of known issues which will require more fixes and more test cases to be fully ironed out.

Fixes to KinematicBody collisions:
- Camille, Marcel and Juan did significant work on long-standing issues with the reliability of KinematicBody collisions. One of the main changes merged for 3.3 is a change to KinematicBody's recovery after being stuck in a collider, affecting methods such as move_and_slide() or move_and_collide().
- As physics code is fairly sensitive and prone to regressions when trying to fix a given edge case, Camille made extensive physics test projects for 2D and for 3D, to help validate changes and prevent further regressions.
- Here too, there are still a number of known issues to address, and this will be one of Camille's main focus areas for 4.0 in coming months. Many of the upcoming bug fixes will likely be backported to the 3.x branch for future releases (e.g. 3.4).

Cylinder collision shape for GodotPhysics:
- As part of his Godot 4.0 work, Camille is implementing missing features in the GodotPhysics 3D backend to reach feature parity with Bullet. One of these was the support for Cylinder collision shapes, which has been implemented for Godot 4.0 and backported to 3.3. This is an experimental feature as of 3.3, as it hasn't received extensive testing yet and there are some known bugs in edge cases, so you can expect further fixes in Godot 3.4.

Editor:
Node copy-pasting:
- Being able to easily cut/copy and paste nodes sounds like a basic feature to have, but it is only now that it could finally be implemented in a reliable way, thanks to the hard work of Tomasz Chabora (KoBeWi). Previously, to copy nodes within the scene, they had to be duplicated and dragged under the desired parent. Moving nodes between scenes was only possible by using the clunky "Merge from scene" feature. Being able to copy nodes as easily as you can copy text was probably one of the most-wanted features since the first release of Godot!
- There were multiple attempts at implementing it, but it took time to refine them into someting reliable that could be merged, especially due to the need to take into account the full complexity of the scene tree (instanced scenes, editable children, shared or unique resources and subresources, etc.). In Godot 3.3, the dream has come true: nodes can be cut, copied and pasted, both within the same scene and between scenes. Manipulating the scene tree has never been this convenient.

Improved Inspector sub-resource editing:
- After much discussion, Juan Linietsky (reduz) implemented a change to the Inspector to better highlight sub-resources visually, so that it's easier to know which resource you're editing when there are more than two levels.
- This was implemented for Godot 4.0 but was fairly easy to backport, so here you go! The colors and contrast can be customized in the editor settings.

Import presets configuration:
- When you add assets to a Godot project, most of them get imported to engine internal formats on the fly based on options configured in the Import dock. There are some pre-existing presets for all asset types, and you can define which preset should be used for all resources of the same type (e.g. "2D Pixel" preset for textures), but until there was no easy way to configure all presets easily in a unified interface.
- For Godot 4.0, Juan implemented a new tab in the Project Settings dialog to configure those "Import Defaults", and this was backported to Godot 3.3.
- Additionally, a new "Keep" import mode was added to configure specific files to be left as-is (i.e. not imported) by Godot's import system. This is particularly useful for files which you intend to process yourself from scripts based on their raw contents (e.g. using the File API, loading it as text or bytes), such as CSV files used as database (as opposed to Godot's default CSV import preset as translation catalogs).

3D editor improvements:
Contributors such as Aaron Franke (aaronfranke), Joan and Hugo did a significant amount of work improving the usability of the 3D editor for 4.0, and most of it was backported to the 3.3 branch. This includes changes such as:
- Dynamic infinite 3D grid (further improved here)
- A much-improved 3D rotation gizmo, with increased opacity for better visibility
- A better 3D selection gizmo

Detect external scene changes:
- One of the biggest hurdles when working with Godot projects in a team was that it's very easy to overwrite changes made by another person if they modified a currently opened scene. How often did you pull changes from Git to only see them discarded, because Godot didn't detect that the scene had changed? While with scenes you just had to reload them, modifications to project.godot by another team member required you to restart the Godot editor to properly apply changes. This was especially problematic during game jams where multiple people work on the same small project simultaneously.
- Thanks to Tomasz again, with Godot 3.3, any external changes to opened scenes or project.godot, be it VCS pull or external text editor modification, are properly detected by the Godot editor and you get an option to either reload the affected files, discard the changes or do nothing (which in most cases means another prompt when the editor is re-focused).
- Do note that due to how built-in resources (resources saved within the scene instead of separate files) work, some of them might sometimes not get reloaded correctly (this especially applies to built-in scripts). It's a known infrequent issue, already fixed in Godot 4.0.

Scripting:
GDScript:
- No big change for GDScript in this release as all the focus has been on the rewrite and optimization of GDScript for Godot 4.0. Still, there's been a number of bugfixes which should make the experience more stable.

Mono/C:
- C# users will benefit from a redesign of the solution build output panel made by Ignacio Roldán Etcheverry (neikeq).
- There have been further fixes to the solution and build system, allowing users to target .NETFramework with the Godot.NET.Sdk and .NET 5. Moreover a 3.2.2 regression was fixed for System.Collections.Generic.List marshalling, and Unicode identifiers are now properly supported.
- There's also been extensive work on Mono compatibility with WebAssembly

Other areas:
Improved FBX importer:
- Gordon MacPherson (RevoluPowered) rewrote the prototypical Assimp-based FBX importer that we had in Godot 3.2 to support a lot of the more advanced features used in professional FBX-based workflows. You can read his devblog about it for details.
- In the current state, the new importer works quite well for FBX assets authored in Autodesk Maya. There are known issues with some other types of FBX models which are currently being addressed, and should be fixed in upcoming 3.x (and possibly 3.3.x) releases. If you have models that fail to import properly, please file a bug report so that we can investigate and solve it.

WebXR support for VR games:
- VR developers got a nice surprise back in September when David Snopek (dsnopek) landed a pull request to implement WebXR support in Godot's HTML5 port. Since it was merged earlier this year, we've seen a number of prototypes being developed with 3.3 RC builds' WebXR support, and we're eager to see what the community will create now that it's available in a stable release!

OpenXR plugin:
- As one of his first tasks as a new full-time developer, Bastiaan Olij (BastiaanOlij) worked on an OpenXR plugin for Godot 3.3, before focusing on rendering optimization for mobile Vulkan in the 4.0 branch. He built on the pre-existing effort by Christoph Haag (ChristophHaag), porting the Linux-only plugin to Windows, and implementing a first version of the the OpenXR action system. You can read more in this devblog.
- You can download the GDNative plugin directly from its GitHub repository.

MP3 loading and playback:
- We initially avoided the ubiquitous MP3 audio format for two reasons: it was patent encumbered, and less performant than alternatives like OGG Vorbis. Since the patents expired, and a good minimal open source implementation is available (minimp3), we finally decided to include MP3 support in the engine. This was implemented by DeleteSystem32.
- It is still not recommended for audio streams as OGG Vorbis is typically better, but it enables Godot projects to load pre-existing MP3 assets that they can't convert beforehand: assets streamed from the Internet, or loaded by the users from their system. So supporting the ubiquitous MP3 format with a tiny library ends up being quite useful.

New AspectRatioContainer Control node:
- Making dynamic UI with containers while keeping control of aspect ratio has been made very easy thanks to the new AspectRatioContainer Control node, implemented by Uģis Brēķis (UgisBrekis) and finalized by Andrii Doroshenko (Xrayez).
- This container resizes its child Control nodes based on two parameters: aspect ratio and stretch mode.

Minimap support in GraphEdit:
- Users of Visual Script and Visual Shaders, as well as developers relying on graphs in their game projects and editor plugins, will find this little UX improvement in Godot 3.3. At the end of the last year Yuri Sizov (pycbouh) added an often requested minimap to the GraphEdit control node. Located at the bottom right corner of the graph minimap allows to quickly find your way around even a very complex node structure.