Tepnox

Haha - told you. Some misconfiguration on your end. But this is really something ;D Have fun tinkering around with DCS but hopefully with 100% power limit in the future . Cheers mate! Limiting the power limit is not really undervolting. Try some custom voltage curves with MSI Afterburner. The goal of undervolting should be to get nearly exactly the same FPS-results but with lower core voltage and therefore lower temperatures. This depends on the GPU silicone and can vary alot. My old Gigabyte 3080Ti did run perfectly with 750mV @ 1665 Mhz with 280 W around 75° C max. Stock settings had around the same Mhz but did run with 850mV, over 355 W and therefore 10 °C hotter.

Do you play other VR titles with the Quest Pro that you could test (via Oculus or Steam VR)? Is the behavior with 10 FPS the same there? There are too many unknown factors about your system. Try following these steps in one of my post for Quest Pro setup and try to figure out if there could be a misconfiguration on your end:

Found a new option in the special tab for the Apache named "MAN TRK Ramp-Up Speed": Please enlighten me, what exactly does this do? Did not found anything in recent changelogs and in ED fashion there is of course no tooltip when hovering over it.

I use OTT - most functions and alot more is only possible with OTT. Just some diagnostics overlays (Oculus Link Status for example) are only accessible with the ODT.

Hi there, you can put in any number in that field by typing into it. Afterwards you need to "Save and restart service" - these settings don't change on the fly (Encode bitrate is the only exception - this setting you can change and save on the fly while still in DCS). I tested alot of ranges there manually - posted the results after my initial post here. From Enc 3905 to 3909 you will have exactly 3936x2080 for the encoder resolution. Beginning with 3910 and above you will get distortion artefacts in the image. 3648 translates to 3648x2080 encoder resolution - with 3960 you will get artefacts. Hope this clears some things.

Core Features -> VR that would make sense. But hey, maybe VR is no core feature any more for ED. Who knows...

Actually quite good tip. I was wondering why sometimes the SAS heading-hold is active when taking off and sometimes it is off when taking off - despite having the paddles in the same spot. Quite irregular behavior right now of the SAS. This should help build up some muscle memory for the pedal-usage when SAS is no longer interfering with the take-off-procedure. Thx, will give it a try until ED fixes this awful SAS behavior.

I totally agree with you on this one. It has been a hit or miss with upgrading hardware for DCS and could lead to many frustrations, especially with patches in OpenBeta that could break the entire performance with just one patch for half the people. Well, it is what it is for now. The engine is outdated and not well optimized - especially with VR, I hope ED tries it's best to keep up. I also think it is a shame that there is no dedicated and optimized VR-branch for DCS. Especially alot more fine-tuning graphics-options would be neccessary for alot of people with VR and this gets ignored year by year from ED. In the long run ED just have to wait until the hardware components gets better and better and hopefully compensate the lack of optimization and laziness in coding it seems. This has been their strategy - no competition on the mil-sim-market, no need to rush. And don't get me started with the Early Access Module Policy. The F/A-18 launched May 2018 in Early Access - it is now 5 years and this thing is still labeled Early Access and not fully feature complete to this date. Pathetic.

Well I meant exactly what you described ;D Image Dips could be distortion (warping) or interruptions - thats what I meant.

Nothing special in my OpenXR-Toolkit. I am running DCS Open Beta with OpenXR and Multithreading (shortcut: "C:\GAMES\DCS World\bin-mt\DCS.exe" --force_enable_VR --force_OpenXR). Turbo-Mode is on and CAS (sharpening) is on. Some tweaks for color saturation and that is it. DCS with Multithreading really did come enjoyable in VR for me when enabling OpenXR Turbo-Mode and also activating HAGS (Hardware-accelerated GPU scheduling with Windows 11). OP is on Win10 - I think that option is not available there. As far as I can tell, no clue what else the problem could be.

Settings are fine (Quest Pro user here). The higher the resolution the sharper the image gets (supersampling). I am currently running a combined 6752 x 3472 resolution with my RTX4090 - no problem in DCS. Sorry for the OP having these issues with that beefy hardware. I suspect the i9 having problems with the P- and E-cores with DCS (read some DCS thread having this issue with DCS MT). Maybe Process Lasso can help by setting the correct core affinity. But I am no expert with Intel-CPU's - just a guess.

