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

10 replies
4410 views

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.

E

eah

Participant

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.

A

Anonymous

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.

E

eah

Participant

Which runtime version are you testing against? Also would you mind sharing a code snippet showing how you're implementing your programmatic re-centering?

A

Anonymous

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));
	XrSpaceLocationFlags valid = XR_VIEW_STATE_ORIENTATION_VALID_BIT | XR_VIEW_STATE_POSITION_VALID_BIT;
	if ((location.locationFlags & valid) != valid)
		return;

	// TODO: This code doesn't work with the Oculus runtime (while the HUD looks correct, the main layer gets the wrong ATW window)
	XR_CHECK(xrDestroySpace(spaceLocalCustom));
	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));
}

A

Anonymous

Just tested with OpenXR runtime version 1.51.0 and the problem is still there

E

eah

Participant

@LukeRoss where are you getting the 1.51 version from? PTC should be 19.0...

A

Anonymous

@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),
	instanceProperties.runtimeName);

A

Anonymous

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?

J

johnkearney

Meta Employee

@LukeRoss A fix for this issue went out in v23 / 1.55.0. Thanks for the reports and reproducible code here.

C

cass

New Participant

This might also be useful. http://blog.xyzw.us/2020/01/recentering-in-openxr.html