RealDCSpilot

@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!)

@Lange_666 Virtual Desktop actually emulates a Quest headset. So you have the choice to play DCS via SteamVR and the OpenVR API or via Oculus VR API.

@upupandaway Well, i don't see coincidence with the recent Blackshark videos about 3D model details. But here, way to much interpreting into stuff that isn't there for my taste. And i don't have forgotten the old Kiowa stream where PC claimed that the Kiowa has already the best helicopter flight model ever seen in DCS... They really have to make up a lot for the community. Unless they really come up with a module at DCS's standards it's all overpromise and underdeliver.

This is a misunderstanding by many people. OpenXR has to be implemented by ED. It's about time to get rid of the current implemented OpenVR and OculusVR APIs. Hopefully this comes with the multi core engine upgrade. All current available VR HMDs support OpenXR, it's already integrated in SteamVR and the other VR Compositors. And of course the Pico 4 can run a native OpenXR application. Via VD and SteamVR for instance. The problem is, that the only real OpenXR game that i know and play is MSFS2020. All the other mentions of "OpenXR" in the VR sim community are about wrappers that do middleman translation from OpenVR or Oculus API to OpenXR in SteamVR or WMR or OpenComposite as VR compositors. The reason for all of this is mostly WMR, the most inferior VR compositor. Sadly the main VR compositor of the beloved HP Reverb series. If HP would have chosen one of the already established standard VR compositors, nobody would ever needed to program all those hacks.

@propeler Yeah, check this:

I actually never use Open Composite or any of the other VR compositor hacks like OpenXR toolkit etc. These are actually made for WMR headsets like the HP Reverb G2. I only run just VD and SteamVR and it performs and looks better than with my former Valve Index.

Can't relate to that on my end. I actually have much better image quality and performance with VD over Wifi than on my already sold Valve Index. The only minor compression issue i see is some color banding in the sky. Just for info, Pico's Streaming Assistant will also get a big update soon. There is already some info about the next version being in beta.

Would love to see the implementation of Black Shark 3 and MB-339 too.

Yeah, the ground crew takes a look at their watches and if it's too late they automatically install the NVG's... (check mission time)

I always use manual mode, can't even remember when i used auto mode the last time. Maybe 10 years ago? I use the Ka-50 for the most hairy situations, often trying to shoot from 8 km away, or even more, to take advantage of it's sniping capabilities.

Works on my end, set it to 0 and it's centered.

@cerebrave Yeah, it's getting better and better.

Ehm, no? Even with a 3080 you should be able to run the "Ultra" profile. Going 4090 is just my personal choice. And this here: is also in the works... Pico is keeping up with enhancing the software, nothing to worry about. The Pico 4 is currently one of the best PCVR headsets and not just because of it's price.

In a helicopter, all inputs count, all the time. Look closely, he also gives the right torque pedal a good kick for this quick change of attitude. And the cyclic input was quite large if you look closely. It's also good to see the typical latency of the air frame reaction to controls input. In a helicopter you are basically always steering ahead of what will happen shortly after your controls input. It's actually a good example to show how the DCS module fails. In DCS the Gazelle acts like a quad copter, where the rotors on the sides can produce constant negative thrust to induce a roll. In real life the main rotor just reduces lift in the directional quadrant of the rotor disc and increases lift on the opposite side (but only to a physical possible extent!). In DCS i can put the Gazelle completely upside down and push the collective down to produce negative thrust and positive lift! This is absolutely ridiculous for a helicopter flight model. Only RC quadcopters and aerobatic RC helicopters with high negative blade pitch angles can have such a weight thrust ratio. If you want to see what we should have gotten years ago and what the minimum is we should expect from the Kiowa, check the "beautiful simulator's" latest addition of helicopters. The Bell 407 with all helpers and assists deactivated demonstrates a pretty good helicopter flight model of this class, with all the basics done right.

With Virtual Desktop and it's high quality profiles you will barely see any compression artifacts in DCS. With high end hardware of course, i'm currently running a 3090 on the ultra setting, but will switch to a 4090 soon which will make the "godlike" setting possible.

There are bindings for translate cockpit camera up down, left right, forward backward...

@cerebrave That's good data collection there! To get the scope of the huge differences, it helps to calculate the full amount of pixels in each case. As an example, your "...(my VD is high 2496x2592 vs Airlink 1856x1872)..." means 12.939.264 pixels to push for both eyes in VD vs only 6.948.864 pixels for both eyes in airlink. I case of DCS, i would look for a better CPU (and maybe mainboard too) first. More than 6 cores and higher clock speeds help significantly (until a completely new engine might change this, but who knows when this is coming...). Regarding to RAM performance, this is all about budget. Slow DDR5 modules can be worse than higher clocked DDR4 modules. In my case, i bought a HEDT quad channel board years ago on purpose, getting crazy MB/s over 90.000 with DDR4@3600 for years while early DDR5's struggled to even reach 50.000. RAM speed can help in DCS, for shoveling data quickly from SSD to RAM to VRAM in your GPU but your CPU is always the middleman and should match the other system components accordingly or it will become the bottleneck. It's the old story, throwing money at the problem...

I can only guess that Oculus runs at a lower resolution, since the panel has a much lower resolution than the Pico4 panels (Quest2 has just one panel). 7 mio pixels against 9.3 mio pixels...

Uninstall and reinstall works on my end.

If "auto" sets the res to 2160x2160 it's not what you want. The rendered resolution always needs to be higher than the panel res because of lens distortion correction. For the Pico you should manually choose something above 3000x3000 per eye or the image will be blurry. VD also automatically sets resolution according to the profiles "High", "Ultra" etc. But if you choose a VD quality preset and SteamVR resolution independently you have more control. Maybe VD sets the resolution in SteamVR to high for your machine? My PC hardware is very different from yours. I sadly can't give you any other recommendation. An i5 9600 and a 3080 in a CPU bound situation like DCS might not be the best combination in general for VR. 6 cores and 6 threads only, DCS already runs on 4 cores and the other 2 cores have to manage all the rest (Windows, streaming, VR compositors...). I only can say that Airlink shouldn't run much better than VD. Something is really strange there.

@cerebrave I think i know now what's going on on your end. Still only speculation (i never used any Oculus Runtime on my system). You are using DCS's internal PD factor for Supersampling. This setting is a remnant from the very early days of VR in DCS, it's a SS value that goes directly into the Oculus Runtime but will work as an extra multiplicator if you are running OpenVR (SteamVR). This is the reason why it's always good to know what resolution you are truly running in the end of the VR compositor chain (the panels in your HMD). Please make another test with your OpenVR configuration, set PD in DCS to 1.0 and only modify the supersampling multiplicator in SteamVR for your own personal sweetspot between VR resolution and performance (DCS must be restarted everytime you change this). Another problem could be Oculus runtime interfering with SteamVR runtime, because the game supports both. Make sure you are not tunneling DCS running on Oculus runtime through SteamVR. Don't know if you can disable Oculus temporarily on your system to make sure it's not running in the background...