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

There is however a delay of significance when you translate from API to API, correct? - I could be wrong, but I’m basing this conclusion off of results demonstrated by use of software such as OpenComposite by @mbucchia with the ReverbG2. I’ve also noted Oculus for example can’t use my GPU fully. It just hovers at 60-80% no matter the settings. Only Oculus games, all Oculus games.
Still better than Revive as I have been told. The world of APIs and such is very murky to lay-people, non-devs, and enthusiasts such as myself. I don’t know how many people asked about why we can’t use OpenComposite for Pimax, only to discover it basically falls on Pimax to have native OpenXr support. I want my Pimax to speak OpenXR hahah. Feel free to educate and enlighten me.

1 Like

My #1 hesitation for buying a Pimax VR headset was and continues to be concern that as a smaller company with little market penetration, compatibility and support from various games and other software will be a significant problem. In practice, this issue hasn’t been nearly as bad as I feared it might be, but it hasn’t been entirely smooth sailing either.

Pimax pushes the boundaries with its hardware offerings. This is what drew me to their products. But frankly if their products aren’t supported by the software out there, then they might as well be big expensive paperweights.

Pimax can’t rely on popularity to cause game developers to cater to them. Instead, Pimax should aggressively engage game developers to support their products. They should be doing whatever it takes to cause that to happen, whether it’s providing free technical development support, free hardware to develop and test with, etc. It could even make sense in some cases for Pimax to offer to directly pay popular game developers to support their hardware.

Taken from this perspective of the bigger picture, it would seem to clarify that Pimax absolutely should support OpenXR. Pimax should be at the forefront of adopting something like this which will improve the compatibility of its products with games on the market.

Not having OpenXR support pushes things in the direction of game developers viewing Pimax as something to ignore. And perspective customers as viewing Pimax as something that’s not going to be supported by the games they want to play.

7 Likes

That’s actually not correct. You can use API layers to extend any OpenXR runtime. A great example is the Ultraleap OpenXR API layer which lets you use the Leap Motion camera for hand tracking on any headset (I’m using it on a G2, but it’s also standard on some Varjo, and more generally you can attach it on any headset, including a Quest 2 that already has hand tracking, and the API layer will take precedence over the Quest hand tracking). Another example is the Next Level Racing Motion Platform which also has an OpenXR API layer and should be usable with any headset. One final example, I implemented a proof-of-concept for Vulkan-on-Direct3D 12 support with OpenXR, adding support for Vulkan to any runtime capable of doing Direct3D 12.

OpenXR is super extensible. The problem is not OpenXR, but it is vendors not providing these API layers for OpenXR, and continuing to invest in SteamVR support instead.

OpenComposite is not my project. Credit goes to ZNix for initial implementation and Jabbah to finish it up. I have literally not done any work on it and do not deserve credit :slight_smile:

Not necessarily. Some API can be more easily adapted to others without the need to create “stalls” where you have to wait for some workload to complete or without introducing any latency. So in theory you can keep near-native performance and latency. A good example of it is the OpenXR runtime for Windows Mixed Reality. This runtime adapts the OpenXR API into the native WMR support (called Mirage), and in certain conditions, it can be 0 overhead. In others, it’s near-0 overhead (this is the case of FS2020), and it’s only in the worst case scenarios that it may add some overhead in the millisecond/frame range. Similar story, recently I implemented a proof-of-concept for Vulkan-on-Direct3D 12 support with OpenXR and it is also 0 overhead. It can be done when in the right conditions and developers are willing to make the efforts.

3 Likes

Haha , you’re right. OpenGL (like OpenVR) started with the best of intentions, but over years turned into a mess, Nvidia was happy to exploit with their “Game Ready Drivers” every week.

Vulkan was created with the same promise all over again. Hopefully with better results this time.

2 Likes

Good point, Pimax is also planning on entering the standalone market, so supporting OpenXR is a must, and it would ensure a common API across all of their headsets. Or even between the 12K in PC and mobile mode.

1 Like

Thanks for pointing it out! I guess I might need to revisit my opinion on OpenXR.

3 Likes

Pimax already works in SteamVR’s OpenXR with Index controllers. If Pimax were to write their own OpenXR runtime, it would mean just installing PiTool and absolutely no SteamVR at all and as such no drivers for Index/Vive controller.

I think Pimax having their own runtime is more useful for enterprise use cases. For the average gamer, compatibility with existing stuff is more important. In fact there are many people using Oculus headsets through SteamVR just for the overlays and tools and other vrchat stuffs.

1 Like

Varjo has OpenXR support. And it works with Index controllers. So how does that work?

1 Like

I recall the OpenXR logo (or maybe the Khrono Group) being displayed by Pimax with a bunch of their other affiliates logos, back as far as the KS and so assumed support had been on going all along. Why wouldn’t you when everyone else is?

2 Likes

Pimax Thumbstick Controllers.

If those work with OpenXR, and that works with PavlovVR/Onward, and if they are usable, then I am done with the fragile and expensive Valve Index controllers.

