OpenXR Development

Hi, Myself and several other devs have noticed problems when building OpenXR apps using the standard Unity OpenXR plugin (not the OculusXR plugin) and using the Oculus Runtime as the OpenXR default runtime.  I do not see the issues when using the SteamVR runtime. 1.  Audio is going through the system speakers rather than the headset.  This can be forcibly changed in Windows, but it should be doing it by default as it will inconvenience users.   2.  There seems to be some performance degredation or memory leak, particularly when the headset goes idle.

[To Delete]

 I am currently implementing OpenXR for Quest into my custom game engine and am running into some issues:An action bound to "/user/hand/left/input/menu/click" gets triggered by the "Y" button AND the "menu" button. I'd expect it to only be triggered by the "menu" button.There is no "local floor" reference space in OpenXR, is the "stage" reference space supposed to be the new normal for standing experiences? Meaning no more resetting? Is it ok to still catch the reset event and move the UI in front of the player? Would be great if there was some documentation somewhere on what the expected behavior is now that the old default is apparently not a thing anymore.Performance levels are different, there is power saving, low, high and boost. Setting it to power saving does seem to do nothing, while LOW corresponds to a level of 1, HIGH is 2 and BOOST is 3 (Only checked on Quest 2). But BOOST is meant to not be thermally sustainable, while level 3 usually seems to be perfectly fine and is

Any chance on getting a reference implementation for Vulkan Foveated rendering (fixed or dynamic) within an OpenXR context? Been working through implementation with XrSwapchainCreateInfoFoveationFB and flags set to XR_SWAPCHAIN_CREATE_FOVEATION_FRAGMENT_DENSITY_MAP_BIT_FB and can create the swapchain fine, but unable to fish the VkImage references back out after creation.  Any help appreciated, example even better!  

Simple YES/NO requested. This should be enabled in OpenXR 1.0 although I get the following: E/OpenXR-Loader: Error [GENERAL | xrCreateInstance | OpenXR-Loader] : LoaderInstance::CreateInstance, no support found for requested extension: XR_KHR_vulkan_enable2 I am using the OpenXR loader supplied with the Oculus OpenXR Mobile SDK. I'm implementing MultiView support and need to access GL_EXT_multiview in my SPIRV vertex shader as GL_OVR_multiview2 no longer seems to be support. 

When a user clicks exit in the Quest system Menu overlay, my OpenXR app's session state transitions from XR_SESSION_STATE_STOPPING -> XR_SESSION_STATE_IDLE (as per OpenXR spec) but nevers transitions to the XR_SESSION_STATE_EXITING state unless an explicit call to xrRequestExitSession is made before or on a transition to STOPPING. If I do not call xrRequestExitSession just exit after transition to XR_SESSION_STATE_IDLE, when xrDestroySession/Instance is called an exception is thrown so my app never does a clean exit this way.

I wasn't enabling the Oculus Online Subsystem 😓 .. that took way longer than it should have to fix***Previously, I would use the 'Oculus VR' plugin Verify Entitlement node.In 4.27, we now have the 'Oculus OpenXR' plugin, and this node is no longer available. We are told explicitly to "Disable the Oculus VR plugin when enabling" the 'Oculus OpenXR' plugin.. sooo.... how am I to do the required entitlement check?? Any and all help greatly appreciated.

With the Oculus Integration it is possible to set a camera to the left or right eye, but with Open XR the only options on the camera are All or None. Is this a bug with the Open XR implementation or am I doing something wrong?

Hello, i was wondering does the Oculus OXR mobile runtime/loader support third-party layers (installing and  dynamically loading them) and also what would the situation be in terms of distrubing apps using this on the Oculus store, would this violate ToA/ToS? For example say, a third party makes a layer extension for a hypothetical input device. 

Issue: APK application opens in a non-interactable window that can only be closed by alternative means (ie. power cycle, open another application, uninstall).Observations: Log does not provide any obvious errors, warnings, or messages. Build Settings match previous working projects with the exception of settings specific to OpenXR requirements.My team and I have been messing around with build settings, checking forums, documentation, news postings, and have not found any relevant or related occurrence of this issue. I'm happy to provide any code, logs, or additional screenshots. Unity Version: 2020.3.2f1Quest 2 Version: 32.0.0.58.353.311069892Quest 2 Software Version: 18371800151900000 

