OpenXR Boundary Alignment Issue

I’m running into an issue when using OpenXR with Oculus (on PC):

  • I would like to keep track of the play area of the player (say for showing a quad on the ground displaying the safe area).
  • I can use FOpenXRHMD::GetPlayAreaBounds (though this is in a private class so not great) to get the dimensions, but not the positional offset to the center of the rectangle.
  • On launch, the center is at (0,0,0), but Oculus allows you to Reset View, leading the center to be located away from (0,0,0), but this isn’t reflected in any publicly available manner. XRSystem->GetTrackingToWorldTransform() doesn’t update to a new location.

So is there any way to maintain alignment between a virtual object and the play area in OpenXR?

Hey @BlueprintBen,

the OpenXR specification for Play Area Bounds doesn’t specify that the runtime should return that information. In 4.27.1 VR Template I implemented drawing the Play Area Bounds when visualizing the teleporter and I’m displaying the position of the player relative to the play area bounds as such:

It’s already on UE4 Main on GitHub but will be available in the binary version of 4.27 when we release .1.

I hope that helps!

1 Like

Thanks Victor. So your BP would correctly place the bounds (say if displayed just at the user’s feet instead of at the teleport target) even after an Oculus Recenter?

To be clear, the recentering itself appears to violate the OpenXR spec here:

Given that the origin is not located “at the center of the rectangle” after triggering (nor are the X and Z axes aligned to the rectangle anymore). Not sure if that’s on UE’s end or Oculus.

Took me a day to build it but I checked out and tried your template: it displays the same issue :confused:

After recentering (at the edge of my play space), the teleport visualizer displays the boundary as if the player is in the center of the play area.

Is this something you’ll bring up with Oculus? It feels like they aren’t supposed to offer the Reset View action in an OpenXR application based on the aforementioned spec on SPACE_TYPE_STAGE…