Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenXR implementation #3428

Merged
merged 1 commit into from
Jun 1, 2020
Merged

OpenXR implementation #3428

merged 1 commit into from
Jun 1, 2020

Conversation

MortimerGoro
Copy link
Contributor

Known issues (already reported to Oculus):

  • Washed out colors: Seems related to having SRGB by default or not applying VRAPI_FRAME_LAYER_FLAG_INHIBIT_SRGB_FRAMEBUFFER
  • Quad and Cube layers work correctly when using FBO swapchains. But when redenring compositor layers with AndroiSurface based swapChain I get a XR_ERROR_LAYER_INVALID error when calling xrEndFrame. AndroidSurface layers are disabled until the issue is fixed.
  • Reusing the instances of input XrActions with different subactionPaths for each controller on the Quest doesn't work well: the right controller reported the same pose and buttons as the left controller. I found a workaround. It works well creating different instance XrActions for each subactionPath/Controller. I'll switch back to single XrAction instances once the problem is fixed (seems a OpenXR SDK bug)

@bluemarvin
Copy link
Contributor

I wonder how much effort it would take to make a noapi version using the OpenXR device. 🤔

@bluemarvin bluemarvin added this to the #11 polish milestone May 27, 2020
@MortimerGoro MortimerGoro self-assigned this May 27, 2020
Copy link
Contributor

@bluemarvin bluemarvin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should enable this to build on master tires to prevent bit rot.

@MortimerGoro
Copy link
Contributor Author

I wonder how much effort it would take to make a noapi version using the OpenXR device. 🤔

We would need some loader or OpenXR runtime for noapi. I wonder if something like https://monado.freedesktop.org/ could do the job.

I think we should enable this to build on master tires to prevent bit rot.

Is user.properties path easy to support in TC?

@bluemarvin
Copy link
Contributor

I wonder how much effort it would take to make a noapi version using the OpenXR device. thinking

We would need some loader or OpenXR runtime for noapi. I wonder if something like https://monado.freedesktop.org/ could do the job.

I'll take a look.

I think we should enable this to build on master tires to prevent bit rot.

Is user.properties path easy to support in TC?

I probably could support it but it would be easier if it was just another platform since I would need to run the regular builds, then set the property and then run the build just for the OpenXR build.

@bluemarvin bluemarvin merged commit 3c70b99 into master Jun 1, 2020
@bluemarvin bluemarvin deleted the mortimer/openxr branch June 1, 2020 23:00
@bluemarvin
Copy link
Contributor

Opened this issue #3447

I don't want this to bitrot from lack of building on taskcluster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants