RealDCSpilot

OpenVR was the first VR API. Valve was already working on VR before Palmer Luckey popped up. If the Oculus thing wouldn't have gone wrong who knows what exercise OpenVR would have become... Well, makes no sense to speculate more about this. The real problem is the disruption that all this early greediness brought for the PCVR market.

@Dentedend10 The "Current OpenXR Runtime" setting tells Windows which "handler" is managing OpenXR. If it's set to SteamVR, SteamVR is the "handler". The problem is that WMR was a bad idea! Valve and Oculus were pretty close at the beginning, OpenVR could have been the unified API for VR and we never would have seen all this chaos. Then Facebook interfered and caught Oculus and thought it would be a good idea to build a closed platform within Windows, looking for domination on this tiny, much to young market. Later Microsoft had the same idea and transformed it's Hololens API WMR into a third VR API also trying to win a war here. They flooded the market with cheap half-assed WMR VR HMDs by Lenovo, Samsung, Acer, HP and more. This coup flopped hilariously, no developer needs a third API to waste more time and effort when he already needs to work for two other APIs. Today, years after this, Microsoft has finally pulled the plug on that idea. And you look at SteamVR in the wrong way, they are the only ones who still try to support as many HMDs as possible while Facebook gives a sh!t. Or are you able to play a Oculus exclusive game by simply starting it for your HP G2? With OpenXR we now have a second chance to get rid of this nonsense.

It drives me a bit nuts how people throw around the words and mixing stuff up adding more to the confusion. Let's try to clear this up: - VR runtimes and VR APIs - SteamVR can do OpenVR and OpenXR. Oculus can do LibOVR and OpenXR. Windows Mixed Reality can do WMR and OpenXR. (Microsoft couldn't find an additional name to distinguish between their VR runtime and VR API) :P 1. DCS now talks OpenXR 2. Before the latest patch DCS could only talk OpenVR (SteamVR's native VR API) and LibOVR (Oculus's native VR API). 3. DCS never could talk WMR, the Windows Mixed Reality API by Microsoft (Sadly HP chose WMR as main VR runtime for the Reverb series, here starts most of the trouble...). 4. Microsoft made a very bad "WMR for SteamVR plugin" so that WMR headset owners would be at least able to play VR games over SteamVR and it's OpenVR API because nobody really made VR games for WMR. This WMR plugin is basically a very underpaid translator, talking OpenVR to WMR, a bad choice of middleman software for popular headsets like HP's Reverb series. 5. So for DCS that means - it talked OpenVR to the WMR for SteamVR plugin wich translated everything to WMR. This wasn't working very well. Thank you Microsoft (good that they now finally stopped this). So OpenComposite came in for the rescue. It translates everything from DCS to OpenXR, the only other VR API that WMR understands. And OpenComposite put a lot of tuning options into it to compensate WMR performance troubles. It is the better translator. 6. OpenXR was developed by Khronos Group to end this mess - One API for ALL! 7. Guess what, SteamVR can also natively talk OpenXR. Oculus can also natively talk OpenXR. 8. OpenComposite is not OpenXR. Sadly a lot of people, mostly HP Reverb owners, refer to OpenComposite as OpenXR. That's not correct. It's also unfair to blame SteamVR for having bad performance if you plug a WMR headset to it via the inferior "WMR for SteamVR plugin". 9. For DCS now everything is about to change! SteamVR native HMD --> Oculus native HMD --> OpenXR --> DCS WMR native HMD --> No more translators needed, finally. Each VR runtime has OpenXR included for quite some time already. If you have a myriad of VR tweaks installed, especially if you were going the OpenComposite route, just start fresh. Step by Step. In the coming months a lot is going to change. Most guides are already deprecated now. Especially for DCS and VR and HP Reverb owners. (And no, DCS bought on Steam doesn't mean you have to use SteamVR. Steam as a shop and SteamVR as a system component are completely different things. You can now use DCS standalone or DCS from Steam with every VR runtime that is compatible with your VR HMD.)

It's native OpenXR, OpenComposite's workaround is deprecated now. All VR runtimes should be able to connect directly to OpenXR now, some still might have troubles (Pimax and Co.)

@VR Flight Guy in PJ Pants @NatoAviator Try to get rid of any additional tweak first. Basically start with vanilla DCS and your VR runtime only. SteamVR with VD (VR Flight Guy) or plain WMR (NatoAviator). This will continue in the next months, because a lot will change. Most of the known tweaks will get old and deprecated.

Two things, one is in your dcs.log, there should be a line with "INFO VISUALIZER (Main): LAUNCH IN VR : SteamVR/OpenXR : oculus" and the second is that when you start DCS and land in the main menu, you will be positioned quite high so that you are looking across the wing of the jet in the hangar. From there you simply press your VR recenter button and your height should be set right in front of the menu.

