Forum Replies Created
-
Posts
-
That sounds as if the Varjo might use SteamVR’s OpenXR implementation, which is 64bit only although the spec demands 32 and 64bit support. Valve has been made aware of this several times by multiple people over the last three years. They didn’t even bother to reply.
There also is another severe spec violation in Valve’s OpenXR implementation that is a bit more complicated to explain:
In OpenXR there are two calls that you use at the start of a frame. The first tells OpenXR at which point in time a frame starts, the second makes the runtime wait briefly if necessary to meet the intended frame duration. Splitting these two things into two calls is tremendeously useful for more complex multithreaded rendering scenarios like vorpX’s separate game/headset rendering, which explitely is why OpenXR is designed this way.
Since Valve’s OpenXR actually is a SteamVR wrapper, but SteamVR handles these two things in one call – probably it just wasn’t designed with such a multithreading scenario in mind originally – Valve’s devs chose to violate the OpenXR specs here. Instead of adding the required functionality to SteamVR, they made their OpenXR wait in the call that signals the frame start, while the call that is supposed to do the waiting simply does nothing.
That doesn’t really matter much for OpenXR apps with a common single thread render loop, but it makes things go haywire for anyone who wants to take advantage of OpenXR’s multithreaded frame handling, which doesn’t work at all as intended. As if that wasn’t bad enough, Valve doesn’t even document their spec violation, you have to find out yourself why your stuff runs like crap with their OpenXR and try to work around it. Anyone mentioning this on their dev forums, again multiple people on multiple occasions, was also ignored, of course.
Long story short:
WMR’s and Meta’s OpenXR are fully working and complete. If other headset vendors did their own OpenXR runtime implementation, that will probably also be great.
SteamVR’s OpenXR however should only be used if you have to. It’s incomplete (no 32bit) and on top that doesn’t implement a core rendering mechanism correctly.
That’s a bit complicated unfortunately. To keep code duplication at a minimum the desktop viewer itself is a program that vorpX hooks into. I.e. vorpX loads a profile for the desktop viewer.
To have profiles for games that run unhooked while the desktop viewer is active, there has to be a new preset system that handles multiple user settings portions within a single profile. Luckily profiles are already split into a base and a user portion for other reasons, so the basic functionality won’t be too hard to implement. Still this is not some minor feature that can be added within a few days. The entire profile system is a somewhat complex beast in itself. Database handling, versioning, the cloud profile backend, file import/export etc, pretty much all of that would be affected one way or the other.
TLDR: Desktop viewer profiles are on the (fairly large) nice-to-have list, but not as simple to implement as it may seem, so I have no timeline for that currently.
That Oculus/DX12 incompatibility shouldn’t exist anmore, definitely not for Cyberpunk at least. Sorry for the confusion. I can’t recall currently whether there is still a reason for the warning, but probably I just forgot to remove it.
You will need the version linked below for a decent CP2077 experience. Works totally different for CP2077 than the last regular build you got on purchase:
A build with the latest CET for CP2077 2.11 included is now available, so noone has to go through the insufferable ordeal of reading two sentences of instructions displayed directly in front of them anymore. ;)
You appreciate my efforts? That is exceptionally kind of you. How on earth could I – with mere 20 years of experience as a 3D-artist – not realize that this butt ugly DX11 Metro Exodus has become practically unplayable after the release of the DX12 version with its life changing, probably even time bending new lighting. My sincerest apologies for only meeting 5/6 of your personal demands in regard to the Metro series. Not.
Seriously: you are the one with the ‘difficult developer’ issue, aren’t you? Ever heard of difficult users?
Official profiles with all the unique bells and whistles vorpX has to offer (and then some) for all games of the series minus the DX12 version of the last, but someone will still complain. You can’t make this shit up. Old fool that I am I truly thought I had seen it all over the last 10 years here until five minutes ago…
If the Varjo has its own OpenXR runtime, you have to make that the default one again. There probably is some button for that in the Varjo software.
BTW: Never let SteamVR make itself the default OpenXR runtime if your headset has its own. Steam’s OpenXR is not only incomplete (no 32bit version for older games at all), it’s also just a wrapper to SteamVR. So there is no reason to use it, not even for native SteamVR headsets, unless some app/game is OpenXR-exclusive.
Huh? There are profiles for all Metro games except for the Exodus DX12 version, which for the most part was an nVidia marketing stunt with marginally improved lighting at the cost of performance anyway.
BTW1: All Metro proflies come with DirectVR (“in-engine”) head tracking, automated FOV setup and various VR related tweaks. Also games like these are perfect for motion controller gestures (requires vorpX 24.1.0). Good luck finding any of that that elsewhere.
BTW2: IIRC the original DX9 versions of the first two games also perform better than their DX11 counterparts, which obviously is highly important for VR. So whether the enhanced edition builds are the better choice is quite debatable.
After launching the mod you should see a roughly 2m large panel with instructions when you turn your head slightly to the right. Virtually impossible to overlook.
For extra convenience the same instructions are also displayed in the top left corner of the game window on your monitor.
The mod uses the CyberEngineTweaks modding framework, which usually has to be updated after a Cyberpunk update.
For detailed information check the instructions panel in the launch room. Reading that is time well spent for other reasons as well.
Still working here (Steam version). Both 3D and DirectVR tracking.
If you encounter issues like broken 3D or a wrong camera field of view, please reset the game’s graphics options to default and double check whether you maybe accidentally disabled automatic game settings in vorpX. Often vorpX auto-adjusts settings that are vital for 3D to work correctly.
@ thebalt
Thanks!
Using a mod with a dxgi.dll is asking for trouble, almost certainly hooks into some functions that vorpX also hooks into. May work, but may also cause all sorts of problems. Hence the according warning that vorpX displays when such a potential conflict is detected.
If you encounter strange issues, that’s one of the first things you should check.
@ sylvan:
Awesome! Avoid SteamVR with a WMR headset whenever you can. Not just for vorpX, but in general. SteamVR acts just as a translation layer to native WMR with WMR headsets. Better to use WMR’s native OpenXR directly whenever possible instead.
It goes away automatically after two minutes or so. The latest cutting edge build linked below reduces the display time further:
Use WMR’s native OpenXR and set vorpX to OpenXR mode.
SteamVR is never necessary for vorpX with a WMR headset. It shouldn’t run at all actually. WMR’s native OpenXR implementation is always the best option for WMR headsets.
I see. I’ll think about it.
No promises though, there are pros and cons to weigh here. While technically that would be possible, it would be confusing as hell if a game actually uses long press or double press actions by itself. Would obviously cause a total mess in such cases.