Official Unity support for OpenXR in preview

For example, use the Oculus XR Plugin or Legacy Oculus Desktop, the controller is in the correct position and rotation without any changes. OpenVR always needs an offset, and it appears to be the same in OpenXR. Some offset is needed to be applied to the tracking so that the controller lines up with where it should be.

 

Thanks, I've had reports from others that it's with every controller type: not just Oculus Controllers. Can you confirm that the suggested tracking component is the "Tracked Pose Driver (New Input System)" component with bindings when using OpenXR?

 

I've seen some very noticeable offsets for the Oculus Touch controllers (for both the CV1 and Quest 2) when using OpenXR that weren't there in the Oculus plug-in. The offset is the most noticeable when physically tapping the left and right controllers together (using the same official Oculus controller models) -- in OculusXR the controllers don't intersect each other, while in OpenXR they tend to have a very pronounced overlap (I think it's almost 50% of the bounding box of the controller in the Oculus OpenXR runtime).

If you try to bounce the controller from the other side the controller's models' don't touch at all when they tap in the real world.

The positioning of the controller is -- with a mm or two -- identical in this setup (and in all attached photos). The only change made was switching the XR plugin and OpenXR runtime / my natural hand jitter holding the controllers (the 1-2 mm). I'm using the new action based input system, and have both the "Track Pose Driver (new input system)" component on the Main Camera, and the normal "Track Pose Driver" -- as I can't get the camera to follow the player's head without the latter (idk why).

Theis first photo is using the Oculus OpenXR runtime.


This second photo is using the Steam OpenXR runtime. There the offset is much smaller (and just happens to be almost exactly the width of the top tracking ring on the controllers).

 

What colin posted is a about what I'm seeing as well. This is a pretty huge difference. I haven't tested other controllers myself, but I have heard reports that other controller types have the same issue. Knuckles etc.

 

@the_real_apoxol , is there any plans for gamma color space support?

 

Anyone knows when will the quest apk build support is planned for ?

 

Anyone aware of a way to detect which OpenXR runtime is being used at runtime within Unity? Want to have different settings for Oculus vs Steam users.

 

You can distinguish between Oculus and SteamVR by detecting each configuration file. I made a small library for that.
https://github.com/shiena/OpenXRRuntimeSelector

Code (CSharp):

1. void Start()
2. {
3.     var openXRRuntimes = OpenXRRuntimeJsons.OpenXRRuntimeJson.GetRuntimeJsonPaths();
4.                                                                                                                
5.     void Initialize(string settingPath)
6.     {
7.         if (openXRRuntimes.TryGetValue(OpenXRRuntimeJsons.OpenXRRuntimeType.Oculus, out var oculusPath))
8.         {
9.             if (settingPath == oculusPath)
10.             {
11.                 // initialize for Oculus
12.             }
13.         }
14.         else if (openXRRuntimes.TryGetValue(OpenXRRuntimeJsons.OpenXRRuntimeType.SteamVR, out var steamPath))
15.         {
16.             if (settingPath == steamPath)
17.             {
18.                 // initialize for SteamVR
19.             }
20.         }
21.     }
22.                                                                                                                
23.     if (openXRRuntimes.TryGetValue(OpenXRRuntimeJsons.OpenXRRuntimeType.EnvironmentVariable, out var envPath))
24.     {
25.         Initialize(envPath);
26.     }
27.     else if (openXRRuntimes.TryGetValue(OpenXRRuntimeJsons.OpenXRRuntimeType.SystemDefault, out var defaultPath))
28.     {
29.         Initialize(defaultPath);
30.     }
31. }

 

Awesome dude cheers for this!

 

Maybe you can detect it this way as well.

Code (CSharp):

1. var lowerName = UnityEngine.XR.OpenXR.OpenXRRuntime.name.ToLower(CultureInfo.InvariantCulture);
2. if (lowerName.Contains("oculus"))
3. {
4.     // initialize for Oculus
5. }
6. else if (lowerName.Contains("steamvr"))
7. {
8.     // initialize for SteamVR
9. }

 

Regarding the origin offsets others have been reporting with Oculus controllers; I just wanted to add that I'm seeing something similar with Vive controllers.

I was starting to experiment with the OpenXR XR plugin today and seeing a discrepancy of (I think exactly) 10cm with the Vive controllers along the Z axis between the pose position got via OpenVR XR plugin and the pose from the OpenXR plugin.

 

Am I right to assume that once more platforms are supported (most notably Vive and Oculus) that the documentation front page will be updated? It's way too tiring to keep having to read this forum thread to figure out when exactly I can port my Vive/Oculus stuff to OpenXR reliably. It seems like it's currently working... but has plenty of bugs still?

 

Steam and Oculus OpenXR runtimes are both supported... Neither are perfect either, nor are at full feature parity with their per OpenXR runtimes. I think just the Quest 1/2 for native android builds are still fully unsupported.

But to be fair a lot of the XR plug-in developer first hear about those bugs here too... And it's still in preview/pre release.

Documentation can come after "fixing the thing" in my book (although really it take should be simultaneous and generated from inlined source code comments)... Which Unity as a whole is actually rather good at.

