Major improvements ahead!
Mobile games represent about half of global game revenue and are the largest market segment for games, ahead of consoles and PC. In terms of user base, that share is even higher. From the latest Godot community polls, about 49…

As we edge ever closer to feature freeze, many of our contributors have been hard at work to get their highly-anticipated features in hopes of Godot 4.7 integration. Fortunately for them, we’ve managed to accomodate several of these proposals, and are excited to showcase them today! Your testing will be crucial to ensure that everything listed stays in scope for a 4.7 release, so be sure to give this latest build a spin after the highlights

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.

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, the XR 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 Poke ALL Toads, a puzzle game starring mischievous fairies on a queat to poke ALL toads. You can buy the game on Steam, and follow the developer on Bluesky, YouTube, or itch.io.

Highlights

Rendering: Add nearest-neighbor scaling

We’re starting things out with one of the most anticipated integrations for our rendering system: nearest-neighbor scaling for 3D viewports. Over the course of nearly three years, Hugo Locurcio has been refining GH-79731 to ensure that 3D titles with pixel-art aesthetics or lower resolution scaling will still look crisp without any compromise to performance:

Bilinear

Nearest (new behavior)

GUI: Add custom_maximum_size property to Control

Our previous development snapshot had a large focus on GUI improvements, and that QOL continues with the new custom_maximum_size property for Control. Enzo Novoselic in GH-116640 has at last brought us the maximal equivalent to the existing custom_minimum_size, enabling the fine-tuning of GUI element sizes to their full potential.

GUI: Improve drag and drop in Tree

vaner spear-headed GH-112993 in order to improve the overall usability and intuitiveness of Tree drag-and-drop functionality. Now when performing a drag-and-drop operation, there will be an always-present vertical indicator showing the potential parental chain, leveraging a standalone CanvasItem to prevent StyleBox occlusion.

Old	New

What’s more, this operation will now consider the x-position of the cursor while determining a to-be parent when in indent space (leftmost, empty space), whereas item space largely retains current behavior. This implementation mirrors what one would commonly find in vector design software.

Editor: Increase available space for array properties

Have you ever wondered why the inspector takes up so much negative space when working with arrays? Turns out it wasn’t done deliberately; it just so happened to be using the default offset of 0.5! Tomasz Chabora rightfully found this quite silly, and whipped up GH-118008 to rectify this oversight.

Old	New

And more!

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

• 2D: Rework TileSet editor proxy objects (GH-117574).
• 3D: Add vector components to 3D ruler tool (GH-106785).
• Editor: Add folding to the Visual Profiler tree (GH-118120).
• Editor: Add type filters to create dialog (GH-111518).
• Editor: Hide renderer selector in main editor window and add editor setting (GH-117754).
• Editor: Make right-clicking on unfocused scene tabs possible (GH-112919).
• GDExtension: Allow viewing GDExtensions from inside project settings (GH-118063).
• GDScript: LSP: Calculate simple string insertions on the server-side (GH-117710).
• Particles: Fix angular velocity (GH-117861).
  • NOTE: This is technically compatibility-breaking, but it’s bringing the functionality in-line with how its always been documented.
• Particles: Fix particles moving when timescale is 0 (GH-109911).
• Platforms: Android: Allow implementing java interfaces from GDScript (GH-115498).
• Platforms: Windows: Implement OneCore TTS support using C++/WinRT (no deps) (GH-116349).
• Platforms: Windows: Use OneCore/WinRT emoji picker when available (GH-116351).

Changelog

88 contributors submitted 188 fixes for this release. See our interactive changelog for the complete list of changes since 4.7-dev3. You can also review all changes included in 4.7 compared to the previous 4.6 feature release.

This release is built from commit 755fa449c.

Downloads

Standard build includes support for GDScript and GDExtension.

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

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 and 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.

Donate now

We support now loading models in PLY format, commonly used for 3D scanning and printing. We support all common variants, which means ASCII and binary with any endianness. We support both models with faces (loaded to ) and without (loaded to ). As usual, “support” means we support them everywhere in our engine and tools. …

Continue reading ➤

