
Godot 4.7: Stable Release Date, HDR & Key Features
Godot 4.7 stable shipped on June 18, 2026 . This article began as a review of the April beta; the feature history below is preserved, with the release status and HDR platform support updated against Godot’s 4.7 release notes and HDR implementation guide .
Godot 4.7 has been stable since June 18, 2026. Its April 24 beta reported 1,265 fixes from 309 contributors since 4.6-stable.
HDR output landed on Windows, macOS, Linux/Wayland, iOS, and visionOS. It requires the Forward+ or Mobile renderer. Android, Linux/X11, and Web remain unsupported, according to Godot’s HDR guide .
AreaLight3D, VirtualJoystick, and Vulkan ray-tracing groundwork close three long-running gaps. The first two are production-ready in 4.7; ray-tracing is plumbing only.
What 4.7 is and isn’t
4.7 is the polish-and-coverage release. 4.6 made Jolt Physics the default and brought back inverse kinematics ; 4.7 fills in the platform support and editor friction that 4.6 left untouched. Its first beta marked feature freeze, with 85 fixes from 47 contributors landing in just the two weeks between dev 5 and beta 1 .
This release took just under two months to move from beta to stable. Studios planning upgrades should check the current 4.7 patch release and test their own projects before switching.
4.7 is not a rendering rewrite or a new physics engine. The headline feature is HDR; the biggest editor change is that you can copy and paste inspector sections. This is a release that earns its keep by quantity, not novelty.
HDR output reaches desktop and Apple mobile
Godot rendered scenes internally in HDR before 4.7, but supported devices could not display the full range as HDR output. Version 4.7 adds output on Windows, macOS, iOS, visionOS, and Linux with Wayland. Linux/X11, Android, and Web remain unsupported; the Forward+ or Mobile renderer is required. Godot’s implementation guide explains the required drivers and project setting.
The platform work landed across several pull requests:
The Windows implementation waited two years for review and merge . The macOS, iOS, visionOS, and Linux/Wayland work followed. An HDR-capable display and operating-system setup are needed to see the result.
Phoronix’s coverage treats HDR as the most exciting item in the release, which is fair: it works without exotic compiler flags or C++20 escape hatches, which is more than the long-standing community HDR forks could promise.
What this changes for indies: if you are shipping a 3D game on Steam in 2026, your players with OLED monitors and modern HDR displays now see your game the way it was authored on every desktop platform Godot exports to.
AreaLight3D: rectangular real-time lights
The new AreaLight3D node renders real-time light from a rectangular surface in 3D space. Up until now, the only way to fake a soft ceiling panel or a window light source in Godot was to scatter several point lights and tune attenuation until it looked OK. That trick costs draw calls and never quite gets the falloff right at grazing angles.
Emil Dobetsberger contributed the implementation in GH-108219 , closing a four-year-old proposal . The first cut renders uniformly colored area lights; future work targets textured lights via a new PrefilteredTexture resource. For 4.7, expect:
| Feature | Status in 4.7 |
|---|---|
| Rectangular area light shape | Shipping |
| Real-time falloff and shadows | Shipping |
| Uniform color per light | Shipping |
| Textured area lights | Proposed for later |
| Disc and sphere area lights | Not in scope yet |
The practical reading: anyone doing interior 3D scenes, architectural visualization, or stylized 3D with soft lighting can now do it with one node where 4.6 needed three or four. The engine is still behind Unreal’s lit area light suite, but it is no longer behind Unity’s URP.
VirtualJoystick is finally built in
Mobile input on Godot has been a long-running source of friction . Every mobile project pulled in one of the community VirtualJoystick assets, each maintained by a different developer, each with subtly different APIs. New devs often picked the wrong one and rewrote their input code three times before shipping.
4.7 ships the official VirtualJoystick node, contributed by Kazox61 in GH-110933 . It supports three modes:
| Mode | Behavior | Best for |
|---|---|---|
JOYSTICK_FIXED | Stays put regardless of touch position | Classic dead-zone setups, twin-stick games |
JOYSTICK_DYNAMIC | Appears under the initial touch and snaps back when released | Smaller screens where screen real estate matters |
JOYSTICK_FOLLOWING | Follows the touch if it leaves the bounds | Long-swipe action games |
This single addition removes one of the rougher edges from Godot’s mobile pipeline. Combined with the SDL3 joystick driver for iOS in GH-114316 and Wayland touch support in GH-113886 , the input story on mobile finally has a default answer instead of three competing community plugins.
Picture-in-picture support on Android via Fredia Huya-Kouadio’s GH-114505 is a smaller change but a notable one for utility apps and second-screen experiences. Combined with native file picker support across all Android devices and Java interop from GDScript in GH-115498 , Android remains the platform where Godot is investing the most per release.
Vulkan ray tracing, sort of
Antonio Caggiano’s GH-99119 lands the low-level Vulkan ray-tracing plumbing: acceleration structures, ray dispatch, the basic API surface. It does not land production ray-traced shadows, ray-traced reflections, or a path tracer. What it does land is the ability to fire rays at all from inside the renderer.
Caggiano shipped a GDScript demo project to showcase the new functionality. That is the right scope for a first cut. Shipping a buggy ray-traced reflection probe in beta would have been worse than shipping nothing.
For studios that need actual ray tracing today, the NVIDIA-maintained Godot RTX fork remains the practical option. The 4.7 work is the foundation for shipping real ray-traced features in 4.8 or 4.9 without forking.
Lower-priority but worth flagging:
- Nearest-neighbor 3D scaling (Hugo Locurcio, GH-79731 ). Pixel-art 3D games stop being blurred by automatic bilinear filtering. Crisp at any resolution.
- DrawableTexture2D (Colin O’Rourke, GH-105701 ). A texture that can draw onto itself with blit calls, useful for paint tools and fog of war. The 4.7 class reference documents the API.
- Shader inline previews in the editor (Yuri Rubinsky, GH-117726). Live preview of text shaders without leaving the editor.
The little things that compound
The editor changes in 4.7 are unflashy and you will not notice any one of them. You will notice all of them by week two. The most-cited improvements from devs testing the beta:
Vertex snapping in the 3D editor (Robert Yevdokimov, GH-117235 ). Hold a modifier key, hover near a mesh vertex, place the next node exactly there. Level design has been waiting for this since 4.0.
Path3D collider snapping (Gustavo Jaruga Cruz, GH-102085 ). Snap path nodes to existing colliders. Useful for racing tracks and rail-shooter paths.
Inspector copy/paste sections (Raphaël Daubelcour, GH-111469 ). Copy an entire property section in one action instead of hand-copying each field.
Animation track collapsing (Malcolm Anderson, GH-113479 ). Group rows in the animation track editor. Once your character has 40 tracks, navigation without this was painful.
AwaitTweener (Tomasz Chabora, GH-79712 ). Tweens can await signals before progressing. The end of yield-driven cutscene callback chains.
Selective export template downloads (Tomasz Chabora, GH-117072 ). Stop downloading 600MB of templates you do not need. Pick the platforms you ship to, get only those. Forum user dragonforge-dev flagged this and the easier node movement as “my favorites so far” when testing the beta.
wasm64 and the web
Web exports got a quiet but meaningful upgrade: wasm64 support landed in GH-102378 . On browsers that support 64-bit WebAssembly, this raises the addressable heap limit beyond the 4GB ceiling that 32-bit wasm enforced. Most current browsers still default to 32-bit wasm, so this is a forward-looking change rather than an immediate win, but it is the right time to land it.
The HTML5 export remains the weakest of Godot’s platforms in absolute terms. Forum posts on web export issues continue to outnumber posts about any other platform. 4.7 does not solve this. It moves the ceiling up.
What you have to watch for
The release notes call out several compatibility breaks . The ones most likely to hit a real project:
- BlendSpace points handling. AnimationTree projects that wrote against specific BlendSpace internals will need to retest blend behavior.
- Audio spectrum analyzer. API change. Audio visualizer code may need adjustment.
- Keyboard and mouse device IDs. Numbering scheme changed. Code that hardcoded device IDs breaks.
- Particle angular velocity corrections. Particles using rotation will look subtly different.
- Shader preprocessor restrictions. Some macro patterns that worked in 4.6 no longer compile.
- OBB Android support removed (GH-118283 ). If your Android pipeline relied on the legacy OBB format, you need to migrate to Play Asset Delivery or PCK split before upgrading.
None of these are catastrophic. All of them require running a real test pass on a real project before changing versions.
The shape of the criticism
Not every reaction has been positive. The Hacker News thread on the 4.7 announcement attracted the long-standing critique of Godot’s project priorities , summarized by strix_varius:
“Godot is so driven by whatever sounds neat to work on that it has three completely different rendering systems, all buggy and mediocre. At least two shipped tilemap systems, one deprecated.”
This is not a bad-faith complaint. The Forward+, Mobile, and Compatibility renderers do diverge in feature support, and the TileMap to TileMapLayer migration is messy in 4.3+. 4.7 does not address either issue. The editor and rendering improvements in this release are real, but they sit on top of an architectural sprawl that the team has not yet pruned.
The other side of the thread was less ambivalent. barcoder summed up the reason most developers stay:
“I just love how Godot itself is under 100mb. Even as the project grows I hit play and it instantly loads.”
Both reactions are correct. Godot ships more features per release than any other open-source engine and has more accumulated rough edges than any other open-source engine. 4.7 widens the lead on both.
Should you upgrade?
Upgrade now if: You are starting a new mobile project (the VirtualJoystick alone is worth it), you ship 3D on desktop and care about HDR, or you have an editor workflow that hits the inspector copy/paste pain daily.
Wait if: You have a shipped 3D project on 4.6 with custom shader preprocessor macros, or your Android pipeline still uses the legacy OBB format. The breaking changes will bite you.
Evaluate: If you are deciding between Godot and another engine for a 2026 project, the gap to Unity is materially smaller in 4.7 than it was in 4.5. HDR coverage, AreaLight3D, VirtualJoystick, and Vulkan ray-tracing groundwork are all features the comparison turned on a year ago.
The pattern from 4.6 holds in 4.7 : the engine is no longer the slow half of an indie pipeline. For studios pairing Godot with an AI agent like Ziva , the productivity ceiling in 2026 is higher than the same combination would have offered in 2025, mostly because the engine stopped being the bottleneck.
4.7 is not the release that makes Godot interesting. 4.6 was that release. 4.7 is what makes 4.6’s bet pay off on the desktop platforms 4.6 left behind.