It depends on the graphics card. If you set the encode bitrate too high you will get occasionally audio- and image-stutter or dips. In my experience my RTX3090 could handle the bitrate up to 500 Mbit, above that i got these audio- / image dips. Switched to a RTX4090 and settings up to 960 Mbit for encode bitrate are possible. So you need to test this on your rig. Recommended settings are 300-500 Mbit. Default settings is 200 or 250 Mbit I think. You should only set a higher setting when compression artefacts on some color patterns are visibile for you and you want to get rid of it. Some people on this forum are fine with 300 Mbit, I personally can tell the difference betweeen 500 Mbit and 960 Mbit and so I prefer much higher settings. Bandwith should be no problem via the link cable, I suppose you get 2.0 Gbit in the speedtest and above. The limiting factor in this case is the graphics card. Happy testing.

I think that this works the way by design (2 clutches per axis - so it is separated by design). I have a new WarBRD-D with clutches and it behaves nearly the same like in your video. The only way to partly mitigate this issue is to lower the clutch resistance to the lowest possible point where you have a very low resistance but the stick still gets fixed in the last position. Light springs also do help to get less pressure resistance. Using the WarBRD-D with a 200mm extension from Virpil with a TM F-16 Grip and CosmoCam with center and light springs as a dead stick. Works "ok" with the Apache but if I am honest I would be much more precise hovering with my regular WarBRD (no extension) and the regular in-game central trim position mode. I have this new center-joystick-setup since 1 week so I think I need to practice some more flying to get a full picture and a final result. The dead stick is nice for muscle memory and helo-flying but some precision gets lost with the clutches for sure. Especially when hovering.

I am using DLAA in favor to DLSS (more blurry) in that civ sim in VR. Also using foveated rendering with the Quest Pro via OpenXR and this saves up to 20% GPU-headroom. Very nice combination and would be nice to have in DCS. Let's see what ED has in store for us this year!

Then you are blessed sir and this setting saves performance for you. I get nausiating effects while playing with 72 & 80 Hz - so not my cup of tea.

I suppose you mean it does not change while in-game? If so, yes - that is correct. You need to set the default supersampling in OTT before starting DCS. Do you have a separate profile inside of OTT for DCS running? Make sure you have the correct Supersampling settings there. If you use Multithreading DCS (MT) you need to make a new profile because it is another path and OTT does separate between DCS Singlethreading and DCS Multithreading (different path). If you don't use profiles the settings in the main window should work. It is quite annoying to figure out the best resolution and hardware limitation while having to permanently launching and exiting the game just to try some other value. Welcome to the club ;D If you are testing your settings I would also recommend using the "Pixel Density" Visual HUD to see the current pixel resolution that is active to verify if it is working: Beware: If you are using DCS without OpenXR this overlay is not visible (bugged in DCS since years with Oculus Runtime). If you are using OpenXR (DCS.exe Shortcut with additional target commands: --force_enable_VR --force_OpenXR) the ingame DCS setting for PD is correct with 1.0. OTT setting will then set as a multiplier). If the OTT Supersampling settings still do not change even after re-launching DCS, try resetting OTT via the Advanced tab. Somtimes OTT itself gets bugged and this could help:

Agreed. My online experience has been alot better with HAGS enabled on DCS Multithreading - especially when running with motion reprojection (ASW) on via OpenXR and Quest Pro. Prior I had serious stutters / jitters with DCS Singlethreading and HAGS enabled - which I could also see on my frametime-graph. Thx alot for the tip! I was indeed wondering in the past why DCS would be my only game that had issues with HAGS - that is the past. Fingers crossed ED don't mess this up in future patches - the Multithreading environment still needs more time in development.

I appreciate your feedback but what is the point of your theoretical discussion if you don't even own a Quest 2 / Quest Pro and try to discuss the settings of Oculus Home / OTT itself? I still get a better picture clarity when the encoder resolution is higher than the lenses pixel width itself - I tested it myself. Period. I technically don't know why that is the case but I see no point in arguing with a G2-user who can not test this for hisself. Good for you if you can live with 72Hz or even 60Hz on the G2 - arguing where the processing power is better spent is highly individual for sure.