We’re happy to showcase a project that released last year, but was long in the making. The folks at Xibbon have been working hard to port the Godot Engine to the iOS platforms. Not only did they port the editor to make it run on iOS, they successfully interfaced the editor with a custom iOS interface in order to make the engine match Apple strict UI and UX guidelines. Using their app on the iPad and iPhone feels totally native, because it is!

Xibbon has been active in our community, in terms of code contributions and events. Xibbon has been our sponsor at events, such as the first GodotCon in the US!

Today, Miguel de Icaza, known for starting the GNOME, Mono, and Xamarin projects, is sharing with us his experience developing his iOS app.

---

Can you tell us a little bit about your project?

Xogot brings the Godot Editor to the iPad and the iPhone as a native iOS application.

Xogot uses the Godot Editor and the Godot Engine, but we provide an alternative user interface and shell that is built on top of Apple’s native user interface elements. We tuned the user experience to be both touch friendly and to work with the more limited screen space on these devices.

By being a new user interface on top of the existing Godot Editor, we remain compatible with the desktop Godot and users can move seamlessly between the platforms, but we also wanted to make a product that truly belonged on the iPad, not merely running the desktop experience on the iPad.

While I am an engineer, the joy that I derive from using creative apps on the iPad is unmatched.

Interacting with the world with our fingers is one of the earliest skills that we acquire as babies – and I find the physical feedback of using touch user interfaces to be very rewarding. Not only do I spend hours playing with my iPad, I also love watching creators use their iPads for sketching, drawing, modeling, composing, editing videos, and building games.

Why did you want to build Xogot?

Xogot is very much a labor of love, the result of a perfect storm of conditions and a way of expanding our own horizons and getting out of our comfort zone.

We have worked on the mobile world for almost fourteen years, and built developer tools for helping .NET developers target mobile platforms. Mostly building IDEs and tools and supporting others on their adventures to bring software to users (among those, funding the early effort to bring .NET to Godot).

We wanted to get out of our comfort zone, and build an end-user product that followed the ethos of iOS developers that obsess over highly polished apps. Products that obsess over the details of the user experience and strive to create delightful user interfaces.

For almost sixteen years we have helped folks in the game industry adopt .NET for game development, and we supported various games, engines, and hardware vendors with their efforts to bring our compilers and tools to their systems. Just like we were inspired by the iOS community, we are inspired by the game developer community – people pouring their hearts out exploring ways of entertaining and surprising us, and we wanted to get closer to this joyful world.

Lastly, we all witnessed a major turning point in the game-engine industry when Unity’s leadership made decisions that shook developer trust across the community. We watched as the industry rushed to find alternatives – and being emotionally invested already in Godot, we were very much in the camp “How can we give the Godot community an edge?”.

What was challenging about bringing the Godot Editor to the iPad and iPhone?

This is the poster child of a slippery slope, or an extreme case of Yak Shaving.

There are three buckets of challenges:

• Multi-process
• User experience
• Embedding

At first, we figured “How hard could it be to get Godot on the iPad?” and it turned out that running Godot on iPad was quite simple, but comes with some strings attached. The first thing you have to deal with is that the Godot workflow uses three processes: the home screen that creates new fresh Godot Editors on demand, the Godot Editor itself, and every time you press “play”, a new and fresh instance of Godot.

The challenge is that iPadOS does not really support the above model where you get a fresh new process for each step, instead you get a single process and you get to live there. Without being able to launch a new project, Godot would have worked, but would not have been very interesting to people.

We first experimented with a proof of concept which was to reset the state of Godot to one of a fresh process. That worked, and it allowed us to edit one game, and then edit a second one. We called this the “reset state” effort. That was still not quite useful. The second stage was to make the editor run a child process, and for that what we did was to “virtualize” every single global variable in Godot, so we could run multiple instances simultaneously. That turned out to work great, but it relied on a very manual process of editing a very large chunk of Godot to remove every access to globals and static variables. We later invested in a clang-based rewriter that would take an existing Godot codebase and produce a virtualized Godot on demand. This is what we are based on now.

