Godot Engine VR Development Log: Lessons and Pitfalls from Porting to PSVR2

Introduction: Is It Viable to Make VR Games with an Open-Source Engine?

In the VR game development space, Unity and Unreal have long dominated, while the open-source engine Godot is often seen as a choice for 2D and lightweight 3D projects. However, an increasing number of indie developers are attempting to develop and ship VR games using Godot, even porting them to Sony's PSVR2 platform. A recent article titled "Shipping Godot VR and Porting to PSVR2: A Partial Post Mortem" is a real-world account of this emerging trend.

Although the author labeled this post mortem as "Partial," it reveals an important signal: Godot, as a free and open-source engine, is being seriously used for the full lifecycle of commercial VR projects—from development and release to cross-platform porting. For developers interested in open-source tool ecosystems and VR technology deployment, this kind of frontline experience is extremely valuable.

Godot's Role in VR Development

Current State of VR Support in Open-Source Engines

Since version 4.0, Godot has significantly enhanced its 3D rendering capabilities by introducing a modern rendering pipeline based on Vulkan, laying the technical foundation for performance-demanding scenarios like VR. Vulkan is a next-generation graphics API maintained by the Khronos Group that provides lower-level hardware control and significantly reduced CPU overhead compared to its predecessor, OpenGL. In VR scenarios, the engine needs to render separate images for each eye (stereo rendering), which nearly doubles the rendering workload. Vulkan's multi-threaded command submission and fine-grained memory management mechanisms allow the engine to allocate GPU resources more efficiently and reduce rendering latency. Godot 4.0 adopted Vulkan as its default rendering backend precisely to compete with commercial engines in these high-performance scenarios.

For VR/AR support, Godot provides a unified interface through the OpenXR standard, allowing developers to target multiple headset devices with the same codebase without writing separate adaptation layers for each platform. OpenXR is an open standard officially released by the Khronos Group in 2019, designed to unify the interface between VR/AR applications and runtimes. Before OpenXR, each headset manufacturer (Oculus, HTC, Valve, etc.) had its own proprietary SDK, requiring developers to write different adaptation code for each platform. OpenXR defines a unified API layer that allows the same application code to run on any compatible device. Meta Quest, SteamVR, Windows Mixed Reality, and even PSVR2 all support or are compatible with OpenXR to varying degrees. For an open-source engine like Godot, implementing OpenXR support means gaining broad device compatibility without needing to sign proprietary partnership agreements with each manufacturer.

As a cross-vendor industry standard, OpenXR is the key bridge enabling Godot to reach closed platforms like PSVR2. Compared to closed-source engines that require licensing and custom SDKs, Godot's open architecture gives developers greater autonomy and allows deeper involvement in low-level rendering optimization—which is particularly critical in VR applications that are extremely sensitive to frame rates.

Why Choose Godot Over Unity

For indie developers and small teams, Godot's biggest attraction lies in "zero licensing fees" and "fully open source." Unity's recent runtime fee controversy drove many developers to seek alternatives, and Godot's MIT license offers a commercial path with no additional costs.

The specific background of this controversy: In September 2023, Unity Technologies announced the introduction of a "Unity Runtime Fee" policy that would charge developers additional fees based on game installation counts. This policy triggered strong backlash from the game development community due to its retroactive clauses and ambiguous billing criteria, with numerous developers publicly stating they would migrate to other engines. Although Unity subsequently revised the policy details and replaced its CEO, the trust crisis had already formed. This event became a catalyst for user growth in alternative engines like Godot and Unreal, with Godot seeing significant jumps in GitHub stars and downloads following the incident.

Additionally, the engine's lightweight footprint, fast editor startup, and easy-to-learn GDScript scripting language are all practical reasons for choosing it.

However, choosing Godot also means bearing the cost of an immature ecosystem—fewer available plugins, limited community VR resources, and often needing to dig through source code yourself when encountering problems. This is the root cause of many "pitfalls" documented in this post mortem.

Core Challenges of Porting to PSVR2

The Closed Nature of Console Platforms

