Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

Wrong ATW/reprojection window if XrReferenceSpaceCreateInfo::poseInReferenceSpace contains rotation

LukeRossLukeRoss Posts: 137
edited July 2 in OpenXR Development
I stumbled against this bug while I was trying to implement a surrogate of programmatic recentering, since the OpenXR API appears to lack such basic functionality (the equivalent of ovr_RecenterTrackingOrigin()).

If an XR_REFERENCE_SPACE_TYPE_LOCAL space is created with an XrReferenceSpaceCreateInfo::poseInReferenceSpace that contains a rotation, the window used by the runtime for asynchronous timewarp will be wrong for the XrCompositionLayerProjection that refers to such space. The perceived effect is that the limits of the visible (reprojected) area will be rotated off the view axis by the angles given in the space's origin orientation, to the point where nothing will be seen in the headset when the angles are too large.

Edit: To clarify, this occurs even if the rotation is yaw-only. Even though the OpenXR spec allows for any pose, it would be understandable at this point if the runtime was not robust to local space rotations that involved pitch/roll. But yaw should definitely be supported correctly.
Hey, did you check out my VR mods for No One Lives Forever 2 and Grand Theft Auto V?


  • eaheah Posts: 24 Oculus Staff
    Thanks for reporting, I've filed a task and I'll add an OpenXR conformance test for this. Our runtime does currently call ovr_RecenterTrackingOrigin under the covers and you should be getting a XrEventDataReferenceSpaceChangePending on recenter but the poseInPreviousSpace will currently be identity.
  • LukeRossLukeRoss Posts: 137
    Thank you for your replies (to this and the other bug reports).

    About recentering, maybe I was unclear. The problem I was describing does not occur when recentering is initiated by the user through the Oculus Dash interface, i.e., when the runtime knows about it: in that case, as you mentioned, ovr_RecenterTrackingOrigin() is called behind the scenes and I do get a XrEventDataReferenceSpaceChangePending event.

    The problem with misaligned timewarp occurs when I want to recenter programmatically from my application: since the OpenXR API offers no equivalent of a ovr_RecenterTrackingOrigin() call (a weird omission IMO), I simulate the recentering by rotating the local space, which works correctly on the Microsoft OpenXR runtime but not on Oculus.
    Hey, did you check out my VR mods for No One Lives Forever 2 and Grand Theft Auto V?
  • eaheah Posts: 24 Oculus Staff
    Which runtime version are you testing against? Also would you mind sharing a code snippet showing how you're implementing your programmatic re-centering?
  • LukeRossLukeRoss Posts: 137
    Sure. The runtime I tested against was 1.49.0. Here is my programmatic recentering function:

    void OpenXRMgr::Recenter()
    	using namespace OVR;
    	XrSpaceLocation location = { XR_TYPE_SPACE_LOCATION };
    	XrResult res;
    	XR_CHECK(xrLocateSpace(spaceView, spaceLocalRuntime, GetTime(), &location));
    	if ((location.locationFlags & valid) != valid)
    	// TODO: This code doesn't work with the Oculus runtime (while the HUD looks correct, the main layer gets the wrong ATW window)
    	XrReferenceSpaceCreateInfo createInfo = { XR_TYPE_REFERENCE_SPACE_CREATE_INFO };
    	createInfo.referenceSpaceType = XR_REFERENCE_SPACE_TYPE_LOCAL;
    	float yaw;
    	((const Quatf &)location.pose.orientation).GetYawPitchRoll(&yaw, nullptr, nullptr);
    	centerPose = Posef(Quatf(Axis_Y, yaw), (const Vector3f &)location.pose.position).Normalized();
    	createInfo.poseInReferenceSpace = (XrPosef &)centerPose;
    	XR_CHECK(xrCreateReferenceSpace(session, &createInfo, &spaceLocalCustom));

    Hey, did you check out my VR mods for No One Lives Forever 2 and Grand Theft Auto V?
  • LukeRossLukeRoss Posts: 137
    Just tested with OpenXR runtime version 1.51.0 and the problem is still there
    Hey, did you check out my VR mods for No One Lives Forever 2 and Grand Theft Auto V?
  • eaheah Posts: 24 Oculus Staff
    @LukeRoss where are you getting the 1.51 version from? PTC should be 19.0...  
  • LukeRossLukeRoss Posts: 137
    edited August 1
    @eah Why do you mention PTC? I'm not on the public test channel. I'm on the normal v19 Oculus software.

    1.51.0 is what your xrGetInstanceProperties() function returns:

    XrInstanceProperties instanceProperties = { XR_TYPE_INSTANCE_PROPERTIES };
    XR_CHECK(xrGetInstanceProperties(instance, &instanceProperties));
    RVRLogFmt("OpenXR runtime version %u.%u.%u: %s", XR_VERSION_MAJOR(instanceProperties.runtimeVersion),
    	XR_VERSION_MINOR(instanceProperties.runtimeVersion), XR_VERSION_PATCH(instanceProperties.runtimeVersion),

    Hey, did you check out my VR mods for No One Lives Forever 2 and Grand Theft Auto V?
  • Tagh_azogTagh_azog Posts: 1
    Hi Staff,
    I am experiencing the same problem @LukeRoss is referring to. We are using the OpenXR API to recenter the local space for cockpit experience and this works well with Windows Mixed Reality runtime but for Oculus the square rendered in the headset has its orientation broken as described by @LukeRoss.
    The app is simply not usable with an Oculus headset if recenter doesn't work using OpenXR and we cannot integrate into our engine the Oculus SDK (too high cost).
    Pretty sad there is no news about this bug, recentering looks like a must have in VR basic experience, could you tell us how is this going? Or if there is a workaround using current runtime version @eah?
  • johnkearneyjohnkearney Posts: 1
    @LukeRoss A fix for this issue went out in v23 / 1.55.0. Thanks for the reports and reproducible code here.
Sign In or Register to comment.