With the above system we could open multiple projects, but also start and stop the game under development over and over. So we were now cooking with gas. One last component was not just to launch separate instances of Godot, but having those run side-by-side, which was necessary to implement debugging over a “virtual” process that happened to be running on your same address space.

We took the limitations of the platform as a fun challenge to solve, and I am incredibly proud of the result.

That was a very satisfying technical problem to solve, but it did not lend itself to a great iPad experience. Godot is designed for a desktop computer where you have a lot of space, and you can easily aim your mouse at small user interface elements. On the iPad and iPhone, Apple recommends that elements are at least 44 points in size for users to be able to interact with them comfortably. In fact, every time I thought I could get away “just this time” with a smaller user interface, I found out the hard way that neither our users nor myself could tap it. We repeatedly learned that lesson.

44 points.

It is now hanging on a printed piece of paper next to my desk, so I do not forget.

But even if we resized the controls, the user interface did not feel good on the iPad. Godot was clearly intended to be used with a mouse and a keyboard, so we set out to solve the most problematic areas for our users. Some were mechanical, like “make this button larger” or “display this elsewhere”, but some were more philosophical. In my previous experience with the GNOME desktop, we pursued a path similar to Godot. That is, we tried to deliver a user interface, but whenever there were disagreements about the intended behavior, rather than making an editorial or design decision, we offered a choice. Or three. Or four. Or five, or as many choices as there were opinions.

Offering choices sounds great on paper, but is terrible in practice. Options can paralyze users, but each option forces you to test two codepaths – and that is if you are lucky, if you have options that interact with other options. Now you have to test combinations of those features, and so on. And then you get to document all these combinations.

We wanted an application that lived up to the ethos of great iOS applications. We felt that we had to act as editors and make design choices that surfaced the right defaults, and we opted to only surface what we felt was necessary.

Overall, I think that we did a pretty good job, but every once in a while, our users would complain and make a case for why they really needed an option. So, in those cases, we have brought back a level of configuration or re-surfaced elements that were previously not shown.

Our design process was documented in our blog, and you can see our process and some of the iterations on the concepts over time.

We initially thought we would only touch on a couple of pieces, the scene pad, the file pad – and over time we found ourselves rewriting almost all of the user interface in Godot, both because it felt so much better, but also as users struggled with different parts of the UI. This is a process that has been both extensive, but also quite enjoyable – as SwiftUI has made this a delightful exercise.

At first, we just layered a new UI on top of the Godot Editor, and we customized Godot to show fewer UI elements when running. This served us well for a while, but at some point we found ourselves needing to “host” parts of the Godot UI in SwiftUI views that we controlled, like the bottom bar panels, the plugins that render inside the inspector, as well as having a fallback for custom Godot user interface code – and for that we used a system that allows us to “rehost” parts of the Godot UI – but having this was important to fully take control of the user experience, while ensuring that everything you need to work with Godot was still there.

Adapting Godot from a desktop application into a pleasant, touch-first, iPad application was a lot of work, and we were convinced there was no more shrinking or adjusting in our future. But even during the beta period before we launched the iPad version, our testers kept asking us for an iPhone version. We were not convinced that this was necessary, but our users kept telling us all the reasons why they would want this – tuning their apps, experimenting on the go, testing an idea during small breaks, adjusting some properties of their game during their bus or train ride or during their lunch breaks.

But there is a big gap between what people tell you they want and what they are actually going to do, so we remained skeptical for a long time. The first time we reconsidered this was when we heard a presentation from Chad Stewart on using Godot on Android where he shared his real-life experiences doing his work on the go. Then the Godot foundation shared information about usage of Godot on Android, on phones and tablets – and it was then that we grasped that for some folks their phone is their sole computing device. So not only was this possible, for some folks it was a necessity.

So, delivering the full Godot Editor on iPad and iPhone has meant more than just porting a desktop app. To meet App Store requirements and match Apple users’ expectations, we rebuilt the interface to be truly native and touch-first – something that feels at home on touch devices rather than adapted for it.
Xogot has been a multi-year effort and a significant engineering investment. It’s a commercial product created by a small team deeply passionate about both Godot and Apple platforms. Xogot includes a free tier open to everyone, with the complete version provided at no cost to students and contributors to the Godot open-source project.