Hi there, My title Vermillion is out on Steam. I'm using OpenXR, and forcing the use of SteamVR OpenXR because with the Oculus OpenXR integration, it freezes after a few minutes for I believe all Oculus hardware. On the SteamVR OpenXR version it's mostly fine, however CV1 users are still experiencing the freezing. Needless to say, this is a big issue. Can this please be looked into with urgency? 

Hey all, im a somewhat beginning when it comes to developing VR. I have some experience using Unity and the XR Interaction toolkit, but with all the news with OpenXR and the PassThroughAPI I would really love to be able to develop for that.However im really confused, do I need the oculus integration in my Unity project still? Or do I purely just use OpenXR, if thats the case I'm having a really hard time finding any documentation on developing oculus with OpenXR that isnt just using the stand OVRRig and such. I know there obseleting there proprietary API's in a year so I really dont want to start working with something that is gone soon. Is is just the Oculus XR Plugin thats getting deprecated, or both that and oculus integration. I'm really excited to start working with hand tracking and PassThrough but im so lost as to where to start currently. Any help would be greatly apreciated.

Hello. I am looking if ASW 2.0 is active under our game using OpenXR. I am sending the XrCompositionLayerDepthInfoKHR with depth swapchains, and in the oculus debug tool tells me that the projection layer has depth. All look good. BUT. It seems whenewer I enable or disable sending depth to OpenXR, the result is the same, there is no difference on the ASW output. I have checked with the oculus debug tool, that ASW actually doing something, and while it is doing it, the edges of geometry are jagging during HMD movement. But regardless I send the depth buffer or not, the jagging is exactly the same. Is ASW 2.0 actually used under OpenXR. I have found no word about it at all.

Hello,I am converting my Unity project from SteamVR to OpenXR (never used OVR before) to be able to submit to the Oculus store now that it accepts OpenXR. One of the functional requirements is that the app must pause when the user removes the HMD or opens Oculus Dash (VRC.PC.Functional.3). The example code for this: https://developer.oculus.com/documentation/native/pc/dg-vr-focus/ relies on OVR GetSessionStatus. How does one meet the requirement with OpenXR?Thank you!

While using the Unity OpenXR plugin 1.0.3 I've discovered that the Oculus Rift does not report itself in the initial connected devices at game startup ( in a RuntimeInitializeOnLoadMethod method ) if the headset is not mounted (on a head)Instead, the Rift reports itself connected when the headset is mounted via the Unity.XR.InputDevices.deviceConnected  event. This is a problem for our scenario because headset on AND off are valid situations and we need to properly toggle content for each state, especially at startup.Is there a way to have the headset appear connected in the Unity.XR.InputDevices connected devices at initial startup ? Calling something in OculusXRPlugin.dll or OVRPlugin.dll ?Thanks in advance for any help

Hello, I am working on our game to include VR support using OpenXR. Everything is set up and working fine, and now I'd like to add support for ASW. I use the XR_KHR_composition_layer_depth extension, and provide the depth buffer in the XrCompositionLayerDepthInfoKHR structure as the next parameter of the XrCompositionLayerProjectionView for the runtime as in the docs. I am using D3D11, my depth swap chain is in DXGI_FORMAT_D32_FLOAT format, and I use reversed depth. As the result, all I can see is blocks, all around the screen. I can't post shots for legal reasions, but I have managed to reproduce this with one of the Microsoft sample applications for OpenXR: OpenXR-MixedReality/samples/BasicXrApp at main · microsoft/OpenXR-MixedReality · GitHub Here I get the following result which practically producing the same artifacts as in our game:Interestingly here it only affects the left eye, but in our game it is present for both eyes. If I disable ASW

  I use joints plus joint radius to build pentagon tubes for the hand mesh. It's fast, looks decent, is easy to work with, and is consistent across platforms. It looks like the Oculus runtime is reporting joint radius as half size or something. My fingers are the correct size on other platforms, but Quest gives me dracula needles instead 🙂 This is on a Quest 2, using the 1.0.13 OpenXR SDK published on 2021-02-19.

