Enabling Physics Interpolation Resets Transform of XRCamera3D even when not connected to an XR runtime

[CheesecakeCG]

Tested versions

• Reproducible in Godot 4.4.1
• Not Reproducible in Godot 4.4

System information

Godot v4.4.1.stable unknown - Arch Linux SMP PREEMPT_DYNAMIC Mon, 07 Apr 2025 19:59:13 +0000 on X11 - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 (nvidia; 570.133.07) - AMD Ryzen 7 5700X 8-Core Processor (16 threads)

Issue description

I've been setting XROrigin3D & XRCamera3D's in projects I want develop for both XR and desktop, in this case, a 3rd person shooter. In 4.4, the camera is offset from the player as expected, but when the project is run in 4.4.1, the XRCamera3D's local position is snapped back to (0, 0, 0). Disabling Physics Interpolation prevents this.

I should say this is a pretty weird thing to do, and offsetting the XR camera only and not the XR origin was a mistake that came from me never testing the project again in XR once I switched from 1st to 3rd person, but this admittedly cursed setup didn't break in 4.4 and earlier.

Likely caused by: #103233

Steps to reproduce

1. Add an XROrigin3D and an XRCamera3D child.
2. Move the XRCamera3D in the scene.
3. Enable Physics interpolation.

For the MRP, I've added Label3D's to each node so you can see them move in the editor camera override view.

Minimal reproduction project (MRP)

mrp-xrcamera-moves-withoutxr.zip

[BastiaanOlij]

We recently fixed physics interpolation with the XRCamera3D so it properly combines the latest tracking data with the interpolated data of the underlying physics object.

As there is no tracking here, that means we're getting a zero position and orientation for the camera at this point.

It is ALWAYS expected that the XRCamera3D node is positioned by the system and that any position you give it is overruled. That it "works" for you is more a fluke than expected behavior.

The recommendation is to have a separate rig for non-XR that uses a normal Camera node (seeing that also allows you to properly setup FOV and other properties that can be overridden by XR and thus have unpredictable behaviour) and use that in your non-XR mode.

[Asaduji]

This can be closed as this PR #106109 brings back the old behavior (transform doesn't change unless it receives pose data), however as he said you shouldn't rely on this at all.
Maybe another issue could be created to change the docs to be more specific about this, as it currently says it will only change transform "if such tracking is available".

[lawnjelly]

Closing as @Asaduji reports this as closed.