mrsylvestre

H.265 (HEVC) su AMD 60x0 e 70x0. Non conosco NVidia.

Not really, unless you absolutely need a direct USB connection. Some also say that colour range and latency are a bit better with Connect. The colour improvement seem to be only noticeable in dark environments. Nice to kill zombies or vampires in other games, not really relevant to DCS unless you mostly fly night missions. The range of render resolutions offered by Pico Connect is also comparatively low. Max resolution is 2560x2560 per eye. That corresponds to VD's "High" setting. For DCS, I can use VD's "Ultra" and VDXR with the same performance (fps, smoothness) as Pico Connect with its lower resolution. It is possible to edit a (huge) config file to increase Connect's resolution but performance then tanks rapidly.

Pico connect requires Steam. VD is advisable over pico connect and not only because it doesn't require Steam: even when used with the Steam OpenXR runtime to level out the playing field, VD performance remains superior to Pico Connect. That said, Pico Connect is a significant improvement over its predecessor (Streaming Assistant), but it doesn't match VD (yet?) performance-wise.

A/ On the software side: 1. Buy Virtual Desktop (VD) from the Pico Store and install it on the Pico, install the corresponding VD application on your PC. If DCS is your only PCVR game, you do not need anything else on your PC at this time (no SteamVR, OpenVR, WMR, OpenXR stuff or whatever you may have read here or elsewhere in the past, no nothing). If you have other PCVR games, just add steamVR, but avoid adding anything else. Most advice regarding VR software for your PC that you will find in the forums pertain to the HP G2, Meta Quest, Pimax, Varjo and others. It is not always relevant to your Pico 4 and will probably do more harm than good. 2. Make sure to use the VDXR option in the VD application on the PC 3. With your RTX 4080, you may want to set VD resolution (on the Pico) to Godlike (3120x3120 per eye), 72 Hz, SSW disabled (this will avoid retroprojection artefacts) 4. On the DCS side, for the graphics settings, start with the VR preset (pretty low image complexity, you can improve on that later). Do not forget to enable VR in the appropriate tab of the DCS settings. Leave the pixel density in that tab to 1 at this time. 5. Enjoy 6. From then on, you may want to fine-tune your settings and system. Install QuadViews [github.com], do not mess with its settings, the defaults for the Pico 4 are great and provide a noticeable performance boost (fps) at the cost of minimal degradation of the periphery of the images. You can then progressively start to increase the graphics complexity in DCS until your system cannot maintain the 72 fps for a stutter-free experience (or, if you are stutter-tolerant, until these become unacceptable to you), then back off a little. Do not forget to enjoy the game and VR experience for what it is, learn to live with the compromises anyone needs to accept until the RTX6090 will be on the market, this tuning can become obsessive at times. There might be some tuning left on the NVidia drivers side but I can't provide advice there, as an AMD Radeon user. Also, it is being said that QuadViews may end up being included in VD's VDXR in the coming weeks so the first part of step 6 might not be required anymore anytime soonTM. B/ On the hardware side: Check the requirements of VD for network connectivity. Unless you router is close to your gaming PC, you may want to consider adding a cheap dedicated WIFI router to your system. It will connect the Pico 4 wirelessly to the PC. The connection between the PC and the router should be a network cable. Have fun! -- Edit: typos.

I concur. When it works, Pico Connect is a significant improvement over Streaming Assistant but regarding use with DCS, VD with VDXR is still a notch above and less prone to problems.

Caveat: Pico Connect "ultra" is the same resolution as Virtual Desktop "high" (2560x2560 per eye). It is possible to redefine Pico Connect resolution by editing a (big) config file but when set on par with Virtual Desktop higher resolutions, performance in DCS is not as good. Connect is a big improvement on Streaming Assistant, especially with regard to useability, but regarding performance in DCS it is still behind Virtual Desktop.

That is correct. My routine is launch 1/ Virtual Desktop streamer on the PC, 2/ Launch VD on the headset, 3/ Connect, 4/ On the virtual desktop screen that is displayed in the headset once connected, launch DCS from the Windows start menu or any shortcut to wherever the dcs.exe is on your PC. And that's it, really, it just works. No command line option needed (just "use VR" checked in DCS options but if it works with the QuestLink app, I assume it is checked already). The only thing that I can think off is to check that OpenXR runtime is set to VDXR in the options of the Virtual Desktop streamer (on the PC). That, or the Quest software is somehow messing up the VR subsystem even if it is not invoked.

Perhaps we should not overthink it. In the end, what matters is that with your settings and your QPro, you get stable native 72 fps with no (perceived) loss of image quality. The fluidity alone is probably worth it.

Just tried that out of curiosity. As I still have a Pico 4 (no eye tracking), not a Quest Pro, 0.25 x 0.35 for the (fixed) centre is too restricted. I increased that to 0.45 x 0.45 which is acceptable with fixed foveated rendering and I could still get 72 fps with my setup. However, I get increased shimmering, even in the centre with resolution x 1.5, with High + SGSR. Because my GPU is AMD, I use MSAA 2x as antialiasing (no DLAA or DLSS). Switched back to QVFR defaults. My thoughts about the whole process: downgrading from godlike (3072x3216 on the QPro) to high (2496x2592) but increasing centre resolution from 1.1 to 1.5 results in DCS rendering that part of the image at an about 20% higher resolution BUT... after rendering the periphery at lower resolution, it combines both at 2496x2592 (VD's "high" setting). This is then sent, at that resolution, to the encoder and streamed to the HMD where it is upscaled. Hence the 1.5 resolution increase for the centre is akin to supersampling (which is good) but in the end, less information is sent to the HMD, which has to make up for it by a relatively basic, low-computational cost upscaling algorithm (SGSR). With Godlike, the image passed to the encoder is 3072x3216 and inherently contains more info. To which extent this will translate into improved final image quality is affected by the streaming (and thus encoder) bitrate. If the bitrate is capped too low, the lossy compression will reduce (but not negate) the advantage of passing an higher resolution image to the encoder, but I doubt this would be the case in practice, with bitrates >= 150 Mbps. Hence, assuming the above is correct and encoding/streaming shenanigans notwithstanding, my understanding is that SGSR upscales the picture from "high" to "ultra" resolution but starting from a picture that has been produced with 1.5 supersampling at the centre (kind of SSAA, really). For the periphery it boils down to something like high with 0.5 downsampling then upscaled a bit from high to ultra.

+1 for QVFR benefits that depend on your hardware. On a 6950XT / 5800x3d system, the performance gain is significant. For instance, my DCS graphics settings are tuned (down) so that I can run the F-16 over Golan Heights instant action mission at 72 fps native (no retroprojection) on the Pico 4, with QVFR. This is with VD on Ultra (2736x2736 per eye). If I disable QVFR, everything else being unchanged, that system cannot reach 72 fps anymore (stutter fest). I guess that it is because in general with DCS VR my GPU is bottlenecking long before the CPU is, so offsetting some of the load from the GPU to the CPU with QVFR results in an overall performance increase. OTOH, with a 4090 monster that can cope with resolutions of 4000x4000+ per eye and flying the Apache over Paris, shifting some of the load to the CPU might be counterproductive. This could especially be the case in MP which is notorious for hammering the CPU. I would also assume that the extra load on the CPU from QVFR might increase with resolution.

Running VD with VDXR is simple and efficient. You may (or should) add QVFR to the mix for another bit of extra performance at negligible image quality cost. Since the latest DCS updates, DCS-MT is the default, you don't need to play with command-line options or anything like that. It just works. VD, VDXR and QVFR are the holy trinity of DCS VR on Pico 4. For less demanding games/sims (e.g. VTOL VR), the gap between SA and VD is not that big. But in DCS and MSFS2020 a lean, efficient VR software environment is essential.

Pico 4 is a bargain. Q3 has some advantages, but not overwhelming at this point, and these come at a price. Here is a short review on Reddit that I think sum it up very well: Meta Quest 3 vs. Pico 4 - A Closer Look into a PCVR player's perspective. This is for PCVR; story is different if you value standalone use as Meta's products have a much larger games library. Quest Pro would be even better as Dynamic Foveated Rendering can squeeze extra performance (Along with MSFS, DCS is probably the most taxing VR application your PC will see), but on some markets (Europe...) it costs twice as much as the Pico 4. In any case, with any headset that connect via WiFi or USB (Pico 4, Q2, Q3, QPro), it is preferable to only consider VR if you have an RTX3090 / RX6900XT class GPU or better and you are prepared to make compromises nevertheless. Software wise, Virtual Desktop with its built-in VDXR API/renderer is all you need for DCS (no SteamVR, Opencomposite, WMR, OpenXR Toolkit,...), along with Matt Bucchia's QVFR which also make it possible to do fixed foveated rendering to gain performance on headsets that do not have eye tracking, for nice performance improvement at negligible perceived image quality cost. Tune (usually down...) your graphic settings to sustain native refresh rate (72Hz, 72 fps) because retroprojection artefacts can be really annoying in flight sims.

Fixed it by copying the mission file from the missions subfolder in the Harrier installation to my default mission folder, then edited it. The original mission loadout is indeed invalid, you cannot have 3 mk82 mid-wing and a missile at wingtip anymore. Changed that to two mk82 per wing and that's it (don't forget to adjust loadout on the second wingman too). I also traded of an AIM9 for a sidearm. Not sure about the com's, tough. Never heard the Tornado in the attempts I made so far (until being blown to pieces by air defenses, that is).

