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

Even so, I am quite sure Pimax staff will be a lot more comfortable about creating such products when they have in place solutions that can bypass Valve/SteamVR dependencies.

1 Like

Yes that is the intention of OpenXR. Pimax jist also needs to aim to join as well.

3 Likes

For Pimax to invest capital and reputation in putting hardware products in the field, with any unnecessary dependencies on third-party software that is constantly updated, cannot be forked, cannot be frozen, and has a terrible track record, is something no reasonable person would do.

OpenKnuckles might depend on some stable interface from SteamVR. After the track record I have seen from SteamVR, it might take very firm public commitments, strong legal contracts, and years or decades, to convince me that anything extra that depends on any interface, especially through third-party drivers like OpenKnuckles, to SteamVR, is worth specifically investing in.

If it’s not open-source so it can’t be suddenly degraded, then Keep It Simple and add lots of workarounds for the future is the only sustainable path. Obviously, not having tracksticks is consistent with Keep It Simple.

Being able to bypass LightHouse tracking entirely, I think, more important or at least in addition to any OpenKnuckles drivers, Qualcomm chips, etc, was necessary for Pimax to continue investing in their own controllers.

Bottom line, before the VR industry can grow much beyond its current size, SteamVR MUST be removed as a dependency. I highly doubt Facebook/Meta is an acceptable dependency either.

OpenHMD/OpenXR gives Pimax that assurance that other companies/software with already bad track records (ie. Valve/SteamVR) can’t break their stuff, which allows more investment from everyone. I think Pimax gets that, or is at least starting to, and I think we all hope Pimax is heading that direction now.

3 Likes

Linux and VR opensource unfortunately still lack proper adoption by the masses whom are lulled into windows and windows dependencies.

OpenXR will help by eliminated some issues with closed minded Meta(whom has no real 3rdparty support) and Valve whom do at times breaks things but are much more open than Meta to 3tdparties.

At least it looks like Valve is starting to come around with controllers; but likely due to OpenXR commitments.(Remember both Valve and Meta are apart if the Consortium)

OpenXR is a consortium that pimax has yet to join or become more compliant with.

OpenHmd would do better with Pimax if Pimax would work on adding there headset to the Opensource project. Deja Vu with Osvr problems of adoption.

1 Like

What web browser did you type that with? And even if you did use MSIE (which I highly doubt), that was forced into the confines of the standards dictated by the open-source community to MS, long ago.

What’s really happening here is the open-source community once again is being forced to shell out for the sustainable path that big companies will profit from.

Meanwhile, Pimax can profit from being the first on the sustainable path.

Android’s Chrome.

Yes I at one time used MS IE which was a crap browser and is mostly dead as MS has moved to there Edge Browser.

Do you remember MS trying to push out 3rdparty browsers by making non MS IE browsers work slow? Many web dev inserted code telling a user to download a non IE browser and would close the page. MS was sued over it and Netscape eventually became Firefox.

MS also at that time tried corrupt Java with there own changes to it.

If pimax actually embraces it. By not using microsoft dependencies like Vis C to develop there software. They have yet to even offer an install option to choose custom install location while using Inno installer? That @light demonstrated in very early pitool versions by decompiling and recompiling it with the custom install option.

They had a golden thing going with @SweViver & @arminelec 's Pimax Experience but killed this free project.

Now had they opensource the pitool interface properly we would have had PE like interfaces long ago and even a SteamVR Overlay for pitool settings that can be changed on the fly

@crony years ago tried to get pimax motivated with things like osvr.

3 Likes

Copanies like where I am working are searching for a solution as replacement for Oculus Quest mainly because of the Meta rogue data grabbing and closed environment, no way to escape. So an openXR would be a real alternative, to foster the industrial usage. Key will be interoperability for the different matrixes, big companies are just creating.

3 Likes

+1
I totally agree with you.

Apparently support for openxr would cause faster performance by skipping the translation of api layers. Is that correct?

These diagrams might help (replace WMR with Pimax):

https://m.imgur.com/a/VXwDOYX