What are the biggest differences between the Xogot and the Godot Editor?

Xogot has two major limitations. First, it can not run third-party plugins authored in native code, or run .NET code. The reason for the former is that Apple’s security system does not allow for third-party dynamic code to be loaded into a process, so all of these plugins fail.

And the ability to run .NET code is not something we have worked on.

Considering the improvements made to adapt to the new form factor, are there any plans on bringing Xogot to other platforms?

We want to bring Xogot to the Apple Vision Pro. Anecdotally, just before we decided to embark on bringing Godot to the iPad, we were working on building frameworks and games for the Vision Pro. We were going to our first Boston Unity meeting to learn more about Unity and Vision when the Boston Unity group disbanded in response to Unity’s license changes. It was in this turmoil that we were inspired to jump headlong into the Godot world.

The idea of building and testing immersive experiences directly inside the headset feels like a natural extension of what we have done so far – creating something with your hands, right in front of you, makes the process feel immediate and physical. But like the iPad effort, there are a number of very interesting problems to solve there before we can ship a product that would meet the expectations of users, so we are going to have to work through those.

We don’t currently have plans to bring Xogot to non-Apple platforms. Our focus right now is on delivering the best possible experience on iPhone and iPad, and continuing to refine what it means to build games natively on Apple’s devices. So you will see us iterating on the experience and incorporating user feedback until we can score ourselves one of those Apple Design Awards.

That said, Godot already runs on many platforms, and we see Xogot as part of that larger ecosystem. For now, our aim is to deliver a great experience to game developers on the Apple platforms, and to maintain a high level of compatibility with Godot so that both environments can complement each other.

Were there some improvements made in Xogot that made it upstream?

Our biggest contribution so far has been the LibGodot effort, which is a major investment we’ve been funding with the development work led by Migeran. LibGodot makes it possible to embed Godot inside modern applications, and Migeran is now in the process of getting it upstreamed so it can benefit the broader community.

We’ve also contributed a number of smaller patches and fixes, and we’re continuing to learn what it takes to shepherd contributions through the review and merge process. Looking ahead, we expect to contribute larger components as well. We already have a few ideas in mind. But as we’re still relatively new to the game development community, we want those contributions to be shaped by what we learn as Xogot and its user base continue to grow.

I would love to participate more directly in Godot’s workgroups and community discussions. Balancing that with running a company and raising three kids can be challenging, but I have enormous respect for the dedication and care of the Godot team. My hope is that over time we can contribute not just code, but also ideas and processes that help strengthen the community.

What’s next for Xogot?

We’re especially excited about Xogot Connect, our new open-source Godot add-on that lets developers on Windows, Linux, or macOS easily run and debug their projects on iPhone or iPad without the usual complexity of exporting to iOS, building in Xcode, or managing provisioning profiles.

Our goal is to keep expanding that bridge between desktop and mobile development. Xogot Connect already makes it simple to configure on-screen controls in your game by enabling the iOS Virtual Controller in Project Settings, and we have a few more ideas like this in the works that bring the mobile-specific affordances we’ve developed for Xogot directly to Godot developers on the desktop and make targeting mobile smoother and more approachable.

---

I would like to thank Miguel de Icaza for sharing with us the experience of his ride of adapting the Godot Editor specifically for a new platform.

You can easily find Xogot in the App Store or at its homepage.

Also, don’t forget to check out Xogot Connect in the Godot Asset Library. (Expect it to be also in the upcoming Asset Store!)

While the majority of our team continues to focus on development snapshots for Godot 4.7, we still have a commitment to maintenance releases for the latest stable version. Specifically, our release support policy promises active support until the successor’s first patch release, so there’s still room for yet more maintenance releases in the future. As for now, we’d like to thank everyone who took the time to evaluate and ratify our release candidates for Godot 4.6.2.

Maintenance releases are expected to be safe for an upgrade, but we recommend to always make backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.

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.

Download Godot 4.6.2 now or try the online version of the Godot editor.

---