So that’s another reason for Pimax to have OpenXR compatibility. Having their own controller hardware, which can easily be much better than Valve’s (once again, most of Valve’s stuff being relatively poorly designed).

3 Likes

Varjo has OpenXR support. And it works with Index controllers. So how does that work?

It works even without SteamVR installed? Damn wish I had one to test with. It is pretty unique in that sense. They might have some code specifically to handle Index controllers. If Pimax could do the same then compatibility problem solved.

1 Like

that would be great. That would allow us using OpenComposite → OpenXR and get rid of SteamVR.

1 Like

I dont think it does work without SteamVR installed.

Will test and report back.

2 Likes

I’d be so mad if supporting OXR was all that was needed to see the thumb sticks see the light of day.

That excuse they came up with why they couldn’t is so paper thin.

Add OXR support might even get us a guardian when playing oculus games.

They are putting stick/AB on the 12K so either they have a solution or there will be some blow back :smiley:

1 Like

OpenXR != OpenVR
Valve == bad

In case I am not being clear here, Valve really is responsible for terrible damage to the VR industry.

Valve put insanely complicated inaccurate technology (ie. LightHouses, weird SteamVR specifications, unstable complicated config files) in place of everything other companies actually did well (eg. Oculus Constellation, ASW). Then they made that proprietary, refuse to fix critical bugs after years, at least they allowed third-party overlay apps (the ONLY feature of SteamVR), and called it all ‘OpenVR’.

OpenVR. Doesn’t work most of the time, black box no one can work with. But OpenVR.

Written like someone who has not even read the SteamVR specifications, or really had to tinker with its innards, or most of all, seen how unstable those are from one version to the next. Anything that works today would be unmaintainable tomorrow, and just from the bugs Valve refuses to fix even after years, you have to have seen enough to know that.

I’ve tried and given up on doing anything non-experimental with SteamVR files and such. I’ll touch other stuff, like DCS World files, or Hand Tracking processes, but I don’t try to preserve the ‘chaperone’ room setup files, etc, anymore.

EDIT: Holy WOW. I realize in retrospect I am willing to rely on a dozen or so third party mods for DCS World, not so well designed game software, managed through JSGME, without a second thought to it, but I am no longer willing to touch any single piece of SteamVR. Boo.

Because the 12K has non-LightHouse tracking, so presumably, it can present, without the real controllers interfering, emulated controllers to SteamVR, after using a completely different software and hardware stack.

Not entirely true. @Lucivr opengloves project already has made a hardware abstract layer(Open Knuckles Driver) Pimax could use to do stick controllers.

As we already saw with the HTC Cosmos controllers which are not SteamVR tracked they needed to introduce a wand translation(workaround) until DeVs supported there controller’s functions. That being said Kevin has said Qualcomm has made the new controllers work. So imagine they are seen as one of those already supported controllers if info is accurate on how well there working with current titles. Pimax just needs to evaluate and if viable(no real reason shouldn’t be) and execute a plan to create there driver hooking into the Open Knuckles driver giving proper credits as per Opensource.

Tg0 has also created there own Controller that can be SteamVR Tracked atm should be shipping June. (Etee)

I would imagine if pimax had been aware if the Open Knuckles driver project they would have released at min a Stick version of the Sword controllers even without the hand tracking. With this project they could have likely added extra inputs to the Sword Wand controllers.

But yes without projects like Open Knuckles Driver. SteamVR controller development is not very open/friendly. I believe if not mistaken LuciVR Open Gloves is one if the first/very few whom has been successful in making a Knuckles type driver.

1 Like

If OpenKuckles had been both available and sufficient at the time Pimax announced controllers with sticks were off the roadmap for now, I would think Pimax would have been very, very well aware of that. SteamVR has a bad track record, and much worse for not breaking third-party solutions. My guess would be that had something to do with it.

I was really not surprised to see the 12k both combine non-LightHouse tracking with LightHouse tracking, and also to use that as a workaround to obviate the Valve Index controllers. I saw that one happening a long way off, to the point of having planned similar things myself.

Pimax was not aware of the Open Knuckles. They admitted that. The project has been around for quite sometime before Marcin received the hybrid Sword controller. Iirc by at least a year or more.

Pimax like the Sword lite emulating a Vive Wand was trying to have Sword Stick emulate Index Controllers. But they by there own words were unable to accomplish it citing they needed Valve’s help. As they were not aware of the known Knuckles project.

Kevin already stated Qualcomm has been the one to make the 12k controllers work. Which is likely in part due to Qualcomm being uses in other Standalone. Pimax had always planbed on other bon Lighthouse tracking “Pi Tracking” but have not released any modules for current headsets except the 3rdparty Hand Tracker.

SadlyItsBradley’s recent video seems relevant to the 3rd party controller support discussion. In it, he claims that Valve is implementing generic support for other companies to use whatever arbitrary controller designs they want with SteamVR.

He mentions about how this has historically been a significant problem with SteamVR up to this point and that existing efforts have had to write very hacky drivers to get their controllers to work despite the lack of support.

So it looks like that whole situation is getting better now.

2 Likes