Godot 4.7 Quietly Became the Most Complete Open-Source XR Engine Yet. Steam Frame and Android XR Are Now First-Class Targets.

Every so often an open-source project stops being the scrappy alternative and just becomes the obvious choice. Godot has been inching toward that line in XR for two years now, and with version 4.7 it finally crosses it. This release, nicknamed "Lights, Camera, Action," landed in June with more than 1,265 fixes from 309 contributors, and buried under the headline features (real HDR output, a brand new Asset Store, the AreaLight3D node) is the most complete XR story the engine has ever shipped. If you build for headsets and you have been waiting for a reason to take the free engine seriously, this is it.

I covered Godot 4.6 back in April, when the big deal was OpenXR 1.1, frame synthesis, and a universal APK that ran on every OpenXR headset from a single build. That release made Godot XR viable. 4.7 makes it comfortable, and it does so by fixing the unglamorous things that actually decide whether a project ships.

Steam Frame and Android XR are now first-class targets

The most forward-looking line in the release notes is that Godot 4.7 is production-ready for Valve's Steam Frame, the standalone SteamOS headset arriving this summer. Godot is one of the very first engines committing to day-one support for a platform that has not even shipped to consumers yet. That matters because the alternative, waiting six months for tooling to catch up after a headset launches, is exactly how good hardware ends up with a thin content library. An open-source engine can move at the speed of its contributors instead of the speed of a corporate roadmap, and here that speed is the whole advantage.

Android XR gets the same production-ready treatment. Samsung's Galaxy XR platform has been the year's big spatial-computing storyline, and Godot now targets it through the same OpenXR pipeline it uses everywhere else. Add improved OpenXR composition layers, which give you crisp text and UI panels rendered at their own resolution instead of getting smeared through the main render, and the practical result is that one Godot project can reach Quest, Steam Frame, Pico, and Galaxy XR without you maintaining four forks of your code.

Foveated rendering that actually saves you memory

Here is the change I am most excited about, and it is the kind of thing that never makes a headline because you cannot screenshot it. Godot 4.7 adds Vulkan subsampled images to the Mobile renderer. In plain terms: when you use foveated rendering, the headset renders the edges of your view at lower resolution because your eyes cannot see fine detail out there anyway. Until now, Godot still stored those low-detail tiles at full size, so you paid the memory-bandwidth cost even though the pixels were blurry on purpose. Subsampled images store the reduced tiles at their reduced size and interpolate on the way out, which cuts memory bandwidth exactly where standalone headsets are most starved for it.

The consequence is a quiet but meaningful reversal. The release notes now recommend that new XR projects use the Mobile renderer, not the Forward+ renderer that desktop developers reach for by default. For anyone who has fought to hold 72 or 90 frames per second on a mobile chip, this is the difference between shipping and shelving a project. It is also a great example of why I keep pointing people at open source. This optimization came from contributors who ship XR games and felt the pain firsthand, not from a checkbox on a feature-parity spreadsheet.

Less boilerplate, more building

Godot 4.7 also cleaned up the first thing every new XR developer trips over: the action map. Previous versions dumped more than ten controller profiles into every new project, one for each headset vendor, and left you to sort out which bindings you actually needed. The new release leans on OpenXR's generic controller profile, so a fresh project ships with a sane default of just the generic profile, the Touch controller profile, the Pico 4 profile, and hand interaction. You can still add whatever else you need, but you are no longer staring at a wall of vendor-specific inputs before you have moved a single object.

Rounding out the release is the stable launch of the Godot Android Build Environment, or GABE, a companion app that finally makes exporting, signing, and deploying Android builds a straightforward process instead of a Gradle scavenger hunt. Since every major standalone headset runs on Android under the hood, a smoother Android export path is a smoother headset export path. Pair that with the new Asset Store, and the on-ramp for a first-time XR developer has never been shorter.

Why this keeps mattering

None of these features is flashy on its own. Nobody buys a headset because a game engine improved its memory bandwidth on foveated tiles. But taken together, 4.7 removes the last few excuses for not building XR in Godot. It is free, it is MIT-licensed, it now targets every headset that matters through one codebase, and it is fast enough on mobile silicon to actually ship. Meta has been funding the maintainers, Valve is clearly working with them closely enough to earn day-one Steam Frame support, and the contributor count keeps climbing. That is what a healthy open-source project looks like when the industry finally decides it needs one.

If you have been meaning to try XR development and the cost of a commercial engine license was the thing holding you back, download 4.7, plug in a headset, and give the Mobile renderer a spin. The barrier to entry just dropped again, and in open source, that barrier only ever moves in one direction.