Porting a VR game to PSVR2 first requires overcoming the closed ecosystem barriers of Sony's console platform. Console development requires officially authorized development kits (devkits), passing rigorous certification processes, and complying with performance and content standards. Console platforms like Sony, Microsoft, and Nintendo enforce strict technical certification systems (TRC/TCR/Lotcheck) for published games. Certification covers hundreds of checkpoints including but not limited to: loading time limits, frame rate stability, memory leak detection, network disconnection handling, user interface standards, trophy/achievement system integration, save system behavior, and error tolerance for various exception scenarios. VR platforms add extra checks for comfort metrics, such as whether frame rates consistently meet targets and whether comfort mode options are provided. A single certification failure can mean weeks of fixes and resubmission cycles. For developers using non-mainstream engines, issues encountered during certification often lack community experience to reference, making troubleshooting significantly more difficult.

For Godot developers accustomed to the freedom of PC development, this entire process represents a steep learning curve.

The thornier issue is that Godot's official support for PS5/PSVR2 is not as out-of-the-box as commercial engines. Developers often need to rely on third-party porting service providers or handle platform-specific low-level integration work themselves, significantly increasing the technical complexity and time cost of porting.

The Real Pressure of Performance Optimization

Although PSVR2 features advanced capabilities like eye tracking and Foveated Rendering, the PS5's hardware performance remains a fixed ceiling. Foveated rendering is an optimization technique that leverages the characteristics of human vision: the fovea region of the human eye covers only about 2-5 degrees of the visual field but provides the highest resolution visual perception, while peripheral vision's sensitivity to detail drops dramatically. Foveated rendering accordingly concentrates computational resources on the area where the user is looking, rendering the center at full resolution while reducing rendering resolution or detail levels for peripheral areas. PSVR2's built-in eye tracking hardware makes dynamic foveated rendering possible—the system tracks pupil position in real time and dynamically adjusts the high-precision rendering area. This technology can reduce GPU load by 30%-50% without noticeably affecting visual quality, which is crucial for maintaining 90fps on fixed hardware.

VR applications require stable high frame rates (typically 90fps or above) to prevent user motion sickness, placing extremely demanding requirements on rendering workload.

Developers must repeatedly fine-tune the rendering pipeline in Godot, reduce Draw Calls, and properly utilize foveated rendering to lower computational load in peripheral vision areas to meet console certification performance standards. A Draw Call is a single draw command issued from the CPU to the GPU, with each Draw Call incurring certain CPU overhead (state switching, data transfer, etc.). In VR, Draw Call counts naturally double due to dual-eye rendering. When scenes contain many objects with diverse materials, Draw Call counts can reach thousands or even tens of thousands, causing the CPU to become a bottleneck. Common optimization techniques include: Batching, which merges objects using the same material into a single Draw Call; GPU Instancing, which allows multiple copies of the same model to require only one call; and LOD (Level of Detail) systems that switch to lower-polygon models based on distance. In Godot, developers need to manually plan scene structure and material strategies to control Draw Call counts, requiring a higher degree of technical involvement than commercial engines' automatic optimization mechanisms.

This is also why this post mortem is called "Partial"—VR porting is rarely a one-shot engineering effort but rather a process of continuous iteration, shipping and fixing as you go.

Practical Takeaways for Developers

The Commercial Path for Open-Source Tools Is Maturing

The most important significance of this practice is that it validates the feasibility of an open-source engine completing the full pipeline of "development—release—cross-platform porting." Despite the process being full of challenges, it proves that indie developers don't need to be locked into major engine vendors and expensive licensing fees to reach high-barrier markets like console VR.

Evaluate Platform Adaptation Costs Early

For teams planning cross-platform VR releases, the implicit advice from this post mortem is: thoroughly evaluate adaptation costs for target platforms early in the project. The workload for console porting is often severely underestimated—certification processes, performance thresholds, and platform SDK integration can all become key factors in project delays. Front-loading porting planning rather than treating it as a late-stage add-on can effectively reduce risk.

Conclusion

Although this development post mortem is limited in length, it documents a real and precious practice sample in open-source VR development. As the Godot ecosystem continues to mature and the OpenXR standard gradually becomes widespread, more developers will choose the "open-source engine + cross-platform VR" technology path in the future. And every honest post mortem is an indispensable accumulation of experience driving this ecosystem toward maturity.