Any word on when haptic feedback will be added?

 

Will this support OpenGL / Vulkan on desktop? It seems that right now e.g. when you want to use OpenXR on Windows Desktop, Oculus forces the Graphics API to DX11, which means we can't test on Windows against OpenGL / Vulkan.

 

Could they be confusing HDRP only supporting DX11?
https://docs.unity3d.com/Packages/c...es.high-definition@7.1/manual/VR-in-HDRP.html

 

Thanks for the partial clarification. We're trying to use OpenXR on Vulkan. The Oculus plugin is not active, only OpenXR is active. Still, OpenXR with Vulkan doesn't seem to work at all and does not initialize any kind of XR, with the log about Oculus.
Is this a Oculus bug where the package does something (prevent XR entering) even while it's not the active XR Backend?

certainly sounds like there is some support and having set Unity to Vulkan on Windows Desktop and trying to use OpenXR should at least do something, or am I mistaken there? (right now it does nothing)

 

When trying to reproduce in a blank project all I get is immediate crashes on entering play mode;
reported as Case 1326119 [XR] Crash on pressing play after switching to Vulkan on Windows Desktop

 

OK, so to summarize: there is no way to use anything other than DX11 on Desktop right now when using OpenXR + Oculus.
Is that correct?

(reason we wanted to test that is that we get rendering differences on Desktop and Quest and wanted to reproduce/debug those by testing on Desktop with the same graphics backend. So one bug is covering more other bugs here )

 

I tried, and that's also what QA replied, and it doesn't crash but is still broken (double rendering), so reported
Case 1326186 [OpenXR][Vulkan] Oculus via SteamVR renders double in OpenXR

 

New SteamVR beta update 1.17.4 is out: https://steamcommunity.com/games/250820/announcements/detail/3007816130308944470

The change notes include:

My Oculus Link cable is broken at the minute so I can't check myself - does that fix this issue?

 

(I found another cable.) I'm still seeing a mismatch between where the Oculus OpenXR runtime says my controller is and where Steam's runtime says it is.

I put my left hand Touch controller on the table, resting on the ring upside down like so:


My Unity project uses a simple cuboid as a controller model; it binds to <XRController>{LeftHand}/devicePose and sets deviceRotation = pose.rotation and devicePosition = pose.position, nothing complex.

Here's what I see with the Oculus runtime:



Here's what I see with the new SteamVR beta 1.17.4 runtime - the model aligns with where the "stem" of the controller is in real life:



And here's what I see in the Input Debugger (Oculus, then SteamVR):




I didn't move the controller in between tests, but of course I did move my head and the HMD, so presumably that would affect these inputs. But note that, in SteamVR's case, the devicePose and pointer poses are the same, whereas in Oculus's case they differ. (Oculus is correct here.)

I assume these issues are all to do with the SteamVR runtime rather than Unity, but thought I'd report them here in case it's helpful.

 

The problem is that gamma with blit type never works much faster on quest and android platforms, but in the editor there is no way to enable different types of colors for different platforms.
Perhaps you could suggest something other than switching from one color space to another every time?

 

I have previously used the Oculus integration, but now trying out HP Reverb G2 in OpenXR package. But I am having difficulties finding a recenter command to use at runtime. Can anybody help with this?

 

Got a bit of an issue, OpenXR Headtracking feels Really jittery, but it's rock-solid when using the Oculus Loader. Any idea what that might be?

 

Is there any update on support for Oculus Quest yet?

 

I am using OpenXR with HP Reverb G2 and Oculus Rift S. No tracking issues... Using 2020.3.3f1 with latest packages

 

Using Oculus Rift S with OpenXR results in a strange extremely low FOV. Anyone have input on this issue?

 

Is there any updates coming regarding haptics?

 

Thanks for the haptics workaround!

 

Awesome! Now all we need is android support.

 

First of all, thanks for trying to get a workaround this issue... but, I've tried to implement this and it didn't work...

The Callback for the "Rumble" Function is working, but the controllers are not rumbling... (Using Oculus Quest 2 Here)

Code (CSharp):

1.  private void Rumble(InputDevice device)
2.     {
3.         Debug.Log($"HUMBLE on {device.name}");
4.         // Setting channel to 1 will work in 1.1.1 but will be fixed in future versions such that 0 would be the correct channel.
5.      
6.         var command0 = UnityEngine.InputSystem.XR.Haptics.SendHapticImpulseCommand.Create(0, _amplitude, _duration);
7.         device.ExecuteCommand(ref command0);
8.         Debug.Log($"Execute {command0.typeStatic} on {device.name} ");
9.  
10.      
11.         var command1 = UnityEngine.InputSystem.XR.Haptics.SendHapticImpulseCommand.Create(1, _amplitude, _duration);
12.         device.ExecuteCommand(ref command1);
13.      
14.         Debug.Log($"Execute {command1.typeStatic} on {device.name} ");
15.     }
16.  

as you can see I put some debugs to see if everything is being called and yes it is:



Any help on how I can make this work until any official patch is out ?

 

Is it possible to use OpenXR eye gaze interaction with Vive Pro Eye?