So I've got code that uses the OpenXR hand tracking extension, and it works perfectly with HoloLens 2 and the Leap Motion layer. On Quest, I can see the extension, xrGetSystemProperties reports it as available, I have the manifest settings configured and the app does not ask me to switch to controllers, but XrHandJointLocationsEXT::isActive always reports false when calling xrLocateHandJointsEXT!Any thoughts as to what I'm missing here? Is there some additional configuration I may have missed, or is this perhaps still buggy?Engine is custom, StereoKit, so it's native code. I'm using the 2020-12-04 (OpenXR 1.0.12) release of the Oculus OpenXR Mobile SDK.

This has been verified with Oculus OpenXR runtime version 1.58.0. To get the headset angular velocity, I use code like in the following snippet: XrSpaceVelocity velocity = { XR_TYPE_SPACE_VELOCITY }; XrSpaceLocation location = { XR_TYPE_SPACE_LOCATION }; location.next = &velocity; XR_CHECK(xrLocateSpace(viewSpace, localSpace, displayTime, &location)); This works as expected with both the WMR and Valve OpenXR runtimes. With the Oculus runtime, however, velocity.angularVelocity always contains {0,0,0}, despite the XR_SPACE_VELOCITY_ANGULAR_VALID_BIT flag being correctly set in velocity.velocityFlags.

I'm working on a WebXR and remote debugging stopped working. Now my device (Oculus quest 2, using the Oculus Browser) doesn't show up in chrome://inspect/#devices on Chrome 89.0.4389.90 I can connect with adb, but I'm never asked about allowing the ADB remote key - and I couldn't find any way to reset all authorized keys. All I could do was disable/re-enable developer mode in the Oculus app on my phone Any ideas on how to debug this issue?

I have been creating basic Oculus/Unity/C# apps for a few years now (personal hobby, not professional), using both the Oculus Plugin and the new XR Plugin system in Unity. I have recently gotten into MSFS2020/VR, but am having trouble with Vatsim/Kneeboard integration while wearing the headset. I would love to explore making my own "overlay" (interactive) that would appear in the sim in VR (or even other apps that arent mine). I have a good start understanding the MSFS SDK and API, but dont know where to start on injecting an overlay in VR. What API's could I look into that would let me do that? I'm guessing I would have to look into the OpenXR api? If Unity wont do OpenXR, I can do C++/Dlls as well. Any help pointing me in the right direction would be appreciated.

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 definitel

Hi All,I have an app in Chrome (not my app) with which I can use the immersive mode - works fine with the Rift and Rift S.  When I am using a Quest 2 with Link cable, I get the the error "Error initialising device config... WebXR session mode unsupported"I thought the Quest 2 would be seen by Chrome as a Rift / Rift S?  Am I wrong?Many thanks.

Hello forum and Oculus staff.I opened a performance bug relating to Oculus' OpenXR runtime for Quest 2 on Nov 20th, which hasn't been fixed since Nov 20th and is threatening to stall the release of my game.Can you please escalate this? The stall has been independently reproduced as of today by another user, in the hello_xr sample app and in their own code as well. It prevents 90 Hz operation via Link on PC.Thank you for your time.

This has been verified with Oculus OpenXR runtime version 1.55.0 using the XR_KHR_D3D11_enable extension.According to the OpenXR spec, xrEnumerateSwapchainImages() has two modes of operation: a size query mode, where imageCapacityInput is 0 and only imageCountOutput is returned, and a texture retrieve mode, where the images array is filled up to imageCapacityInput capacity. Obviously, only the second call should AddRef() the swapchain textures (and only those that are actually passed back to the application), because the first call returns no pointers that the application can later Release().Instead, with the current runtime, xrEnumerateSwapchainImages() AddRef()'s all the swapchain textures even in the first mode of operation. With the typical two-call paradigm (query for size first, then retrieve the array), this leads to a hidden increment of the reference count for all swapchain textures, which later on shutdown prevents the textures (and thus the D3D11 device) from ever