Same issue here. I guess there might have been changes made to the permissible Harrier loadouts since 2021, rendering the default mission loadout invalid.

Still no news? This topic comes regularly in the virtual reality subforum. The other, civilian flightsim, nicely dissociates head and mouse cursor movement and it feels so much more natural and is so much precise to have the mouse move the cursor relative to the cockpit alone, not to where one may be looking. With the current DCS implementation, it is as if on the Windows desktop, the mouse pointer would be controlled by your hand and where you look, at the same time. Very unpractical. Please ED, consider adding an MSFS-like mouse behaviour as an option.

I am confortable using mods (e.g. VAICOMPRO community for natural voice communications with the AI - once it is correctly setup, it is a game changer for single player). IvyVR seems well-designed, thanks for the link. One still need trackers (but indeed Vive trackers seem to be a viable option) which add an additional layer of complexity compared to the mouse implementation for VR in MSFS. IvyVR may ultimately be even more realistic, requiring larger gestures and body movement for switches that are not close to the HOTAS but may be less convenient to players that have a chair with armrests or that use a stick and throttle on a desk.

Sadly not at this time. In DCS VR, if you move your head, the mouse cursor moves. This is appreciated by some, as by binding a "mouse click" action on a HOTAS button, it allows to "look and click" in the cockpit, without the need to pick up the mouse. Others including myself would like to have an option for the mouse cursor to behave like in MSFS: when you point to a control in the cockpit, the cursor stays there until you move the mouse, as a metaphor for the pilot's hand, irrespective of any movement of your head (also in MSFS, after some time if the mouse is inactive, the cursor disappears and the position is reset to the center of your field of view when you start to used it again so you don't have to look everywhere in the cockpit to find it). This approach, if implemented in DCS, would allow much more precise interactions with the controls and some may argue that it would also be more realistic. IRL, when you are adjusting something with you hand, you don't have to compensate if you change your head position or gaze away. Also real pilots cannot "look and click" cockpit switches, knobs etc without letting go either the throttle or the stick. But to each its own, I don't advocate removing the current mouse behaviour in VR, just implementing the option for the more natural behaviour explained here, which shouldn't be that complex considering that it is the default in VR in several other sims and games. Now that VR is showing all its potential and taking off within the user base thanks to the more affordable Q2, Q3, Pico 4 plus the higher-end headsets combined with current higher-end GPUs, I believe adding this feature should be a priority, but what do I know...

QuadViews and VDXR have made DCS VR much more enjoyable to me and many others. Many thanks for your passion-driven work and having shared it generously with us all, Matt @mbucchia !