@VR Flight Guy in PJ Pants Pico is running fine. Virtual Desktop runs it emulating a Quest HMD. The DCS log says "INFO VISUALIZER (Main): LAUNCH IN VR : SteamVR/OpenXR : oculus" which is exactly what you want to have. Since VD's reprojection system runs on the headset, no problems! People mix up to much about SteamVR and OpenXR! SteamVR is just a runtime, OpenXR is an API. SteamVR was never the source of trouble for WMR headset users, it was the half-baked WMR for SteamVR plugin by Microsoft. OpenComposite was basically made for bypassing this terrible WMR plugin. The whole thing was just a failed attempt by Microsoft to establish a third VR market platform. But luckily no developer really cared about WMR as an API.

@Assamita On VD's Discord they say you have to disable energy saving options and factory reset the device. The issue came for some people after the 5.3.2 update.

It's my 7th HMD since 2016 and the one with the fewest inconveniences...

For "UI Layer" i have bound 2 HOTAS buttons on my throttle grip to left click, right click and one encoder dial of my throttle grip to mouse wheel forward and mouse wheel backward. Gives you all the same functionality like with a mouse and no need for running extra mapping software. Yes, they will continue to work. Other people also use classic trackball devices as alternative to binding mouse buttons to HOTAS. I believe there is even a binding somewhere to hide and unhide this cursor. Have to search for it again...

The trick is to give VD some time in Wifi first before switching Wifi off in the headset. VD makes a copy protection check over internet once it started, so it needs Wifi on the headset for a small amount of time.

In VR options, check "use mouse". Then you have normal mouse functionality. Unchecked, you get the view-centered fixed cursor and to get the most out of it, bind mouse button functions in UI layer to your HOTAS (for straightly looking at buttons in the cockpit and using them without lifting a hand from HOTAS).

@rosteven1 To which VR API do you connect via VD? OpenVR via SteamVR or Oculus without SteamVR? I'm always running SteamVR and DCS on OpenVR on my end (without audio issues, Discord works, but i don't use SRS).

@Mr_sukebe For easy enabling USB tethering use this .apk: https://drive.google.com/file/d/1PUTpT9boTKssDXQ2qUCLxOKM3LPxQtlA/view The rest depends on Windows networking settings. It might switch to a public network type automatically everytime and you have to set it back to private. But in the end, you only get stable 1200 Mb/s and maybe a marginal cut in latency for USB tethering. You loose the charging capability during playing, your PC's USB connector can't provide much power. I have my Pico connected to it's charger with a long USB-C cable and i'm back to Wifi5 at 5GHz connection. I'm in the same room with my router and the connection is fantastic. USB tethering only helps with low Wifi connection quality situations. However, another option is a USB-C Ethernet adapter...

Alright, got my new machine on friday, was pretty busy installing and migrating all the stuff... When i started DCS for the first time, i got shivers down my spine. Never seen this image quality and performance in VR in DCS. 3840x3840 per eye resolution, DCS settings on ultra but without any AntiAliasing. It's mind blowing.

There were discussions that ED will never implement DLSS and stuff. But well, it does make so much sense. With OpenXR it's the same. It wouldn't make sense to not implement it and get rid of the old VR APIs.

All our troubles will come to an end...

SteamVR and Steam are technically two completely different things. Valve is the much lesser evil if you go down that road. Look at the Microsoft store or the one from Epic...

@VR Flight Guy in PJ Pants I took our screenshots to compare resolution quality, it's quite obvious that you run at much lower supersampling. There is no magic, only sacrifices to make to trade in more fps. I zoomed in a little to make it more visible, your cockpit readability suffers pretty much. On top of that, i took my screenshot on ground which costs extra fps. I'm personally happy with 60 fps without extra fiddling and nearly all ingame settings on ultra. SteamVR SS is around 3060x3060 per eye.

@Mr_sukebe You asked the wrong question. His answer is about OpenXR support for native Android VR apps running on the device. This is in experimental state: https://developer-global.pico-interactive.com/sdk?deviceId=1&platformId=1&itemId=7153484514247917573 OpenXR for PCVR is not in Pico's hands and doesn't need to be because both streaming solutions take care of this by connecting to SteamVR or Oculus VR on PC (Streaming Assistant or Virtual Desktop). And as i told you already, i'm easily playing MSFS2020 the whole time with VD and the Pico 4 and MSFS2020 does only support OpenXR. Please learn about the difference of a VR compositor and a VR API first. This is OpenXR (an API): https://www.khronos.org/openxr/ This is just a software translating or "talking" to OpenXR (it is not OpenXR!): https://mbucchia.github.io/OpenXR-Toolkit/opencomposite.html All known standard VR compositors can "talk" to OpenXR for a couple of years already (SteamVR, Oculus Runtime, WMR runtime...).

