Forum Replies Created
-
Posts
-
The only relevant factor for natural depth/scale is the distance between the left and right camera. Ideally you want the average human eye distance which is roughly 65mm. If your camera rig is capable of meeting this requirement and the end result uses a spherical projection, depth and scale will be natural when playing back the video in vorpX’s 360° video mode.
Make sure that the game window is in the foreground by clicking into it. Input might not work as expected if the game is running in the background.
You only have to set the game resolution, vorpX figures out the best headset resolution based on that.
How high the resolution should be depends. No one size fits all anwser here unfortunately.
You have to find a balance between performance and fidelity. What that means in particular depends on the game, your PC and last but not least your personal preferences.
As a rule of thumb: Go as high as you think it’s OK performance wise. For ‘Full VR’ mode you’d typically want a 4:3 res or something slightly narrower is possible. For immersive/cinema mode you want a 16:10 or 16:9 res.
Please switch to the beta: https://www.vorpx.com/forums/topic/vorpx-23-1-0-beta/
Can’t recall currently why I didn’t also update the profile for the regular release last time it broke. Probably some code changes were necessary on top of the profile update.
With the standalone mod you see only the game in the task manager, that’s perfectly fine.
Please don’t use VD. Download the Quest/Oculus PC app if you haven’t already and then use Quest Link with Oculus mode selected in the mod config tool. No SteamVR required, no VD required.
If it works correctly, the first thing you see in the headset is a launch room with instructions and a motion controller tutorial.
2023/11/02
An updated version of alpha 9c for CP2077 2.02 is available. Fixes the broken HUD scaling in the last release.
Users of the most recent vorpX beta receive an incremental auto-update, standalone users have to redownload and reinstall the mod.
Keyboard shortcuts can be changed in the config app under ‘In-Game Key Bindigs’. The specific shortcut you are looking for is the EdgePeek shortcut.
Your other issue is probably caused by the cursor being drawn with the same shaders as the HUD. Since the HUD is scaled down for VR, the cursor in such a case might appear misaligned with unscaled menu elements. Fairly rare, but in some games that may happen. You can easily address that by switching to EdgePeeek mode when you have to use the menu. Using menus in EdgePeek mode is a lot more comfortable anyway. That’s actually its main purpose.
That is possible, but not configurable via the UI. If you aren‘t afraid of editing an .ini manually, follow the steps below:
- Close vorpX and the config app if running.
- Browse to C:\ProgramData\Animation Labs\vorpX.
- Open vorpControl.ini with a text editor.
- Add a new line at the end of the [Exclude] section. If e.g. the last line reads sExcl150=Xbox.exe, your new line would look like sExcl151=PartialName. No wildcard char, just the partial name. Make sure to raise the number by one, that‘s important.
- Save the changed .ini and start vorpX
Sorry, overlooked that you mentioned that in your post. I have the game in my Steam library. Will check whether something is possible.
That sounds extra weird… I don‘t have a direct solution, but typing your password into some text file and then use copy and paste for entering it in the game‘s password field should be a viable workaround. Pasting into the game‘s password field is definitely possible with the usual ctrl+v keyboard shortcut.
That‘s just a dev message I forgot to remove. Occasionally I use easy to spot stuff like that to briefly check whether or when a certain point in code is reached.
You can safely ignore this message. It‘s not an actual error.
Some games may refuse to start with this workaround, but most of the time making a copy of a game’s main .exe and using that instead of the original .exe does the trick.
Unfortunately not. Or to be more precise it’s theoretically possible in a technical sense, but impractical.
Modern games actually sometimes have an extra depth pass to build the depth buffers used for effects, but trying that retroactively without knowing which draw call draws geometry that has to be included into the depth pass and which doesn’t would be even more error prone than the generally similar heuristics required for G3D. Also these heuristics would have to be configured on a per game (or at least per engine) basis. Last but not least the performance impact would probably be similar to G3D.
In a nutshell: neat idea for sure, but even if/where possible not even close to the one-size-fits all solution you probably were hoping for.