The cover illustration is from Bombun, a wholesome 3D platformer where you guide Bombun, a bomb-throwing bunny, on a mission to defend her floating fortress from a friend-turned-foe. You can buy the game on Steam, and follow the developer on Bluesky or itch.io.

Changes

61 contributors submitted 122 fixes for this release. See our interactive changelog for the complete list of changes since the 4.6.1-stable release.

• 3D: Fix 3D focus selection for subgizmos (GH-116972).
• 3D: Fix DirectionalLight3D property list (GH-117189).
• Animation: Check playback_queue existance after emit animation_finished signal (GH-116676).
• Animation: Deselect bezier keyframes when switching animations (GH-116953).
• Animation: Fix timeline cursor following mouse during marker selection (GH-117634).
• Animation: Fix visual shift of animation editor keys during selection (GH-117290).
• Core: Fix String::split_ crash on empty string (GH-117353).
• Core: Fix editable children state when duplicating instantiated nodes (GH-117041).
• Core: RingBuffer: Fix T read() method reading empty buffer (GH-117388).
• Core: RingBuffer: Fix overreading on methods that take an offset as an argument (GH-117151).
• Editor: Fix build profile generator creating bogus profiles (GH-115410).
• Editor: Fix mute button after pausing and stopping (GH-116537).
• Editor: Fix theme item inspector tooltips for Window subclasses (GH-115245).
• Editor: Set accessibility name on Tree inline cell editor when editing (GH-117135).
• Editor: Stop autocomplete from eating words by default (GH-117464).
• Export: Android Editor: Copy keystore to temp file during export (GH-116161).
• GDExtension: Add missing GDVIRTUAL_BIND(_get_supported_extensions) on MovieWriter (GH-117479).
• GUI: Fix “Custom” anchor preset being ignored if the parent isn’t a Control (GH-117488).
• GUI: Fix RichTextLabel drag selection not working after double-click (GH-117201).
• GUI: TextEdit: Fix clipping of last character due to right margin rounding (GH-116850).
• GUI: TextServer: Ignore language of embedded object replacement spans when updating line breaks (GH-116197).
• Import: Blender attempts should be incremented to avoid endless loop (GH-116589).
• Physics: Jolt Physics: Make MoveKinematic more accurate when rotating a body by a very small angle (GH-115327).
• Physics: Jolt Physics: Rework how gravity is applied to dynamic bodies to prevent energy increase on elastic collisions (GH-115305).
• Physics: Jolt Physics: Swapping vertices of triangle if it is scaled inside out (GH-115089).
• Platforms: Android: Fix FileAccess crash when using treeUri in Gradle-built apps (GH-117131).
• Platforms: Fix macOS Steam time tracking lost when opening a project (GH-117335).
• Platforms: iOS: Add UIScene lifecycle events (GH-116395).
• Platforms: iOS: Propagate VC UI preferences to SwiftUI hosting controller (GH-116633).
• Platforms: macOS: Enable wake for events if Magnet is running (GH-116524).
• Platforms: Wayland: Improve mapping robustness and synchronization (GH-117385).
• Platforms: Windows: Set current driver when ANGLE init fails (GH-117253).
• Rendering: Apply fixed size properly for mono/stereo rendering (GH-115147).
• Rendering: Fix accidental write-combined memory reads in canvas renderer (GH-115757).
• Rendering: Fix Tangent decoding detection when computing vertex skinning (GH-117401).
• Rendering: Fix viewport debanding not working with spatial scalers (GH-114890).
• Rendering: macOS: Force ANGLE (GL over Metal) when running in VM (GH-117371).

This release is built from commit 001aa128b.

Known incompatibilities

As of now, there are no known incompatibilities with the previous Godot 4.6.1 release. We encourage all users to upgrade to 4.6.2.

If you experience any unexpected behavior change in your projects after upgrading to 4.6.2, please file an issue on GitHub.

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 and 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.

Donate now

This a bit non-standard news post: I wanted to announce a new release of PasDoc, documentation generator we use to create Castle Game Engine API docs. PasDoc is a documentation generator for Pascal source code. Documentation is generated from comments found in the source code (or in special description files). We support many output formats, …

Continue reading ➤

