OpenXR Comes to Axmol VR

[halx99]

Refer PR: #3220

This update brings a real OpenXR-backed VR path to Axmol. The old generic stereo renderer was useful for previewing VR-style rendering, but it was not connected to a headset runtime. With this change, Axmol can create an OpenXR session, render into runtime swapchains, submit stereo projection layers, and route controller input back into the engine.

From Renderer to Compositor

The core rendering hook has moved from SceneRenderer to SceneCompositor. A compositor is responsible for frame-bound scene presentation: it can poll runtime events, render the scene normally, render it multiple times, redirect it into offscreen or runtime-owned targets, and transform scissor rectangles when needed.

The default SceneCompositor keeps normal rendering behavior. VR projects can now choose between two compositors:

• VRPreviewSceneCompositor for local stereo preview and distortion debugging without an XR runtime.
• VRSceneCompositor for OpenXR-backed HMD rendering.

That split keeps the preview workflow lightweight while giving production VR a runtime-aware path.

What the OpenXR Path Does

The new OpenXRDriver drives the OpenXR frame pipeline:

• OpenXR instance, system, session, and local space.
• Stereo view configuration and swapchains.
• Per-frame xrWaitFrame, xrBeginFrame, and xrEndFrame flow.
• Runtime-owned texture wrapping for the active RHI backend.
• Controller action sets, bindings, poses, buttons, thumbsticks, and interaction profiles.

VRSceneCompositor connects that context to Axmol's frame lifecycle. It polls XR state before scheduler update, renders each eye with the runtime-provided pose and asymmetric projection, draws controller rays, flushes rendering work, releases swapchain images, and submits the projection layer.

Controller Rays Become Pointer Input

OpenXR controller input now reaches two layers of the engine.

For XR-specific input, use XRInputEventListener to receive button, axis, aim pose, and grip pose events.

For UI and scene interaction, controller aim rays are also bridged into PointerEvent. A PointerEvent may now carry:

• PointerType::Controller
• current and previous 3D rays
• a world-space PointerHitResult

That means existing pointer listeners can participate in VR interaction, and custom nodes can override Node::onPointerHitTest() for ray-aware picking. Widgets, scroll views, menus, and terrain tests have been updated to use this path.

RHI Work Under the Hood

OpenXR swapchain images are owned by the runtime, not by Axmol. To render into them, the RHI now supports wrapping external native textures with ExternalTextureDesc. The renderer can also submit current frame commands without presenting the default window surface, which lets the OpenXR compositor finish GPU work before releasing acquired swapchain images.

For Vulkan, OpenXRVulkanInterop implements the VulkanInterop interface and is registered via Application::registerVulkanInterop() during engine bootstrap. GraphicsCore (formerly DriverContext) queries the OpenXR runtime for required extensions and the runtime-selected physical device through this interface, keeping the core RHI free of OpenXR dependencies.

Enabling It

Build with:

-DAX_ENABLE_VR=ON
-DAX_ENABLE_OPENXR=ON

For Vulkan OpenXR, call this in applicationWillLaunch():

void AppDelegate::applicationWillLaunch()
{
#ifdef AX_ENABLE_OPENXR
    registerVulkanInterop();
#endif
}

Then install the compositor:

#ifdef AX_ENABLE_OPENXR
renderView->setSceneCompositor(std::make_unique<ax::VRSceneCompositor>());
#else
renderView->setSceneCompositor(std::make_unique<ax::VRPreviewSceneCompositor>());
#endif

This is the first OpenXR integration step for Axmol's VR stack: real runtime frame timing, headset swapchains, stereo eye poses, and controller input are now part of the engine path.

Platform note: This PR is validated on Win32 desktop only. Android is not tested and not guaranteed to work.