v69 breaks OpenXR cubemaps with compressed textures
Our application creates a XR cubemap layer and applies textures to it. The cubemap layer is the usual type XR_TYPE_COMPOSITION_LAYER_CUBE_KHR. The 6 textures are loaded from KTX files and use the GL_COMPRESSED_SRGB8_ETC2 format. Starting with v69, this method for creating the environment around the user stopped working and our UI elements just float inside a black empty space. This functionality broke also on our *published* version of the application, so it was probably not caused by a bug on our end. Everything worked fine on v68 and it broke on v69, We have been investigating this issue for several days and it seems that the problem is specifically triggered by the combination of compressed textures and a cubemap layer. Some additional observations: Textures with format GL_COMPRESSED_SRGB8_ETC2 or GL_COMPRESSED_RGB8_ETC2 do not work. Using PNG files for the cubemap does work (GL_RGBA8). Disabling layers also works. Loading other textures with the same formats works (we do it for the controllers).
Washed out (double gamma correction) on OpenGL
No matter which swapchain format I specify, my OpenGL application always renders washed out. That implies that OpenGL always thinks it is rendering to a linear render target, while OpenXR always thinks I am submitting an sRGB render target. Changing the swapchain format that I ask OpenXR to create between sRGB and linear makes no difference, and neither does glEnable(GL_FRAMEBUFFER_SRGB).Bug Report - Hand Tracking is being Shaky/Laggy (Reproduced on 2 devices)
Hi, after going through the forums, back and forth between Meta Support, they couldn't help me, so I am going to put all the information together here. Hand Tracking seems to work but it's incredibly shaky when staying still. I managed to reproduce this on a Quest Pro and Quest 2 on Link and Standalone. This seems to be exclusive to OpenXR apps, it doesn't happen in the Home environment nor Apps such as First Hand Experience app or at least it's not as noticeable. I managed to reproduce this in the new Aura sample app that got released on App Lab on Standalone. As well as other two barebones OpenXR apps via Link. Here's two videos showing the issue: (I made sure to be in lit environment, so it's not bad lighting) Video #1: https://youtu.be/wBfFyP7Tl10 Video #2: https://youtu.be/08E-BWR4CD0 Version v49 (49.0.0.206.357) on Standalone (Quest Pro) I also tried both the latest PTC version (50.0.0.165.257) and the stable version (49.0.0.170.358) of Oculus PC software on Link, if that matters. My first forums post about this issue: PTC v50 Oculus Link issue - Hand Tracking is shaki... - Meta Community Forums - 1030901 (atmeta.com)
Get Device Physical Screen Resolution
I am trying to get the physical width and height of the device to create the swapchains. With the old Native VrApi that is currently deprecated, I could use VRAPI_SYS_PROP_DISPLAY_PIXELS_WIDE and VRAPI_SYS_PROP_DISPLAY_PIXELS_HIGH to retreive the correct physical screen resolution. When tested on the Meta Quest 2, the results were 1,832 and 1920. I am moving my code to use Native OpenXR. Using the OpenXR Runtime when I query for typedef struct XrViewConfigurationView { XrStructureType type; void* XR_MAY_ALIAS next; uint32_t recommendedImageRectWidth; uint32_t maxImageRectWidth; uint32_t recommendedImageRectHeight; uint32_t maxImageRectHeight; uint32_t recommendedSwapchainSampleCount; uint32_t maxSwapchainSampleCount; } XrViewConfigurationView; and for typedef struct XrSystemGraphicsProperties { uint32_t maxSwapchainImageHeight; uint32_t maxSwapchainImageWidth; uint32_t maxLayerCount; } XrSystemGraphicsProperties; The recommended width and height I receive are 1440 and 1584, while for the maxSwapchainImageWidth, maxSwapchainImageHeight, maxImageRectWidth and maxImageRectHeight, I am receiving 8192. I believe the maximum swapchain size should be the physical size of the screen. Or maybe there is another way to retreive the physical screen resolution like it was implemented in the deprecated VrAPI. System Information: Device: Meta Quest 2 Build: Meta Quest build 50.0 OpenXR Loader Version: 1.0.24 Development: OpenXR Native APIGet Motion Controller Data lags behind when actor is moving
I have discovered a bug when using the "Get Motion Controller Data" function. I am using Unreal Engine version 4.27.0. I have yet to test this in the latest version of the engine. The bug occurs when moving the actor around. The data found in XRMotionControllerData which is given by the function "Get Motion Controller Data" gives position and rotation data for the motion controllers which doesn't seem to be up to date with exactly where the actor has moved. In my testing project, I added code which simply draws this data as a red beam. I also added code which moves the actor. The red beam and the teleport beam both appear to be lagging behind the actor. The bug also occurs when rotating the actor. It does not occur when moving the motion controller around, it only seems to occur when moving the actor around. When using the location and forward vector of the MotionControllerComponent World Location as a scene component, the issue does not occur. All of these effects have been observed both from VR Preview via oculus link with the Quest 2, and a version launched to the Quest 2. I have verified this in a fresh VR Template project. The bug is present without any modifications. Here's a drive folder with some recordings of the issue, and some screenshots of some code. The videos are labeled with what's happening, and in what environment. https://drive.google.com/drive/folders/17ExfnqBW2rH_rx2OSSZfiqHlOupmeeTz?usp=sharingUsing OpenXR and Vulkan, getting strange artifacts unique to Oculus runtime
On steamVR (with an Index), these artifacts don't appear. I can run the app with 0 validation errors in the Oculus runtime. I'm using a Quest 1 + link cable. The behavior changes depending on whether I use msaa. With msaa: The game works well until a sufficient # of chunks have been loaded (this is an open world voxel game). Once that is the case (~30s in), a flickering artifact slowly grows from the bottom right of the right eye, and moves left to cover both eyes over the course of ~5s. Without msaa: The game works well until a large # of chunks have been loaded (requires more chunks to be loaded than when msaa is enabled). Once that is the case, it is as though my draw calls get cut off before finishing, but only in my right eye. As an example: I first render my opaque chunks (front-to-back), and then my transparent chunks (back-to-front). When I have sufficient # of chunks in view, the right eye stops rendering the transparent chunks entirely (as well as many of the distant opaque chunks). The left eye stays solid the whole time. If I shift my view to only contain a small # of chunks (ie, look down), both eyes render fine. If I add `vkDeviceWaitIdle` between my rendering `vkQueueSubmit` and `xrReleaseSwapchainImage`, the bug "goes away". This leads me to believe there might be a bug in the synchronization in the oculus openxr runtime between those two calls. Renderdoc, regardless of case, shows both views rendering correctly. I posted this to the Khronos slack, as well as the Vulkan discord, and one thought that was shared was that it might have to do with this: https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ ? ^ the beginning of the flickering artifact when msaa is enabled (right eye) ^ right eye when looking at sufficient # of chunks with msaa not enabled ^ left eye when looking at same view (renders correctly)
XR Session state never transitions from IDLE to QUITING when user clicks Quit in System Menu
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.Wrong ATW/reprojection window if XrReferenceSpaceCreateInfo::poseInReferenceSpace contains rotation
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.Issue with xrEnumerateSwapchainImages
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 being released correctly, leaking video memory. This is normally hidden in simple test applications by the fact that the application terminates right away, forcing a cleanup of the device. But in more complex real-world scenarios, like the one I'm working on currently where the OpenXR renderer can be toggled on and off multiple times, this leads to all swapchain textures leaking every time.