It’s not so much about “translating APIs”, because in the end you either use OpenVR (SteamVR), LibOVR (Oculus) or OpenXR, that’s a single API, which eventually talks to the native platform API (eg: Pimax drivers). It’s about having to go through the SteamVR composition code before reaching this native platform support. This can 1) degrade visual quality because composition implies some image processing that can “lose pixels” in the process and 2) degrade performance, because a direct path from OpenXR to the native platform API would be one less step (and either OpenXR or the platform drivers have to do their composition anyway).

Composition means a few things: from “compositing” multiple layers (eg: the SteamVR home displaying on top of your game) to performing image reprojection, but also things like applying custom resolution and FOV settings.

Also, as you know OpenComposite does pretty good on certain platforms, in spite of indeed adding more API translations (OpenVR → OpenXR → Native), but these translations are lightweight, with no extra composition and complex processing.

6 Likes

Well that pretty much sums it up Pimax! Let us use the most efficient path.

Sincerely and politely: If at all possible, please consider OpenXR support with the 12K Reality HMD in development. A HMD that costs that much shouldn’t be an “emulator” for half the games we play. This appears to be a clear-cut way to improve inter-operability and performance in general. I for one have some games that I can’t seems to make work with SteamVR, but they work fine with Oculus runtimes. Sometimes it’s good to have a backup.

This really makes me want to ask @PimaxQuorra @PimaxUSA @hammerhead_gal : What are the barriers and challenges to incorporating/supporting OpenXR more directly?

@mbucchia and the folks associated with OpenComposite seems to understand this landscape very well. Please collaborate and communicate these challenges with the community!

4 Likes

Also, I feel like this is a reason MS/Asobo doesn’t listen to Pimax’s concerns about WideFOV support. Many people feel like Asobo only cares about Reverb G2 and Oculus users, but I’m starting to wonder if it’s more of a case of they are focused on simply providing VR in general and don’t want to have to “hold the hand” of every VR maker.

1 Like

Looking at the Pimax native SDK (part of the Pimax Unreal SDK for some reason), their native API for rendering looks extremely close to OpenXR and it includes all the primitives needed for OpenXR composition layer. Their handling of swapchains/frame submission is almost 1 to 1 mapping with the OpenXR standard. So getting a basic OpenXR runtime talking to this would be pretty straightforward (not saying trivial, but I would say a few weeks of work, certainly not many months or years). The input system in OpenXR does get complicated but even there it’s mostly a lot of boilerplate code needed, and the rest could also be mapped fairly easily to their native SDK.

The tricky part about OpenXR is passing compliance tests, and this however would take a while (months). But you don’t even need a compliant runtime to work with MSFS for example :slight_smile: as the game only uses a small subset of the standard.

2 Likes

fyi they may have fixed something in ms 2020 as i no longer get a performance hit using PP

1 Like

at normal fov i aint even using pp anymore,just openxr foveated rendering,with the pimax fix the culling is only on one side and far away into the edge with normal fov and because of foveated rendering i get decent performance.

2 Likes

nice that you can cope with that, but for me - i cant its too distracting and takes me out of the “VR experience”

S

1 Like

I totally agree with you. Support openxr.

Support OpenXR Please!

Did I understand correctly from the announcement today that Pimax is going to support OpenXR with the Reality series? Starting with the Crystal in Q3 2022?

I have started to write an OpenXR runtime that bridges to the Pimax native SDK (PVR):

After about 2 days of work, it’s working with a handful of example apps (so nothing really interesting yet) on my brand new 8KX.

I’ve just gotten DCS to start up with OpenComposite and OpenXR Toolkit. No SteamVR involved! The tracking is inverted somehow and I have to figure out why before I can even comment on performance and see if it’s worth pursuing…

PS: I’m doing this work for fun. I can’t guarantee this is going anywhere, but I’ll try to see if I can get MSFS and DCS to work with it, and give you a sneak peak of whether the performance gain is worth it :smiley:

EDIT: Late night, Flight Simulator is almost working… just 2 1 bug to fix!

EDIT2: Early morning… DCS is working perfectly now.

12 Likes