Reproducable in 4.4-dev cb411fa960f0b7fdbd97dcdb4c90f9346360ee0e
System information
Any
Issue description
XR headsets have long had a build in feature to recenter our view but the definition of how we should react to this under different conditions has been somewhat unclear. Recently behaviour around this has changed in various XR runtimes with the introduction of the new 'LOCAL_FLOOR' reference space and with that the interpretation of the 'STAGE' reference space changing.
Currently what we do is completely broken with us no longer sending 'recenter' events to the user so this needs to be fixed, but there are further problems with our implementation.
First, as mentioned, different XR runtimes interpret how to react to the user triggering a recenter differently. As we're only indirectly informed of this through the XR_TYPE_EVENT_DATA_REFERENCE_SPACE_CHANGE_PENDING event, this is where we're reacting to this, but us reacting to this is being ignored because the contents of this event seems to have changed.
Second, different XR runtimes interpret the rules differently. Quest sends out a single event, while steamVR sends multiple.
Third, timing is wrong, this is a pending event telling us that the stage change will soon be applied and depending on how we react to the signal, in its current implementation we get the signal before we read the new tracking data.
We should probably change this logic in the following ways:
ignore the poseValid property of the event
set a flag "pose_is_recentered" to true on receiving this event
check the flag AFTER we obtain new tracking data and then emit the pose_recentered signal and reset the flag
Steps to reproduce
This can be reproduced in the character centric movement demo on our demo repository though I need to submit a few fixes which I'll do momentarily (the current recenter logic is incorrect as it does not take the chosen reference space into account).
Then simply trigger a recenter:
In steamVR, open the steamVR menu and choose recenter
In Quest (link or native) hold the meta button for a few seconds
BastiaanOlij
commented
1 day ago
Tested versions
System information
Any
Issue description
XR headsets have long had a build in feature to recenter our view but the definition of how we should react to this under different conditions has been somewhat unclear. Recently behaviour around this has changed in various XR runtimes with the introduction of the new 'LOCAL_FLOOR' reference space and with that the interpretation of the 'STAGE' reference space changing.
Currently what we do is completely broken with us no longer sending 'recenter' events to the user so this needs to be fixed, but there are further problems with our implementation.
First, as mentioned, different XR runtimes interpret how to react to the user triggering a recenter differently. As we're only indirectly informed of this through the
XR_TYPE_EVENT_DATA_REFERENCE_SPACE_CHANGE_PENDINGevent, this is where we're reacting to this, but us reacting to this is being ignored because the contents of this event seems to have changed.Second, different XR runtimes interpret the rules differently. Quest sends out a single event, while steamVR sends multiple.
Third, timing is wrong, this is a pending event telling us that the stage change will soon be applied and depending on how we react to the signal, in its current implementation we get the signal before we read the new tracking data.
We should probably change this logic in the following ways:
poseValidproperty of the eventpose_recenteredsignal and reset the flagSteps to reproduce
This can be reproduced in the character centric movement demo on our demo repository though I need to submit a few fixes which I'll do momentarily (the current recenter logic is incorrect as it does not take the chosen reference space into account).
Then simply trigger a recenter:
Minimal reproduction project (MRP)
https://github.com/godotengine/godot-demo-projects/tree/master/xr/openxr_character_centric_movement