Following hot on the heels of the last snapshot, the third development snapshot for what will become Godot 4.7 is now out! This snapshot comes packed with some long-awaited features, some of which may transform the way you design GUIs in Godot. As always, we need as much testing as possible to ensure everything can be stabilized.

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.

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, the XR 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 Lucid Blocks, a game where you explore, build, and survive in a cryptic expanse oozing with dreamlike oddities and esoteric critters. You can buy the game on Steam, and follow the developers on Bluesky, YouTube, or Discord.

Highlights

GUI: Add transform offset to Control nodes

One of the most long-awaited features in Godot’s GUI system is to be able to translate, rotate, or scale a Control node without it affecting the rest of the container. This is most notably used for animation purposes, so that buttons can smoothly slide in view or fade away with a scale change.

However, Godot’s various Container nodes apply the position, rotation, and scale to their children, which means any changes made to the children’s transform is lost when the container is sorted again (which occurs when children are added, removed, or moved in the scene tree). The new transform offset properties implemented by Timo Schwarzer in GH-87081 aim to address this limitation in a self-contained manner, similar to the transform property in CSS.

You can choose whether the transform offset affects mouse input. By default, transform offset is purely visual, which means there is no risk of buttons losing their hover status after being transformed. Controls with a transform offset applied show their original bounding box with a gray dotted rectangle:

GUI: Implement search bar for PopupMenu

As a tool that can be used to create complex projects, Godot is no stranger to popups with dozens of options to choose from (if not more). While incremental search can be used to focus the first item that starts with a given letter (by pressing the letter in question), this can be difficult to use as incremental search lacks visible feedback once you perform it.

To resolve this longstanding usability quirk, Alexander Streng added search bars to PopupMenu in GH-114236. This is particularly useful for long lists such as animations, skeleton bones, inspector dropdowns for Resource properties, and more. A visible search bar also makes searching more discoverable, which is a win for usability.

This feature is available in any PopupMenu node, which means it can also be used in projects such as non-game applications.

Editor: Add vertex snapping to the 3D editor

One of the most keenly awaited features to improve 3D editor usability is finally here! Robert Yevdokimov implemented vertex snapping in the 3D editor in GH-117235. This allows you to snap the selection to nearby nodes’ vertices, which is useful for level design and ensuring everything is visually connected to neighboring nodes.

To use vertex snapping, hold B and move the mouse near the selection’s vertices. Once you see a yellow circle, hold the mouse button and move the mouse to the desired location (you can release B at this point). The circle becomes green once a vertex to snap to is detected near the mouse cursor. For better depth perception, the yellow/green circle appears with reduced opacity if it’s occluded by another surface.

Vertex snapping works differently depending on whether the selected node has a mesh-based representation or not. For example, MeshInstance3D and CSG nodes have a mesh-based representation, while other nodes such as Label3D and Marker3D do not. Nodes without a mesh-based representation will teleport to the highlighted vertex when holding B and clicking on another node’s vertex. Thanks to the follow-up contribution GH-117380, you can opt into this behavior for nodes that have a mesh-based representation too.

Editor: Use class name instead of Object ID in remote scene view

The remote scene tree is very useful to diagnose what’s going on in a running project. However, until now, everything was shown as a bunch of anonymous-looking Object IDs. Jayden Sipe has improved this view by adding class names in GH-115738, making this tool significantly more useful.

Before

After

Editor: Create a proper editor for MeshLibrary

GridMap users rejoice! The MeshLibrary resource (which stores tiles that can be used in a GridMap node) can now be edited much more easily, thanks to the work of Michael Alexsander in GH-117376.

This new bottom editor comes with the following features:

• Presentation of items in a grid, with search and zooming.
• Editing of individual items in a separate inspector.
• Full undo/redo for all actions.
• Fallback preview to an item’s mesh in case none was specifically set.

Here’s an example of what it looks like:

Android: Add support for picture-in-picture

Thanks to the work of Fredia Huya-Kouadio in GH-114505, Godot now has the ability to run a project and move it to a small window pinned to one of the screen corners. This relies on Android’s native support for picture-in-picture (PiP) display. For example, YouTube on Android uses this functionality to show the currently played video in a corner of the screen.

