Tech Talk #2 : What would you do if Pimax support OpenXR?

[PimaxQuorra]

Hey guys!

Welcome back to the second episode of Tech Talk!
Last week, we did received dozens of good suggestions and ideas from our user!

This week, we gonna talk about the OpenXR suggested by @drowhunter

As the title said,

What if Pimax supports OpenXR, what would you do to make for a more interoperable ecosystem?

Will this be a significant step forward for our Pimax community?

What’s something you’d love to see on Pimax with OpenXR?

Feel free to leave a comment or suggest a topic for discussion.
Beginning this week, we will select one lucky user to receive a SteamGift Card!

Regards.

[camera]

Open XR ? yes please would love to ditch steam as I’m hearing there are huge performance gains by doing this

s

[zuiquan1]

Asobo to this very day maintain that Pimax is not a supported headset because its apparent lack of OpenXR support. Not only that, they refuse to do anything about needing PP on in MSFS because they insist its a Pimax problem. So at the very least, OpenXR support could open the doors of communication between Pimax and MSFS to finally get actual wide FOV support in the game. Flight Simulators are the perfect place to showcase Pimax’s strengths and IMO they should be doing more to get them as issue free as possible.

[DJSlanr]

Will the 12k support it natively? Can you do so without joining Khronos group? Will pimax join Khronos group? What are the barriers?

[mirage335]

For me, if Pimax supported OpenHMD or OpenXR on Linux, without MSW OS as a host, I would develop robust integration of Virtual Machines with VR game engines.

Much of what we use ‘IRL’ involves physical computers - smartphones, watches, tablets, laptops, etc . Aircraft avionics also have standalone computers. Bringing these into VR easily necessitates VirtualMachines, with robust create/start/stop/networking. This is already possible under Linux, but MSW OS and native MSW virtualization programs impose too may workarounds for the very awkward Inter-Process Communication (IPC) of MSW.

I already have ‘ubiquitous bash.sh _userVBox’ ported to run under MSW/Cygwin (portable), running programs and opening files automatically in virtual machines, but the workarounds for awkward MSW issues are quite extensive.

On top of that, SteamVR is far too fragile. My strong expectation is that fragility has allowed game development companies to continue emphasizing desktop gaming, despite the severe drawbacks of immersion and poor control.

Bottom line is, most users have a very short learning curve, MSW OS and SteamVR already impose too many ways for things to go wrong - the market for sophisticated VR simulations with Linux/OpenHMD can be far larger than the potential market for MSW/SteamVR.

I am hopeful though, that the Pimax 12k standalone feature, may work at least for low-polygon scenes, at full resolution, and able to use VPS from Hetzner (ie. VirtualMachines in cloud). Then less interested users could still participate at the cost of signing up for a cloud provider account and just pennies per hour or a few dollars per month.

[koochy_rat]

I don’t quite understand what is being asked here. Pimax already works with OpenXR under SteamVR. Is Pimax wanting to write their own OpenXR runtime? If so, then you would not be able to use Index or Vive controllers with it since those need SteamVR.

[mirage335]

It’s very well worth losing/selling the Valve Index controllers to ditch SteamVR. Even more worth it to ditch MSW OS. And I say that, having found the Valve Index controllers very nice and effective.

[SmallBaguette]

I would be extremely surprised if Pimax aren’t already working on moving to OpenXR, especially for the Reality series.

OpenXR is where everything is moving, the sooner the better for Pimax.

[SmallBaguette]

That’s interesting, are you definitely sure that those controllers don’t work with OpenXR?

https://docs.unity3d.com/Packages/com.unity.xr.openxr@1.2/manual/features/valveindexcontrollerprofile.html

That makes me think they do. Also I thought valve had committed to supporting OpenXR themselves?

[twack3r]

Any HMD producer that relies on a non-native SteamVR implementation and requires their own sw should focus on implementing OpenXR as a top priority imo.

Relying on SteamVR/OpenVR leaves you at the whim of Valve’s quaility of service and effort into SteamVR/OpenVR and if the last few years are anything to go by, that’s a horrendous position to be in.

The entire industry is in the process of implementing OpenXR. So should Pimax.

[drowhunter]

I’ll start by immediately correcting the topic question and say,

It’s not about what “we would do”, it’s about what “Pimax has to do now” and long term what Pimax “wouldn’t have to do anymore…”

Let me explain …

Game support

More and more games contunue to “do the right thing” and support OpenXR.

“I forsee a day in the future when unless you own an Index or Vive 1+2 you would never see the steamVR window again.”

Recently @LukeRoss did a workaround for Pimax (to circumvent driver bugs ) forcing the REAL mod to use the oculus runtime. It was in this moment I realized how nice it was to simply launch a game and simply have it run directly in the headset without another layer in between. I know for a fact that Luke Ross is tired of having to program device specific fixes so perhaps OpenXR is in his future as well.

I also noticed that Praydog, author of the RE Engine mods has been doing tons of commits lately to make all of the RE mods use Open XR which means if Pimax would support Open XR launching these games would directly use the Pimax SDK.

OpenXR would be the equivalent of allowing software devs to directly use the Pimax SDK without even knowing it! SHOCKING.

Hardware Support

If Pimax adds support for OpenXR it could open up the door to further compatibility with VR 3.0 features like Pimax claims to support with the 12K and supports the current VR 2.0 feature they have the hardware for today like Hand and eye tracking.

Recently OpenXR toolkit added support for eye tracking, and If they did it purely through standard OpenXR interfaces Pimax would only have to support OpenXR eye tracking and it would “just work”. ( I know this is the intention of OpenXR I’m not sure if it’s there yet but i’m sure @mbucchia would know more about that )