Well yes, that is what the OP's question was about. In your frame of reference (TrackIR, OpenTrack, etc), if you hold your hand still the mouse pointer stays at same screen coordinates whatever head movements you do (that change what is displayed on the screen), whichever game you play (DCS, MSFS,...). In VR, you can have a pointer that stays where it is *relative to your virtual world* as long as your hand doesn't move even if you move your head. That is how it works in MSFS and many games, but not DCS, alas.

On MSFS, movement of the cursor by the mouse that only depends on the mouse, not where you are looking, is the default and as far as I know the only way. If you hover the mouse cursor over a fixed point in the cockpit it will stay there, no matter if you then move your head and gaze away, until you move the mouse again. Perhaps I am unaware of a different setting that would exist in MSFS (?), but that is how it works on my system, and I wish that this behaviour could also be available (as an option) on DCS to make it easier to get to the most finicky switches, especially because physical controls beyond those found on the HOTAS (button boxes emulating MCP's, MFD's, radio settings switches and rotaries, fuel system, etc) are not so practical in VR.

Does "best of both worlds" mean that mouse movement is added to head movement to determine the cursor position relative to the cockpit ? I think that it is precisely what OP's is trying to avoid. To explain it differently, the desired behaviour is that the (physical) mouse is a metaphor of your hand. In the real world, you can do one thing with your head while doing another one indepently with your hand: you can point your hand at a control and keep it there even if you gaze around. For instance, if you put the mouse cursor (blue cross) on, say, a TACAN course knob, it should stay there if you move your head (and VR headset) ever so slightly to look at the course needle on the HSI dial or MFD while you turn the knob. The cursor (your virtual hand) should only quit the knob if you move your physical mouse. That is what OP's and others would like to achieve, for more natural control. That is how it works in MSFS. It would be nice if ED could add an option to get that behaviour (without removing the current one, which some do prefer, because it allows to point and click without using the mouse just by looking at a control and binding a couple of HOTAS buttons to replace mouse left click/mouse right click).

Nope, unless there is an option in DCS that I haven't heard of that allows it to behave like MSFS or XPlane. In these sims, if you move the mouse to place the pointer on top of a button, knob or anywhere in the cockpit, it stays there even if you move your head to look around. In other words, movement of the mouse pointer is relative to the cockpit in MSFS and XPlane while it is relative to where you look in DCS. I can understand that some prefer the DCS way because it allows to "point and click" with your head and a joystick button only but many others find the MSFS/XPlane way more natural and certainly more accurate. Please ED, give us both options.

Using Radeon Chill to lock FPS at 45, or half 90 Hz refresh rate, is a neat trick. Thanks! I just tried it in MSFS 2020 and it allows for a really fluid experience, without retroprojection artefacts with the right level of scenery details. I previously tried to achieve that through limiting frame rate with the OpenXR Toolkit but that didn't entirely cure stutter. Currently, my DCS settings are tuned so that I can have 72 fps native (no retroprojection) on the Pico 4 but I may try to bump refresh up to 90 Hz and set the limiter at 45 to see if I can trade off FPS against increased resolution or scenery complexity while maintaining acceptable fluidity.

The Pico 4 can do 90 Hz and 72 Hz. I prefer 72 Hz native to 45 Hz (90/2) retroprojection. If PicoVR would add a 60 Hz option, I'd probably chose it.

Same GPU here but you have better CPU and RAM. With my 6950XT, I get a solid 72 fps in the Caucasus with the F-14 on a Pico 4, which is more demanding than your G2. Something is clearly amiss on your system. You should get better performance with your 6950XT than with the borrowed 3070. Perhaps you should start by eliminating possible trouble by disabling the OpenXR toolkit. Also check that you are not supersampling inadvertently much beyond the resolution of your headset, either in the DCS VR setting (let PD = 1) or in your VR runtime. For DCS, I use 2740x2740 pixels per eye as VR resolution for the 2160x2160 pixels Pico 4 panels, beyond that the fps degrade fast. This is with the QuadViews api layer added. Without QuadViews (which I don't suggest to install before you find the source of trouble, because it would be an additional layer of complexity), I wouldn't go above 2540x2540 pixels per eye to maintain 72 fps.