jherico / openxr-samples

Samples for the OpenXR API

Pre-requisites

• Git (Download)
• CMake 3.12 or higher (Download)
• A CMake compatible development environment
  • Visual Studio 2019 (Download)

Quick Start

• Clone this repository with the recursive flag
  • git clone https://github.com/jherico/OpenXRSamples.git --recursive
  • cd OpenXRSamples
  • If you've already cloned without the recursive flag, you can fetch the submodules using the commands
    • git submodule init
    • git submodule update
• Create a build directory
  • mkdir build
  • cd build
• Configure using cmake (force 64-bit architecture)
  • cmake .. -A x64
  • This step can take a while the first time, since it will automatically download and build all the dependencies
• Build the example
  • cmake --build . --config Debug --target gl_single_file_example

After those steps, if you haven't encountered any errors, there should be bin_debug dir in the main repository dir. This should contain and executable gl_single_file_example. Running it should display an on screen window divided between green and blue and in the HMD should also display green in the left eye and blue in the right eye.

openxr-samples's Issues

Qt3D example has lag

The Qt3D example view shows visible lag of the scene behind the current head pose.

Researching in this forum thread: https://forum.qt.io/topic/107482/qt3d-vr-rendering

Better Basis to Swapchain loading code

Basis loading code should be able to create the correct type of swapchain (cube vs 2d vs array) and negotiate with the session to determine the best format to use (BC7, ETC2, RGBA, etc)

Vive only plays one frame then waits forever with c example

I'm trying to get the single file c example working with a Vive.

When I run the example, I get the default SteamVR "waiting for app [AppName]" window, but the green/blue which is rendered in the window is not rendered in the headset.

I've made these changes for debugging

bool startXrFrame() {

    bool b = false;

    XrFrameWaitInfo frameWaitInfo{ XR_TYPE_FRAME_WAIT_INFO, nullptr };
    switch (sessionState) {
    case XR_SESSION_STATE_READY:
    case XR_SESSION_STATE_FOCUSED:
    case XR_SESSION_STATE_SYNCHRONIZED:
    case XR_SESSION_STATE_VISIBLE:

            //added print line
        std::cout << "Starting wait" << std::endl;

        b = XR_UNQUALIFIED_SUCCESS(xrWaitFrame(session, &frameWaitInfo, &frameState));

            //added print line
        std::cout << "Ending wait" << std::endl;
        return b;
    default:
        break;
    }

    return b;
}

where I get the printout:

So, it seems like it never returns from the second xrWaitFrame()

Any help would be appreciated

Oculus runtime can't do Cube layers in OpenGL

A validation error is generated and the logs report:

ovrLayerType_Cube does not support ovrLayerFlag_TextureOriginAtBottomLeft. Disabling layer 0

Can this work for HTC VIVE headsets?

Hi, your work is really impressive, and I guess you designed especially it for Oculus. However, would it work for Vive latest headsets that with SteamVR runtime?

GLFW shared context rendering issue on Oculus XR runtime

TL;DR: Swapchain updates seem to have no effect when the primary XR window is not focused, or perhaps simply when a secondary window for the same process is focused.

Long Version:

In order to avoid having to do massive OpenGL state resets between using one library for user interface rendering and another for scene rendering, the samples attempt to do UI rendering in a separate OpenGL context & thread that shares resources with the primary context.

The GLFW idiom for creating an offscreen rendering context is simply to create an additional GLFW window that is never shown on screen. So in the current UI testing example I

1. create the primary GL context
2. create the XR session using that context
3. create the UI GL context and make it current
4. create the XR swapchain and framebuffer with the UI GL context active
5. acquire the first swapchain image and clear it with a distinctive color
6. make the NO GL context current on the main thread
7. launch the UI thread
8. make the main GL context current again and continue with normal startup

In the UI thread I

1. make the UI GL context current
2. enter a loop that waits for a frame to be requested from the main thread
3. when a request occurs, acquire a swapchain image and render to it

I've tried variations on this ordering, specifically whether the swapchain is created in the main GL context, or in the UI context, and when created in the UI context, whether it's created on the main thread or in the UI thread. The framebuffer that uses the swapchain images must be created on the UI context since FBO objects are not shared between contexts. However, the location of the swapchain creation doesn't seem to matter.

When I do this I often notice that the in-HMD quad does not have the desired content on it, but flickers between black and the distinctive color used for the first swapchain image clear. In the logs I noticed the line

06/10 10:47:20.810 {INFO} [Kernel:Default] [HMDState] Detected the active window handle changed to 7e07f0ll

When I saw this, I tried clicking the primary window created by my examples and then saw that the swapchain images were now updating properly in the HMD.

Can these samples run on the hololens?

Hello, I want to know if these openXR samples can run on the Hololens. If possible, can you tell me how to do that?

xrEnumerateSwapchainFormats on Oculus returns GL_BGR and GL_BGRA

only typed internal formats are expected.

README file excludes important step

I followed the README file instructions exactly... It's missing a step to install the Vulkan SDK (if it's not already installed)!
Please update instructions...

Building package vulkan[core]:x64-windows...

-- Querying VULKAN_SDK Enviroment variable

CMake Error at ports/vulkan/portfile.cmake:12 (message):

Could not find Vulkan SDK.  Before continuing, please download and install
Vulkan from:

    https://vulkan.lunarg.com/sdk/home

If you have already downloaded it, make sure the VULKAN_SDK environment
variable is set to vulkan's installation root.

Call Stack (most recent call first):

scripts/ports.cmake:76 (include)

Error: Building package vulkan:x64-windows failed with: BUILD_FAILED