In the future apps like Tinker Pilot, MSFS2020 will add hand tracking , another area where Pimax finds themselves years ahead of the competition but woefully unprepared.

Leap motion has improved there software to version 5 for major tracking improvements and Pimax has been promising support for a year now.

I’m not sure if Leap Motion are the ones who need to add OpenXR support to their driver but if Pimax supported it they would just have to hook up the hand tracking from OpenXR to the Leap Motion SDK 5 and never worry about it again.

Pimax can control their own fate

Remember all of those “workarounds” @SweViver had to do to prevent SteamVR’s from gimping Pimax headsets? Messing with GPUSpeed values and MaxReccommendedResolution in steamvr config files?

With OpenXR it would bypass all of this mess (as games move to OpenXR) and give Pimax control of their own performance via their own SDK.

Also if Pimax were part of the OpenXR consortium they would have a voice in getting support baked in for Canted Displays and Wide FOV. Imagine That!!

Conclusion

So by now you can see what my opening statrment means more clearly.

What Pimax needs to do is support OpenXR so that in the new Pimax Client/Pitool there is an option to

Set the OpenXR runtime to Pimax

instead of Oculus or SteamVR or WMR.

Handle all calls for VR initialization, rendering, eye and hand tracking and whatever future tech like body and mouth tracking the 12K has and connect it to the Pimax SDK so we can all reap the benefits.

This will prevent Pimax from having to directly support things in the future with adhoc solutions like like running Oculus games through their “Revive layer” since Oculus is switching fully to OpenXR as of I believe August this year. (I think you might need revive for older games though I might be wrong)

Half way there already?

Actually In some ways their “revive layer” probably took as much effort to create as it would take to implement OpenXR. Both approaches involve handling VR calls and translating them directly to Pimax’s SDK allowing for OculusSDK games to appear to run on the headset natively witbout Steam opening.

Anyway that’s all I have to say,
…go away now.

[camera]

seems liker a no brainer to me

[camera]

cmon guys (Pimax) you can do this we believe in you and maybe more sales will be generated potentially?

s

[DJSlanr]

Thats easy. If Pimax supports OpenXR natively it would add a great deal of value to the headset. 100s of dollars. It would leave no question as to why I would buy it over competitors such as G2 or Aero. One headet to rule them ALL

[Djonko]

@drowhunter

With OpenXR it would bypass all of this mess (as games move to OpenXR) and give Pimax control of their own performance via their own SDK.

Well technically OpenXR and SteamVR would fulfill the same role: being the bridge between the app and the headset. You would just use OpenXR instead of SteamVR (or even use OpenXR as a bridge to SteamVR). OpenXR doesn’t necessarily give more control than SteamVR (it all depends on the APIs they expose)

The main advantage of OpenXR is that game/app developers don’t need to release different versions anymore for steam, oculus, hololens etc. I’m not sure there’s an advantage to Pimax in the sense that the OpenXR api is more powerful than the SteamVR api. Maybe there is but like said, the whole idea is that OpenXR ends the current fragmentation.

[jojon]

Well, Pimax, just like everybody else, needs to produce an OpenXR driver for their headsets, because it is the standard, which is the standard, which is the standard, and that is that! -Let’s be rid of this fragmentated world of gated-off proprietary solutions (…although, I would not be in the least surprised to still see nefarious attempts at good old: “Embrace, Extend, Extinguish”).
There will still be many purveyors of OpenXR VR runtimes, including Valve, Oculus, Microsoft, and maybe Pimax themselves, too - who knows, each with the option to add their own “secret sauce”, but with the driver, the HMD should work with any of them, as should any application that addresses them through the OpenXR API.

What I will say to temper matters, is that any incorrect implementations that some body like Pimax may have in their OpenVR drivers… Well, there is nothing inherently preventing them from making the very same mistakes with their OpenXR drivers…

[mirage335]

I think it is a fair point though, that OpenHMD, which is OpenXR compatible, is a standard across all of MSW, Linux, Mac. Otherwise, the market is still constrained to MSW, which is more severe for high-end PCVR than it would be for other products.

[risa2000]

Hypothetically, you can do things in OpenXR you cannot do in SteamVR, like render multiple views (at different angles or at different resolutions). Something which could be pretty useful for high FOV headsets. The only problem is that OpenXR does not enforce the support for this. If you happen to run an OpenXR wrapper over SteamVR, you are pretty much done.

While the fragmentation will no longer be over the different APIs (SteamVR, Oculus, WMR, OpenXR), it will be over the “optional features”. And multiple views is not the only “optional feature” there. Let’s relive the OpenGL hell again!

Then, with the feature fragmentation, who will force the developers to implement those features which are not supported on all headsets (platforms)?

The last thing, OpenXR as currently specified is one monolithic run-time which must do all or nothing. It is not possible to have for example a controller manufacturer writing a controller driver and plug it into the framework side-by-side with HMD manufacturer writing theirs and haptic gloves manufacturer writing theirs (nothing to say about potentially different tracking systems each one uses).

Now one of them has to provide a complete implementation which includes all of those components because there is only one bridge API to face them all and it must be advertised at one point in the system.

So, while OpenXR looks like a nice effort it seems to be following similar design patterns as some other popular “designed by committee” APIs with unnecessary quirks and at current state creates more problems than solves.

[mirage335]

If OpenXR is supported as just a bunch of framebuffers, as with OpenHMD, then feature fragmentation goes away. SteamVR is actually really horrible in this regard, the way it does such simple things as overlays has imposed arbitrary limitations and weeks of workarounds for many developers.

I think in the end, it is developers who most need PCVR not to go the embrace/extend/extinguish route of MS Internet Explorer, and it will once again fall upon the scarce resources of the open-source community to create a Free/Libre Open Source Software ‘metaverse browser’, hardware support and standardized framebuffers included.