@VR Flight Guy in PJ Pants It's right there in the numbers of fpsVR: 120% ss resolution only. This is pretty low. Most people use 150% and more for sharper image quality. If it's enough for you, why not?

@Bearskin It's actually not about someone's bandwagon, it's about understanding the technology. With the Pico 4 you don't need any of the tampered OpenVR files. And Virtual Desktop is the current best streaming solution for mobile headsets. Guy Godin, the developer, is the current technology leader, he also was the first who introduced this feature. He worked together with Qualcomm to figure out the best practices to get the best out of the XR chipsets for realtime decoding etc. --- And please let's not fill this thread with false information, the Pico 4 runs native OpenXR PCVR titles without problems. There is no need to "avoid Steam", and SteamVR supports OpenXR natively for more than 2 years now. SteamVR is just a VR compositor, it takes care of the two per-eye images and all the tracking data that are provided by the API, OpenVR or OpenXR and sends them forth and back through the connected VR HMD... Eventually DCS will switch to OpenXR, there is no way around it because it's the most modern standard. I expect to see this with the new upcoming DCS engine. My only concern is how the term "OpenXR" is handled nowadays, in the sim community it's used way to much "colloqiual" for the methods of signal wrappers and not for what it truly is, a unified VR API.

Yes, but for those features you can also try the OpenVR hacks by fholger: https://github.com/fholger I tried this all, back then, when i still had my Valve Index. Now with the Pico 4, Virtual Desktop's performance options are simply enough and it runs much better than with my Index and all those "old" tweaks. In the end, it's really about time that ED comes up with multi-core support for DCS. All these hacks simply try to workaround the main problem, this old engine...

Sheesh, i know, from the outside all these OpenXR, OpenComposite and whatever VR API stuff might look quite confusing. But what you are doing there is basically this: Let's have a quick look what OpenComposite is: https://gitlab.com/znixian/OpenOVR "Reimplementation of OpenVR, passing all calls directly to LibOVR." It was made for VR games, that were only compiled with OpenVR support (for SteamVR native HMDs) so that Oculus users could run those games without having to use -- LibOVR (Oculus API) through SteamVR (OpenVR API) -- to get them running on their headsets. Since DCS is running both APIs, LibOVR and OpenVR, you don't need to put anything else in this pipeline! Coming back to the Pico 4, how it can hook into PCVR: Pico 4 -> Virtual Desktop -> LibOVR games (directly via using Oculus Software installed, the VR compositor for Oculus PCVR Headsets) and / or Pico 4 -> Virtual Desktop -> OpenVR games (directly via using SteamVR installed, the VR compositor for SteamVR headsets) and Pico 4 -> Virtual Desktop -> OpenXR games (again, i only know of MSFS2020 being a native OpenXR game - via SteamVR or Oculus Software) -- Since a couple of years the Oculus Software and SteamVR as VR compositors are also able to run games that are compiled with the OpenXR API only (MSFS2020) which is the latest general standard unified API for PCVR. Basically, DCS only needs to adopt OpenXR so LibOVR and OpenVR support will get deprecated instantly. For the Pico 4 this means, it get's OpenXR support automatically because you can run an OpenXR-only VR game via the Oculus compositor or the SteamVR compositor which get's managed by Virtual Desktop. -- Now it get's tricky, the "OpenXR" component of OpenComposite basically originated from the problem Microsoft introduced: Windows Mixed Reality. A third VR compositor for WMR headsets like the HP Reverb G, only compatible with (basically non-existent) WMR API games and OpenXR games (MSFS2020). To make WMR headsets able to play other VR games (the majority of VR games used to have only LibOVR and OpenVR support) they introduced the "Windows Mixed Reality plugin for SteamVR" where all the performance troubles started, especially in the flight sim community, because the Reverb G'series had excellent hardware specs and pricing, but nobody cared about it's poor VR API support when buying it. So all this "OpenXR" development was started by open-source developers, to solve the problem and bring some more features in for tuning. But it's all "middleman translator software", mainly bringing benefits only for HP Reverb owners or VR headset owners with weaker hardware and willing to tune the image quality options even more down to squeeze out some more performance for specific titles. If you don't have a WMR headset, the probability for placebo effect is high. Unless you are really using and needing to turn down rendering options with fixed foveated rendering and stuff.

They seem to visit their subforums much less than me. Maybe they aren't much interested in their products? (Looking at maintenance patches and fixes, changelogs... Oh my!)