Well the point is you can not go higher inside of the Oculus Home App than 5408*2736 (which is 2816x2896 per eye in real). To get a higher pixel count for supersampling you have to use ODT or OTT and set the Supersampling value there. This acts as a multiplier whereas 1.0 would be the baseline (2816x2896 per eye) and gets overridden with the ODT/OTT value. If you set 1.10 in ODT or OTT you will get 2816 times 1.10 and 2896 times 1.10. The mathematical end result in Supersampling resolution is: 3.097,6 * 3.185,6 per eye. The real value inside the headset is 3088*3184 - so there are some round up errors but you can test this for yourself the mathematical way and prove this with the Oculus Performance Pixel Overlay. Your points for the encoder resolution and native resolution sound reasonable in theory but don't prove in reality. If you say the visual clarity of the image with a pre-set 1800*1920 resolution is the same for you as with a pre-set 3232*3328 resolution via OTT/ODT, I would question your eyesight. Small elements like MFD-text in the F-16 are still blurry with values below 3232*3328 for me - of course this is quite individual but I prefer very crisp readable text. In case of getting higher fps this could be seen as "wasted" performance but I can live perfectly fine with crisp text/cockpit readability and ASW 45 fps than blurry text and the possibility for 90 fps. I think this also depends on the things you do in DCS. If I would fly in WW2 warplanes and do visual dogfighting all the time I would prefer a lower resolution and target 90 fps at the cost of a less crisp cockpit readability. But I normally fly the F-16 in high altitude with BVR-engagements so instruments and readability are a high focus for me. Also flying the Apache won't get you anything near 90fps with target MFPD and PNVS on - so here I also prefer a stable 45 fps ASW and perfect readability for the MFDs. Bandwith should also not be a problem - start the performance check with your cable inside the Oculus Home App - you should get around 2.0 Gbit or higher. If you set the encode bandwith to 960 Mbit as I do, you only use 0,96 Gbit of the available 2.0+ Gbit bandwith that is possible with the link cable. So there is more than enough performance headroom left that is still not used. Also the GPU needs to deal with the encoding and this can vary of course for everyone. While having had a RTX3090 I truly got frame-/sound-drops when I would set more than 500 Mbit as encoder bandwith, with the RTX4090 not a problem anymore. 960Mbit encoder bitrate is possible without any drops. So this setting depends on the user hardware of course. I don't think the bandwith changes with the fps / Hz setting (72/80/90). The encoder setting sets the overall bandwith and thats it. So maybe it is possible that there are more artefacts with 90 Hz than with 72 Hz because if the encoder bandwith is still the same, the image quality should be overall better with lower Hz-settings. I did not test this at all because I simply get headaches/nauseating with 72 or 80 Hz. So another personal matter for everyone ;D

This would normally happen when ASW is on - the motion vectoring for the image calculation is not working well with clear blue colors. Happens also in DCS with deep blue sky and waters on Quest 2 / Pro - can confirm. Only solution would be to disable ASW or use 45 fps fixed instead with Oculus Tray Tool. Maybe Meta will fix the ASW algorithm, maybe not. We will see. It has been a problem in some circumstances with Oculus Rift S since 2019 - so nothing new here.

Since OpenXR the DCS VR Supersampling Value is something like a multiplier. Prior to OpenXR with the Oculus Runtime, the DCS VR value would be completeley overwritten with OTT - that is no longer the case. So: set 1.5x in the Oculus Home Graphics Preferences (this is your baseline resolution) and set 1.0 supersampling inside DCS. Finetune with OTT from 1.0 and upwards to your desired resolution. I can not recommend lower settings for the encoding resolution. This will have a degrading visual impact on the overall clarity because the encoded image is smaller on lower settings. 3936*2080 pixels encoder resolution: this is combined width + height - so it is 1968*2080 per eye. ODT just has some more visual hud options (Oculus Link Status for example) that OTT does not have. But in general OTT just overwrites the ODT-settings. But ODT has also some limitations: for example it is not possible to write more than 500 MBit for the encode bitrate inside of ODT. With OTT you can go up to 960 MBit and this will get accepted by Oculus. Some people say they don't see a difference between the recommended default 300 Mbit and 500 Mbit. I highly disagree. I can clearly see more blockage and compression artefacts especially with more muddy colors like green and dark grey. We have those colors alot in DCS. So especially on the green grass or grey airfield textures you can see it clearly. I can also still see differences between 500 MBit and 960 Mbit, but much more distinct with darker and muddier colors. This can get subjective from human to human because we all see different and some people are not that prone to compression artefacts.

