Tepnox

I think the theor. (theoretical) FPS would be the maximum possible FPS sustained by the CPU in the current scene - makes sense in a way, when the GPU is limiting the FPS (maximum utilization) but the CPU could push out more. If the CPU would be the limiting factor you can not push more FPS with the GPU, because in this scenario the GPU would always be waiting for the CPU to finish the calculations - here you would have an under-utilization of the GPU (GPU would idle around in parts). You should always aim for a GPU bound scenario - so the CPU has enough headroom left to always keep up with the GPU. In a CPU-bound scenario you would also have negative impacts on latency and maybe stuttering issues itself.

If you mean distortion in the loading screen, that is quite normal. Because ED did not implement a better VR loading environment you have to deal with that. Reason is the loading screen is not fully refreshed in-game, only when the loading bar moves - this means maybe typical 5-15 fps in there. ASW or motion reprojection needs a miniumum of frames to detect a motion vector to smooth out the image - so this leads to errors. I think this is quite unpleasent if you start freshly with VR and could lead to motion sickness. Such a shame VR is not a priority for ED development.

Wifi 6E is not yet implemented on the software-side but is planned for 2023 from Meta. The normal Wifi6 works fine so far, having 5Ghz and up to 2.5 Gbit bandwith with my router is superb. You can play via AirLink or with extra App Virtual Desktop via Wifi - not the greatest experience with DCS on my end because you will get some interruptions here and there, also the maximum 150 Mbit compressed picture has clearly visible compression artefacts. I simply prefer tethered to the PC.

Most nvidia control settings have no impact on VR quality / performance at all. The texture filtering options have minor visual impact - if this is worth your time in figuring out. Possible guides out there are mostly placebo, nothing you can really measure in numbers. I am running with default nvidia settings just fine since years with DCS World.

That is correct, in numbers: Meta Quest Pro: 1800x1920 per eye Meta Quest 2: 1832x1920 per eye The higher clocked computing power of Quest Pro does not really matter when playing VR on PC.

Joining the club. Ordered the ACE Collection Pedals end of December 2022 (Virpil EU Shop). Waited for 8 weeks and support still was trying to tell me to wait more 2 weeks. I canceled my order and got my money back via Paypal. Right now I ordered just the VPC Flightstick Extension, it has been 2 weeks since my order and nothing happened. Let's see how far we come this time. I fully understand the circumstances that EU sanctions for Belarus may lead to these problems. As far as I am aware, they try to mitigate this by distributing the shipment from Lithuania. But otherwise it is not fair for the customer either to just get a back-order timeframe that is completely undefined. EDIT: Got the extension after 3 weeks. My new WarBRD-D was 2 weeks from order to shipping (EU-Shop). It seems like shipping times are normalizing.