Note that picture-in-picture does not permit interacting with the application while it is in this mode, so this feature is most useful for applications and games that have sections that don’t require real-time input (idle games, autobattlers, etc.).

Picture-in-picture functionality can be enabled in two ways:

• Explicitly by calling DisplayServer.pip_mode_enter().
• Configured to happen automatically by calling DisplayServer.pip_mode_set_auto_enter_on_background(). In this case, the app will automatically go into picture-in-picture mode when the user presses the home button or uses the home gesture on their device.

As an example, since this ability can be toggled at runtime, you can allow picture-in-picture mode to engage when a cutscene starts and disable it when returning to interactive contents.

Here’s an example of it in action on the game Rift Riff, where PiP mode is only enabled during one of the game’s waves:

Android: Enable orientation change in Script Editor

The improvements for Android don’t stop there. Thanks to the work of Anish Kumar in GH-117109, you can now switch to portrait mode while in the script editor on Android devices. This makes it easier to view code while you’re typing on a virtual keyboard. Note that distraction-free mode must be enabled for this to be possible (it can be toggled). This restriction has to be in place, since the side docks take a lot of horizontal space and the script editor in portrait mode wouldn’t be practical with the side docks visible.

Linux/*BSD: Support HDR output

Continuing from the previous development snapshots which added support for HDR output on Windows and Apple platforms, we have added support for HDR output on Linux when using the Wayland display server (GH-102987). Kudos to ArchercatNEO for their dedication to developing and maintaining the Wayland support alongside the Windows and Apple PRs for more than a year!

Also of note is that documentation on HDR output is now available. Check it out! A demo project for testing HDR output will follow soon.

And more!

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

• 3D: Add automatic smoothing for CSG nodes (GH-116749).
• Animation: Optimize Animation Resource, Library, Mixer, and Player (GH-116394).
• Animation: Optimize AnimationTree, Improve internals & Editor & Node::process_thread_group safety (GH-117277).
• Core: Improve thread-safety of Object signals (GH-117511).
• Core: Use TRACY_ON_DEMAND by default for Tracy integration (GH-1117583).
• Editor: Add View3DController for editor 3D view manipulation (GH-115957).
• Editor: Add 3D vertex snap base setting (Vertex/Origin) (GH-117380).
• Editor: Depict version discrepancies in Project Manager (GH-111528).
• Editor: Generate and display documentation for the properties generated by PropertyListHelper (GH-115253).
• Editor: Reorganize Output dock (GH-112690).
• Editor: Revamp autoload creation (GH-91124).
• Editor: Stop autocomplete from eating words by default (GH-117464).
• Editor: Support folding, groups, and subgroups in remote scene inspector (GH-117357).
• GUI: Add triple-click paragraph selection to RichTextLabel (GH-116868).
• Input: Add project setting to ignore joypad events if the app is unfocused (GH-115119).
• Platforms: Add haptic feedback on long-press right-click in the editor (GH-117198).
• Platforms: Enable wake for events if Magnet is running (GH-116524).
• Rendering: Add fast path to Polygon2D (GH-117334).
• Rendering: Add scale 3D and rotation 3D in particle process (GH-1112447).

Changelog

113 contributors submitted 297 fixes for this release. See our interactive changelog for the complete list of changes since 4.7-dev2. You can also review all changes included in 4.7 compared to the previous 4.6 feature release.

This release is built from commit 778cf54da.

Downloads

Standard build includes support for GDScript and GDExtension.

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

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 and 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.

Donate now

What’s Changed

Fix a regression in 3.10.0-alpha2 that caused an Exception when registering classes to the Serializer (Commit f4a0bad & Commit 44ced3d)
Hardened memory allocator for jme by @riccardobl in #2639
Fix SPTerrainLighting.frag missing Spe…

NOTE: This version contains a major regression that may cause Exceptions when registering classes to the Serializer. An alpha3 release has been deployed to fix this, and you should use that instead.
What’s Changed

LWJGL 3.4.1 by @yaRnMcDonuts in #2598…