I think you are mixing some things up here. The encode resolution describes the capturing resolution the data stream gets before encoding and sending it to the headset via cable. The higher the encoder resolution the better the overall image at the end when displayed on the headset lenses. The Quest Pro does not use uncompressed data like with Display-Port (sadly) and so the video signal needs to be compressed as a data stream. You could compare it to a Youtube video that is 1080p or 4K resolution. Of course the 4K YT-Video looks always better even on a device, that has a resolution less than 4K. So for the encoding resolution you should always aim for the maximum in resolution and bitrate to have the best possible output on your lenses after decompressing. The second thing is the Pixel density, this describes the overall image in pixels. This depends on your baseline set in the Oculus Home Settings. You can check out the currently set real pixel density with OTT and the visual HUD for Pixel Density: The Pixel Density HUD only works when you have a VR application running (does not work on the Oculus Rift Home Center). If you would like to check the current pixel resolution or Density ("App Res") and encoder resolution ("Enc Res"), you have to use the OculusDebugTool.exe of Oculus (C:\Program Files\Oculus\Support\oculus-diagnostics) and use the "Performance" HUD with Mode "Oculus Link". I know in the Oculus Home App with 1.5x the Render resolution says 5408*2736. But if you check out the pixel density with the diagnostics tools (having 1.0 with OTT), you see the actual pixel rendering is higher than that. I think Oculus made a mistake here and just used the settings you set with a Quest 2 but the settings internallly have a higher setting on Quest Pro. This translates to 5.632*2896 (or 2816*2896 per eye - I always use the per Eye resolution in my list because this is better to understand than a combined resolution for width+height which Oculus uses). I hope this clears something up. I know this is very technical but that is the way of VR ;D So in short: you have a VR picture that gets video compressed to 3936*2080 pixels (this is combined width + height - so 1968*2080 per eye) and inside the headset this compressed signal gets supersampled to the desired final resolution you set with Oculus Home App (Baseline) and OTT as a multiplier. I do not know how exactly this gets managed in the software and headset itself but you still get better image quality the higher the final Pixel count is. Believe me I tested all possible solutions (higher / lower encode resolution & higher / lower pixel resolution) and these are my best results after testing hours of settings.

Thats true. The ASW algorithm has some problems with clear blue colors (solid blue sky, calm sea) and results in wrong motion vectors and distortion under certain circumstances it seems. Happens to me too.

In my testing (have had the 3080Ti with 12 GB in the past and struggled alot with the AH-64 in case of VRAM usage) the most important factor for using less VRAM in DCS was: Textures to Medium Terrain Textures to Low There are also some user files for reduced cockpit-textures that could save some more VRAM, for example for the AH-64 this helped reduce the VRAM-usage alot: https://www.digitalcombatsimulator.com/en/files/3321192/ Cheers!

Foveated Rendering only works as "fixed" as a fallback in DCS (so no real eye tracking like in MSFS) - so you define the overall mask. That is all for the moment. I really hope OpenXR can support DCS with eye tracking in the future, but the developers said it would be a heavy development - so unlikely. You can still save some GPU-headroom with the fixed foveated rendering - works better than the pseudo DCS HMD Mask. If you are willing to compromise some edge-clarity you can save some more headroom. But the results in MSFS with DFR are really nice, you can save 20 - 25 % GPU-Load when correctly configured. Really impressive. This feature combined with Multi-Threading and possibly DLSS would be really awesome for many VR-users. Well you can always wait, nothing wrong with that ;D I would say, if you are more price sensitive just wait for the Quest 3. Otherwise the Quest Pro is a nice deal right now if you want to spend that money.