openXR compatibility

overload1 · March 11, 2021, 9:09am

Date: 2021 03 11
Issue Title: OpenXR
**Description:**OpenXR not working with pimax

HMD Model: 5k+
First 3 Numbers Serial: can’t tell, label too faded
Pitool Version: 269
HMD Firmware: 269
Tracking: steamvr lighthouse 1.0

System Info

Windows Version: win 10
CPU: i7 6700k
RAM: 16gb
Motherboard: some asus mobo, don’t recall.
GPU Model: 1080ti
GPU Driver: 461.72
SteamVR Version: 1.16.8
Oculus Version:

Hey there, I’m a vr developer that happens to be using pimax 5k+ for development.
I’ve recently started a new project using the unity’s all new unifying standard of XR toolkit
There seems to be some kind of a compatibility issue with pimax however, while it displays things fine on the monitor view, in-headset the game view is just about 1 square centimeter.

I should also note that this issue appears not only in content development but also in consumption of any XR toolkit based content. Also this issue is only present when using pimax, all my other headsets do not have this issue.

twack3r · March 11, 2021, 9:38am

Just to clarify, this is for OpenXR via SteamVR, correct?

I know that @risa2000 is pretty knowledgable from what I gathered, maybe he can chime in.

risa2000 · March 11, 2021, 9:47am

I believe there are two distinct (and quite different) things with confusing name:

Unity XR (https://docs.unity3d.com/Manual/XR.html), which is some sort of unified interface to anything VR from Unity. I.e. kind of new VR API, defined by Unity, analogy to OpenVR, OVR, OpenXR, etc.
OpenXR, which is one API for VR runtime (hardware).

Unfortunately there is not a direct relation (or dependency) between the two, apart from the name.

@overlord1 Which “XR” do you have on mind.

overload1 · March 11, 2021, 9:51am

This is openXR from unity’s XR toolkit unifying standart thing.

risa2000 · March 11, 2021, 1:01pm

I guess you are talking about this then:

Keep in mind that Pimax does not provide OpenXR SDK (or runtime). It supports SteamVR (OpenVR) and fakes OVR (Oculus VR) so it can run SteamVR and Oculus games.

If (ever) an OpenXR app runs on Pimax it is through OpenXR implementation by Valve (which wraps SteamVR runtime).

I am not sure who develops OpenXR plugin for Unity XR architecture, but from the page I googled (and referenced above) it seems to be rather Microsoft (and Windows MR) oriented. It is quite possible that the plugin does work correctly with OpenXR from Valve (SteamVR).

Either way, you better direct your questions to either OpenXR plugin developer, or Valve, if the incompatibility between the plugin and the runtime was caused by the runtime. Pimax cannot help you here.

overload1 · March 11, 2021, 1:13pm

only reason I come here is cause other headsets like htc vive, valve index and my oculus quest 2 do not suffer from this issue, only pimax does.

risa2000 · March 11, 2021, 1:43pm

The headsets you named are all “rather regular” headsets with quasi same FOVs and parallel camera rendering. Does the problem on Pimax appear with both Parallel projection and the native mode?
Does it happen in all FOVs (in particular in Small FOV)?
Does it happen when you turn off all “Pimax specific features” as, e.g. Motion smoothing, Foveated rendering, etc.?

overload1 · March 11, 2021, 3:16pm

Yes, the issue persists regardless of parallel projection being on or off, small fov & other pimax specific features had no effect on the matter.
Attached is monitor view of what the computer shows and a through the lens photo of what I see in the headset.
I should note that when headset on the head and you focus on it, you can see that it is showing the game view except that its the size of those few pixels

risa2000 · March 11, 2021, 4:18pm

What is the blue (cyan) poly line in the left bottom corner of the shot. Is it rendered into the headset?

overload1 · March 11, 2021, 4:34pm

room bounds. It is rendered fine and set to display at all times

risa2000 · March 11, 2021, 6:54pm

This is interesting. The chaperon and the scene image are supposed to be composited by Pimax (SteamVR driver). So it clearly does not do the job correctly with scene image, but the chaperon overlay is correct. Now the question is if the scene image is already wrong when getting into Pimax compositor, or not. Which is difficult to say, as the same codepath works fine when running native SteamVR apps.

overload1 · March 11, 2021, 10:09pm

beats me, I can try testing it though if you figure out how.
Any solutions come to mind on how I could deal with this or am I just doomed to wait till someone in power starts to care?

hammerhead_gal · March 12, 2021, 2:52am

Hi,we have noticed this need,

PimaxQuorra · March 12, 2021, 7:18am

Hello,

Our headset does support the OpenVR in the past, but the OpenXR you mentioned by unity’s XR toolkit seems having an issue on it.
We shall ask the engineer to take a look into this, whilst you can speak with the OpenXR about the compatibility.

Sincerely.

risa2000 · March 12, 2021, 10:34am

If you are familiar with Nvidia Nsight, you might try to hook up Pimax runtime and run your app, with it, but this is a bit tricky and I am not sure it even works anymore.

I might be able to have some means to trace the calls to Pimax driver, but I would need to test it first.

Either way, even if you figure it out, it will be either on Valve or Pimax to fix and neither is exactly famous for bug fixing .

mirage335 · March 17, 2021, 12:06am

Please remember that native OpenHMD (ie. standalone FOSS drivers independent of PiTool) would do much more, especially for Linux developers (ie. like me)!

risa2000 · March 17, 2021, 10:54am

Just to sum up here some findings I made thanks to help from @overload1:

It seems that when the headset implements IVRDriverDirectModeComponent interface in its OpenVR driver (which Pimax does) there is problem when the app uses OpenXR interface run over OpenVR.

The problem @overload1 recorded happens when the SteamVR runtime calls the driver and passes all rendered layers through IVRDriverDirectModeComponent::SubmitLayer function, where, with the layers it also passes a pose at which each layer has been rendered. It seems that the poses corresponding to the app are wrong (while the poses corresponding to the SteamVR overlay - e.g. the chaperon - are right).

There is already a bug report related to that on GitHub: https://github.com/ValveSoftware/openvr/issues/1502

This does not affect “native” SteamVR headsets (as Vive, Index, etc.) which use a different interface, but technically should affect Oculus headsets as well (if they run through OpenXR/OpenVR wrapper). Since Oculus has its own OpenXR implementation, this situation is probably not very likely to happen.