Well it still is "native" rendering because OTT overwrites the Oculus settings itself. If you have 5408x2736 setting enabled in the Oculus Home Settings this is a 1.0 baseline (the current rendering is 2816x2896 per eye - I don't know if that is a typo on Oculus Home but the actual rendering is slightly higher than the setting itself with Quest Pro). If you use 1.15 in OTT you will get 3232*3328 per eye (baseline multiplied with 1.15). You could also set 0.8 in OTT and get 2256*2320 per eye (baseline multiplied with 0.8). I know the Quest Pro has "natively" 1800x1920 pixels per eye lenses. So Supersampling happens all the time even with the lowest Oculus Home settings. So with OTT you do not add an additional layer, you simply overwrite the Oculus settings. The pixel setting in Oculus Home just defines the baseline and what is 1.0. If you want a prove: just set a desired supersampling in OTT (for example 1.3): Now you open the OculusDebugTool.exe (C:\Program Files\Oculus\Support\oculus-diagnostics) and will see the same setting mirrored in there: So OTT just manipulates the Oculus settings itself. If you set 0 in OTT you will get the baseline (=1.0) you defined in Oculus Home. This setting is also nice if you want to switch the pixel densitiy inside the game settings itself (when supported in that game). I prefer fixed values in OTT and also using profiles for different VR games - matter of taste.

I tried this in OpenXR with NIS and FSR and my results were not that sharp. Best results I got was the native supersampling. I use CAS for 70% extra sharpening in my case. This is very subjective and can really depend on the headset itself. I also read that some G2 users were going the opposite way: using 300 % native resolution and shrink that down with FSR and a 60% setting. Many ways to test and tweak ;D

The MSAA mask is the area that gets the Anti-Aliasing (MSAA needs to be enabled for this). It is a circle beginning from the center of the view. You can test this live in game. The smaller the value, tha smaller the MSAA area that gets anti-aliasing but you will notice jagged edged outside of that area. DCS is always rendering a bigger picture that you can actually see with you field of view of the headset. For Quest Pro the Mask Size 0.35 is sufficient and in my case the MSAA gets completely to the edges of my field of view. You can save some GPU-load this way but this setting does not have a big performance impact anymore especially on a RTX4090. The Enable HMD Mask setting cuts the area outside of the field of view and could save some rendering too. You can test this in game by turning on and off and you should see the difference on your 2D Monitor. The problem is, the HMD Mask that DCS uses is for Quest 2 field of view it seems. So it gets cut off a little too early especially on the inner parts - this way you limit your field of view. It is not big but was noticeable for me on the upper end of the picture and the inner parts of the field of view. So in my case I let DCS render the whole picture area and use OpenXR custom fixed Foveated rendering to get some performance gains back. The outer area of my field of view (that is not visible inside the headset) is only rendered with 1/16 of the pixel density and saves some bandwith. In my testing, this saves around 5% GPU load - if you tweak this more aggressively you can get around 8% performance back.

The first thing I would check is that you use a USB port that is directly connected to the CPU not the Mainboard chipset. You need to check your motherboard manual for this - this is very important. For my MSI B550 Mainboard the CPU connected ports with highest bandwith are red. I also get sometimes some issues with stuttering images inside of the Rift Software. In this case I unplug and connect the cable again. Also the Quest Pro often has this issue when you used it prior in stand-alone mode. Try a restart of the headset before connecting and starting the Quest Link connection. If you are sure that the USB port is correct maybe try another cable. Updating the chipset driver from your motherboard may also be an option. In my case I can use a USB-C to USB-C cable and I could also use a USB-A to USB-C cable. I tested both variants on my board. The USB-C to USB-C is the better option because the Quest Pro gets more power delivered and so I could use the headset theoretical for about 10 hours (the battery of the Quest Pro will still get lower with time). With USB-A to USB-C I could only play for maximum 5 hours, the battery would be depleted. Hope you can figure it out.

Glad you like your QP. Let me help you: 1. you can turn off the controllers by pressing the menu button (left controller) / oculus button (right controller) for about 10 seconds to switch them off. You will feel a vibration feedback when they shut down. It is possible that you get some ingame reminders, that your controllers can not be found - this happens not often and normally just in the moment you switch them off. I would recommend you enable the hand tracking as an alternative in the options of the QP - so you can still use the Quest Pro menu and switch to the Quest Link without controllers. Sadly the hand tracking is not (yet) supported in the Oculus Rift Software. But I normally start Quest Link and after the launch, I start DCS via mouse on my desktop. Works. The good thing is the controllers will be still be disconnected even after a shut down of the Quest Pro. If you want to reconnect them, just press the menu/oculus button again for 5-10 seconds until it vibrates. 2. Since OpenXR is supported natively in OpenBeta you do not need open composite any more (this was a translating API to get OpenVR and OpenXR connected). Just make sure, in the Oculus Software you have activated OpenXR runtime - this way the Oculus software will connect via OpenXR automatically without any other layer: For OpenXR you need a DCS shortcut with special commands: "C:\GAMES\DCS World\bin\DCS.exe" --force_enable_VR --force_OpenXR For OpenXR and experimental Multi-Threading (MT) use: "C:\GAMES\DCS World\bin-mt\DCS.exe" --force_enable_VR --force_OpenXR If you don't want to use Open XR, just start DCS the normal way (at least for standalone) - DCS will run natively in the Oculus runtime. There are no real benefits between OpenXR and Oculus Runtime. Never had any problems with the standard Oculus Runtime with my Rift S in the past. I could not find any improvements with OpenXR in that way. The only advantage with OpenXR is you can use the OpenXR Toolkit to tweak some more settings like additional sharpening, color saturation and color modification. I also use a custom fixed foveated rendering with OpenXR. Because I do not use the DCS mask, this helps me getting around 5% headroom of the GPU back (outer field of view is only 1/16 resolution and saves some GPU headroom this way). I can only talk about DCS standalone, I don't know if there are other startup problems when launching DCS via Steam.

This issue persists since DCS 2.8.2.35632 Open Beta - (25.01.2023). They changed something in the engine itself, it happens to OpenXR and Oculus Runtime. You can test this out for yourself, switch back to DCS Stable 2.8.1.34667.2 - (27.12.2022) there is no artificial FPS cap. I made a post about this a while ago, no reaction from ED so far. The FPS cap came also with strange GPU load (GPU less utilized since then). I currently play with ASW on (45 fps), so it doesn't bother me that much anymore.

Can not confirm on my end. MT still stuttering whereas ST is not.

Well, these are my notes and so for me (current setting) is 3905 "optimum" ;D As you can see, the encoder resolution does not change between 3905 and 3909 (it remains 3936x2080). The next step up in encoder resolution is 3910 (=3936x2240) but this setting and above result in artefacts on the lower end of the image. You can read out these values with the OculusDebugTool (C:\Program Files\Oculus\Support\oculus-diagnostics) with "Oculus Link" and "Oculus Link Detail" for yourself. If you want some extensive and critical analysis between Varjo and Quest Pro I recommend those videos from Lukas: So for me, coming from a 4 year old Rift S it was a huge step upwards. The Quest Pro pancake lenses are so much better than the typical fresnel lenses (G2, Quest2, Rift S etc.) - you can't argue with that. FOV has never been an issue for me and I did not own a Varjo or G2 for comparison - so I am kind of biased there. In the end the Quest Pro is not perfect either for sure. If I could design a headset, I would pick the Quest Pro pancake lenses and headset fitting style and combine this with an OLED display and native Display-Port connection (no stand alone). Let's see, what this year has in stores for us VR users. Cheers.

If you want some exact pixel tables per eye on super sampling, I did some testing: 1.00 (BASELINE) 2816x2896 (Oculus Home Settings = 5408x2736) 1.05 2960*3040 Blurry Instruments 1.10 3088*3184 Slightly Blurry Instruments 1.15 3232*3328 OK 1.20 3376*3472 1.25 3520*3616 Perfect Clarity 1.30 3664*3760 1.35 3792*3904 1.40 3936*4048 1.45 4080*4192 1.50 4224*4336 And for the encode resolution you should always go for the maximum possible resolution - the higher the better the compressed image quality. Settings too high can lead to artefacts on the lower image - there seems to be a maximum. Enc 3680 (3680x2080) Enc 3780 (3808x2080) Enc 3880 (3904x2080) Enc 3900 (3904x2080) Enc 3905 (3936x2080) Optimum Enc 3906 (3936x2080) Enc 3907 (3936x2080) Enc 3908 (3936x2080) Enc 3909 (3936x2080) Enc 3910 (3936x2240) Artefacts Enc 3960 (3968x2240) Artefacts Enc 4040 (4064x2240) Artefacts

Quest Pro user here, these are my settings for RTX4090 (was using RTX3080TI and RTX3090 prior): First: Baseline for your optimiziation should be Oculus Home Settings: I was running my Quest Pro prior on RTX3090, your RTX3080Ti is similar in GPU-power. I would recommend 80 Hz there. OTT Settings next: I would recommend 1.0 in OTT and 1.0 in DCS itself for your GPU. Beware: Since latest OpenBeta on OpenXR, the OTT settings are a multiplier on top of your DCS setting. Quest Link settings (via Cable): Again: I would recommend Encode Bitrate max. 500 Mbit on RTX3080Ti. I was getting weird image interruptions above that setting. (not the case on RTX4090). Ingame DCS settings: Because the RTX3080Ti only has 12 GB VRAM, it is necessary for VR to get Textures to Medium. If you plan on playing Multiplayer I would also recommend Terrain Textures on Low. Otherwise you will get alot of stuttering because of too much GPU VRAM usage. It was a pain in the ass to sort this out on my RTX3080Ti. Visibility Range is another option you could lower to High - personal preference. Another boost is Terrain Object Shadows to Off - again personal preference. It really depends on what map you fly and how busy your surrounding area is. DCS VR Tab: In addition to that, I run the OpenXR Toolkit having CAS (Sharpening) enabled with 70% and a custom Fixed Foveated rendering (I am not running the DCS HMD Mask - the mask size i not correct for Quest Pro). Give it a try. Happy flying. Loving my Quest Pro so far, the edge to edge clarity is a wonder and no more screen door effect - coming from Rift S too ;D

You can use the Windows Task Manager or MSI Afterburner tool to monitor GPU and CPU load. The internal DCS tool only shows the total FPS (top scale) and Latency (bottom scale) in ms for the Frame (White), Simulation (Green) and Present (Yellow). I have no clue what Present is for. This won't help identify your bottleneck. You can hover over with your mouse to see the numbers: You are GPU bottlenecked if your GPU utilization hits 95-100% with uncapped framerate (no V-Sync enabled in 2D, no ASW/Motion Reprojection in VR enabled). This is the ideal case you should aim for. So this means the GPU pushes hard to get all possible FPS on the screen and there is no GPU-headroom left. CPU and game engine could possibly render more, but the GPU is the limiting FPS-factor. You could reduce some graphics settings in-game and should gain some more FPS if this is your goal. This would look like this in MSI Afterburner: You are CPU bottlenecked / engine bottlenecked when you have uncapped framerate (no V-Sync enabled in 2D, no ASW/Motion Reprojection in VR enabled) but the GPU utilization will not max at 95-100%. This is the difficult part. In This case it could be CPU limiting (2 cores maxed out at 100% load for DCS - difficult to see because the task scheduler changes the currently used cores frequently) or the engine of DCS is limiting itself. We all know the DCS engine does not run very well with a lot of units on the map, so keep that in mind. This would look like this in MSI Afterburner: If you play in VR you should test this always with uncapped framerate - this means no ASW / motion reprojection enabled. Otherwise the FPS could get capped at your motion reprojection target (45 fps when 90 hz display is used for example) and the lower gpu load would be normal, because the gpu will not push higher above 45 fps until it could reach 90 fps technically. This implies your GPU is strong enough to go higher than 45 fps. If the GPU cannot even reach the motion reprojection target of 45 fps, the GPU utilization would max at 100% out for example with 38 fps. Framerate (and Frametime) can also be monitored in MSI Afterburner: Especially the frametimes (this is the consistency of rendered frames) are important in VR- huge spikes cause visual stuttering and can cause nausea. ASW or Motion Reprojection does not work very well on high-player-count multiplayer servers in DCS. Often the frametimes are all over the place in multiplayer compared to singleplayer. You can literally feel those spikes in VR: So the more even and smooth (perfect would be a straight line) the frametime, the better the VR experience. Since DCS 2.8.2.35632 Open Beta (25.01.2023) the GPU utilization is all over the place especially in VR and I suspect a game engine bug with the rendering. Very often the engine is the limiting factor and can not utilize the best GPU/CPU combinations out there. This also happens alot in recent AAA games, when there is no modern and proper multi-core support for the CPU inside of the game engine. I would not bother investing too much time in optimizing DCS settings right now. If we are lucky, the 4 core Multi-threading is coming in the next months, also DLSS is coming to DCS hopefully this year. Also the changes for VR (Native OpenXR support and some improvements there) could be a welcoming game changer this year.

Quest Pro user here. OpenXR is an API that runs natively with the Oculus Software. No need to install anything. DCS runs also on the Oculus API by default with 2.8.2.35759 Open Beta but there are still some visual and gpu performance issues even on Oculus API right now. OpenXR runs only with a special command line shortcut (DCS.exe --force_enable_VR --force_OpenXR). If you want to play DCS without these issues, I suggest you roll back from OpenBeta to Stable DCS 2.8.1.34667.2. OpenBeta is a VR mess since DCS 2.8.2.35632. I hope they figure this out with the next updates, I also stopped playing right now.

Issue with GPU not maxing out is still the same, even after updating to today's 2.8.2.35759 Open Beta. I tested with OpenXR command line and with default Oculus API, the strange GPU behaviour not maxing out is still the same.

No, the Oculus Software has to run always in the background. Otherwise your headset will not work. It automatically switches to OpenXR API. Just minimize it and you are good to go. OpenXR is just another API that is open source. I am not sure what benefits there are - most SteamVR (Reverb G2) users had better experiences and FPS in OpenXR. For Oculus users this never has been relevant - no gains on that front.

I started another thread in VR topic as I found the same issue with OpenBeta 2.8.2.35632. GPU load is broken and the simulation graph shows activity even when nothing happens (compared to 2.8.1.34667.2 Open Beta). I switched between both updates and this is totally reproduceable.

I can confirm since [2.8.2.35632 Open Beta] the gpu usage is broken and so we get less FPS, I started another thread in VR topic. Let's hope ED can figure it out.

Hello guys, can somebody check if you also got some serious gpu-load issues since OpenBeta 2.8.2.35632? I play normally uncapped in VR (no ASW, no fixed FPS) with my Quest Pro. Therefore my GPU load is always around 99% because I technically can not reach 90 fps. I did not experience any CPU-bottleneck the last days, even with heavy online multiplayer on 4YA Syria server. Since update 2.8.2.35632 my gpu-load is all over the place, very often only around 70-80 % gpu load on empty map in Syria. Also the FPS gets magically capped at 45 fps and then spikes to 60 fps but GPU-load never reaches 99% as before. This is very obvious in regions with some buildings around. I regularly stress test my setup around Beirut and GPU load has always been 99% for me here (which is fine). I triple checked my setup, did run complete slow repair with DCS (vanilla, no mods) and re-installed my graphics card driver (NVIDIA 528.24 Win11 64bit) with DDU. Did not change anything. I checked my ASW settings, ASW is off (forced ASW 45 fps, 30 fps is working when enabled). Again: I was running this setup and exactly same drivers yesterday and GPU load worked just fine. Since 2.8.2.35632 something has changed in the DCS engine it seems. Anybody else? EDIT: I can reproduce the issue (I manually switched between both updates): GPU load with DCS 2.8.1.34667.2 Open Beta looks like this (99% GPU-load and 38 FPS): GPU load with DCS 2.8.2.35632 Open Beta looks like this (92% GPU-load and 36 FPS): It gets worse when flying in active mission. The GPU load drops to 70-80 %. I don't know if this is an engine issue with 2.8.2.35632 Open Beta or Oculus SDK issue but this clearly costs valuable FPS and you can feel it while flying. When 5 fps are missing (just because the gpu load drops) you can feel this clearly in VR when the stuttering gets more and more noticeable. When you compare the ingame FPS graph you can clearly see, the green line gets more spikes in 2.8.2.35632 whereas in 2.8.1.34667.2 it is nearly flat. I think this is the simulation graph, so maybe the issue is here? I am on standalone DCS and OpenXR is my default API inside the Oculus Software using the Link Cable. I am not using Steam VR. My mission is empty and with default settings for Syria, I am parked with running engines in front of Beirut. I also checked F/A-18 and F16, similar GPU-load behavior with those modules.

Well - nothing new. Every new graphical improvement in DCS has lead to more hardware requirements in the past. It is a shame there is no separate VR-branch for DCS parallel to OpenBeta. The main focus for DCS will never be VR, because the ground layer of the game is for 2D. We can only hope for rapid hardware improvements in the future and maybe DLSS / FSR will do the trick temporarily.

He is using Rift S - there is only the original cable thats comes with it. So no improvements there.