Luke Ross has a program that fixes problems in steamVR implementation in his mod by patching the PiTool. “RealFluid only works in conjunction with my mods, as it only implements the small portion of the fix that must run elevated. However, if you want to experiment with it in other games, just do this: run PiTool, start CP2077, then after RealFluid has patched the server quit out of CP2077 and run the other games. As you long as you don’t quit PiTool, the server will stay patched.”
He also identified and compensated/workarounds for glitches with Pitools implementation with Oculus.
I had previously found a way recently to run Elite Dangerous in Oculus mode - thus not requiring PP mode whicb should result in 30 % better performance, and couldn’t figure out why it was performing crappy. We can run games bypassing SteamVR by running them with the oculus library in a command line.
I suspect this is why the hack didnt work as it should and hope to make this work again. It’s complicated as bypassing the launcher in order to use it with oculus libraries required passing a server_token for login in through a command line and I’ll have to look it up again as to how to make it work.
Anyway, thought this was interesting enough to share as it relates to the “bugs” that Luke Ross reported to Pimax in December.
Hopefully Pimax gets native OpenXR support in the future and fixed whatever Luke discovered was wrong with their SteamVR implementations. All I know is, if I switch to steam VR with his Mod the FPS tanks, and looks awesome in Oculus mode…
What’s “wrong” with SteamVR implementation on Pimax?
For what it’s worth, I still strongly suspect that all these times when people say they manage to get PP-only games running without PP, by forcing use of the Oculus API, this is not the result of the games actually rendering canted screens, but PP silently being enforced and reprojected somewhere behind the curtains, when going the OVR route.
Probably…I cant see the full render shape or mask and should look more closely at the scale when I switch FOv…that might give it away. Even then it would just be the input and output which may not reveal the rendering method, I think you are probably right especially since performance tanked.
I’m afraid my search-fu on this forum is awful, so I’m not likely capable of dredging them up – gave it a quick go, and got swamped with no-hits of more recent date.
Maybe some of the people who have managed the PP-requirement-bypassed-through-OVR trick in the past could be reading this about now, and feel motivated to chime in… Hopefully… :7
Anyway, previous posters have claimed to reap performance benefits, but being the mildly jaded reader, I am inclined to wonder if that didn’t come with a corresponding quality hit, that for one or several reasons didn’t bother them (…I mean, this is remembering how in VR talk, there has “forever” been posters talking about things like “no-quality-benefit-to-supersampling-above-150%”, and “no-difference-between-real-frames-and-ASW”, which are wi-hiildly contrary to my own experience :7).
But in this case realfluid does provide a clear and obvious benefit using oculus mode. Fps go way down with steamVR. The fact that Luke Ross found literal bugs in the steamVR implementation is what gets me wondering if it affects more than just his mods.
Yeah no youre right I think my other post regarding oculus mode nonPP with elite dnagerous is a waste as you said. Honestly I just get SO mad that my favorite game, which was one of the first AAA games to support VR. And one of the few multiplayer…fails to use NonPP mode. Sadly i think Frontier is dead
Well, technically it uses only PP – what we want from the game is non-PP operation, so that it will work natively with canted screen HMDs. :9 (term by the issue, or its workaround - depends on one’s vantage point :7)
(…and frankly - I expect even every “regular” (PP) headset (except any that are all stereo overlap) would also see a performance gain, if the game rendered canted, and the runtime then reprojected to the PP of the HMD; Pimax’s PP compatibility mode applied in the opposite direction.)
Unfortunately Frontier just about always make very, very different priorities than large swaths of its customer base. Latest victim on the chopping block is players on consoles, who will not be getting Odyssey.
I believe you confuse how Pimax works. In “Oculus mode” it behaves as Oculus runtime but it does not use Oculus runtime. So whatever it does is implemented by Pimax. With Oculus it only shares the name.
In SteamVR Pimax uses “driver direct mode” (Driver direct mode · ValveSoftware/openvr Wiki · GitHub) (do not confuse it with GPU direct mode), which again relies on Pimax implementing all the features (compositor, warping, etc.).
So switching Oculus/SteamVR just changes the interface the VR runtime is presented to the application, but the heavy lifting is done in Pimax runtime (pi_server).
Which means there is no magic in getting no-PP over Oculus interface - it is then done elsewhere - as I would expect that the apps which cannot handle canted rendering over one interface would not handle it equally over the other.
I get that changing the api doesnt help as it has to be translated back, yes, but Luke Ross identified bugs in steamvr implementation that are unresolved.
