Flextremes

Really appreciate everyone's comments here. I share most concerns mentioned here about the Crystal and I do agree, the Quest Pro is an impressively good headset (in all aspects). However, I am looking forward to actual Pimax Crystal owners experiences who upgraded from the Quest Pro.

Happy Quest Pro owner here, I am delighted with the visual crispness the Quest Pro can run DCS using 4xMSAA and significant oversampling that is possible with Dynamic Foveated rendering using the Pro's eye tracking. Apart from a few niggles, I do not have anything to complain. Did not expect this, but my gamble to try the Pro until the Crystal became available was way more successful than expected. Now the Crystal is available, I have doubts if I should order one. So my million-dollar question is: are the Quest Pro owners here that are happy with their move to the Crystal. Sure, if you are coming from the G2, the Crystal seems an easy recommendation. But coming from a finely tuned, smooth as butter, crispy crisp Quest Pro experience in DCS, how does the Crystal compare in practice?

This was a known complaint with the Crystal Beta, clarity was lacking for objects and scenery at a distance. New glasses should have fixed this supposed 'focus' problem. I wonder if this is the same (residual) issue you guys are experiencing. On my Quest Pro (and Reverb G2) clarity is equal for all distances. I have the Crystal on order, this makes me apprehensive.

hey slughead, I have never noticed (yet) what you are describing? (Apart from typical ghosting when objects move fast, but way better than MR in WMR btw. ) Mayby because I run at render res 3905 with 950 bitrate with PC-link via USB. i will share all my settings when I have the time. (My system is a 5800x3D/4090) i do experience other minor issues I have not mentioned yet: sounds is mediocre in comparison to the G2 the software is not always stable. But once it is running, it is fine. Sometimes a full reboot is nessacary , especially when changing OTT settings. G2 was basically flawless in that respect, almost never needed a reboot.

Just want to report on my Quest Pro experience, coming from the Reverb G2... I really thought the G2 was pretty great, especially with a custom 3D-printed face mask, to bring my eyes much closer, dramatically improving the FOV and sweetspot. After color calibration, the G2 was a great high-res headset IMHO. But, because so many preferred the Quest Pro in this thread, I gave it a try. I took the plunge with a 850 euro secondhand version in pristine shape. After lots of tweaking: 200% improvement over the G2. First impression was not that great, but this was just a matter of tuning the PC-link settings with OTT. But the Quest Pro REALLY made a slam-dunk after I enabled 4xMSAA: because of 72hz I could afford to use the extra head room for 4x instead of 2xMSAA. Holy freak: even better-perceived resolution than the G2, even in the center of the image! 4xMSAA makes all vertical objects (like lamp posts, energy grid towers, cranes, etc..) much better defined and less shimmering. Powerlines are now far better visible than on the G2. I think the low panel resolution of the Pro is misleading many. In comparison to the G2 or Quest2, all panel the resolution is available per eye because the Pro uses separate panels per eye. Because of this, the Pro's resolution is actually 30% higher than the Quest 2 for example. So now I can only repeat what other have said before me, the PRO has massive benefits over the G2: Much better colors, Higher brightness, blacker blacks, much better FOV, and also for folks with wider IPD. Better depth perception (binocular overlap) very similar resolution to the G2 but with almost perfect edge to edge clarity, Massive sweetspot, More comfortable, just turn around the cup at the back of the head strap. Optionally and easily add custom headstrap to relieve weight. Less warm, heat does not build up because of open design More render headroom because of 72hz, Ability to use 4xMSAA: really helps with shimmer and much better rendering of vertical objects. Oculus ASW works clearly better than Motion Reprojection in WMR The future potential to use eye tracking for dynamic foveated rendering The possibility to use hand tracking (not tested yet) And the added benefit to use the PRO wirelessly for other VR games with perfect controller tracking... I pre-ordered the Pimax Crystal, but I am now not that eager for that headset anymore. The PRO, for now, is absolutely my favorite DCS headset.

Appreciate your feedback, but I do not completely understand your point. Isnt Fraps is seriously outdated, only provides fps statistics (and not frame times which is crucial to understand VR performance, reported by openxr)? Is it not better to recommend a more up-to-date generic/3rdp-party performance analysis tools like Nvidia Frameview? More importantly, Fraps does not provide a standardized way to measure performance metrics. You need to manually start and stop fraps which makes this method everything but exact. How can you compare your results with that of others? Not sure I follow your comment on in-game benchmarks: so many modern games and AAA titles (from GTA5 to Cyberpunk 2077) have in-game benchmarking option, it is extremely common still nowadays.

This first version of the DCS Benchmark Tool is a very basic but functional tool to Benchmark OpenXR VR tracks in a consistent and precise way. This tool starts and stops statistics logging automatically when you replay a track. Constistent logging is crucial to evaluate small changes and makes comparisons between different systems possible It is possible to capture detailed frame times and fps with Nvidia Frameview. Enable Frameview in the DCS_Benchmark_settings.ini that comes with the tool. A few notes: There are a million ways to improve this benchmark tool. This is truly the first version. I am anything but a professional coder, please improve and share updates with the community. For the next versions I would like to add automatic calculation of the 'Average' and '5% Low' of the FPS and all 3 Frame Times (app CPU, rdr CPU & app GPU) available in OpenXR. This version now supports OpenXR and Nvidia Frameview (Enable in the DCS_Benchmark_settings.ini) Other tools are supported if you can set a the start and stop command in the DCS_Benchmark_settings.ini You can use any track, just set the record duration in DCS_Benchmark_settings.ini. Enjoy... Suggestions for replay tracks for VR benchmarking are more than welcome! Download "DCS Benchmark Tool.exe" from this ZIP (includes the AutoHotKey V1 script) https://drive.google.com/file/d/1zOOTsgHpzubCVU-aLPYJ20pmU56T_lVX/view?usp=sharing OR copy the AutoHotkey V1 Script below into notepad and name the file "DCS Benchmark Tool.ahk" and download runtime from www.AutoHotKey.com EnvGet, Appdata, Appdata EnvGet, LocalAppdata, LocalAppdata EnvGet, Windir, Windir EnvGet, CommonProgramFiles, CommonProgramFiles EnvGet, CommonProgramW6432, CommonProgramW6432 EnvGet, HOMEDRIVE, HOMEDRIVE EnvGet, HOMEPATH, HOMEPATH EnvGet, Path, Path EnvGet, SystemRoot, SystemRoot EnvGet, USERPROFILE, USERPROFILE EnvGet, TEMP, TEMP EnvGet, TMP, TMP ; Set Default Settings Inifile := A_ScriptDir "\DCS_Benchmark_settings.ini" defaultFrameView := "No" defaultSleepSeconds := 30 defaultStartCommands := """%programfiles%\OpenXR-Toolkit\companion.exe"" -record-stats toggle" defaultStopCommands := """%programfiles%\OpenXR-Toolkit\companion.exe"" -record-stats toggle" defaultLogFolder := """%localappdata%\OpenXR-Toolkit\stats""" ; Create settings.ini with default settings file if not exist if !FileExist(IniFile) { IniWrite, %defaultSleepSeconds%, %IniFile%, Settings, SleepSeconds IniWrite, %defaultFrameView%, %IniFile%, Settings, FrameView IniWrite, %defaultStartCommands%, %IniFile%, Commands, StartCommands IniWrite, %defaultStopCommands%, %IniFile%, Commands, StopCommands IniWrite, %defaultLogFolder%, %IniFile%, Folders, LogFolder } ; Read Settings from INI file IniRead, SleepSeconds, %IniFile%, Settings, SleepSeconds IniRead, FrameView, %IniFile%, Settings, FrameView IniRead, StartCommands, %IniFile%, Commands, StartCommands IniRead, StopCommands, %IniFile%, Commands, StopCommands IniRead, LogFolder, %IniFile%, Folders, LogFolder Transform, LogFolder, Deref, %LogFolder% Transform, StartCommands, Deref, %StartCommands% Transform, StopCommands, Deref, %StopCommands% ; Check if any setting is empty and prompt user to update INI file if (SleepSeconds = "" || StartCommands = "" || StopCommands = "" || LogFolder = "") { MsgBox, 36, Update INI file, Some settings in the settings.ini file are empty. Do you want to update the INI file with default settings? IfMsgBox, Yes { IniWrite, %defaultSleepSeconds%, %IniFile%, Settings, SleepSeconds IniWrite, %defaultFrameView%, %IniFile%, Settings, FrameView IniWrite, %defaultStartCommands%, %IniFile%, Commands, StartCommands IniWrite, %defaultStopCommands%, %IniFile%, Commands, StopCommands IniWrite, %defaultLogFolder%, %IniFile%, Folders, LogFolder MsgBox, Finished, The settings.ini file has been updated with default settings. Please restart the script. ExitApp } else { MsgBox, Error, Please update the settings.ini file manually and ensure all settings are provided. ExitApp } } ; MsgBox to inform users msgBoxShown := 0 MsgBox, 1 --- Universal Benchmark Script for DCS ---`n`n1 Place your VR headset perfectly horizontal on a table.`n`n2 Select the DCS desktop mirror.`n`n3 Load the track in DCS you want to replay.`n`n4 Do NOT select FLY at the briefing screen YET!!!`n`n5 Select numpad 5 to center the view.`n`n6 Open the settings.ini file and configure the performance tool and log folder settings as needed.`n`n7 After you close this messagebox...`n`n>> ONLY Use the Pause Key to start replay in the briefing screen`n`n>> OpenXR stats recording will autostart and stop after %SleepSeconds% Seconds.`n`nSettings used during replay:`n- Use Frameview: %Frameview%`n- SleepSeconds: %SleepSeconds%`n- StartCommands: %StartCommands%`n- StopCommands: %StopCommands%`n- LogFolder: %LogFolder% If (frameview = "Yes") { MsgBox, You enabled Nvidia Frameview.`n`nSet %SleepSeconds% for *Capture duration* in the Frameview confugration window`n`nSet [Scroll Lock] for *Benchmark Hotkey* in the Frameview confugration window` `n`nIn the briefing screen Press [Pause and Scroll Lock] simultaniously } msgBoxShown := 1 ; Check if the DCS window exists if !WinExist("ahk_exe DCS.exe") { MsgBox, 48, Error, DCS window not found. Please ensure DCS is running before starting the script. ExitApp } If (frameview = Yes) { if !WinExist("ahk_exe Frameview.exe") { MsgBox, 48, Error, Frame not found. Please ensure Nvidia Frameview is running before starting the script. ExitApp } } if !WinExist("ahk_exe DCS.exe") { MsgBox, 48, Error, DCS window not found. Please ensure DCS is running before starting the script. ExitApp } ; Activate the DCS window and show a tooltip WinActivate, ahk_exe DCS.exe If (FrameView = "No") { Tooltip, 1------- Load your track in Replay --------`n`n2------- Do NOT select Fly with mouse -------`n`n 3------ Press the [Pause] Key to Start ------- } ; Track replay If (FrameView = "Yes") { Tooltip, 1------- Load your track in Replay --------`n`n2-------- Do NOT select Fly with mouse --------`n`n 3- Press [Pause and Scroll Lock] simultaniously to Start -- } ~Pause:: if (msgBoxShown = 1) { Tooltip WinActivate, ahk_exe DCS.exe Run, %StartCommands% ;; If (FrameView = Yes) { ; Send {ScrollLock} ; Sendinput, {ScrollLock} ; } remainingSeconds := SleepSeconds while (remainingSeconds > 0) { ToolTip, % "Countdown: " remainingSeconds " seconds remaining" Sleep, 1000 remainingSeconds-- } ToolTip Run, %StopCommands% msgbox, Finished! Open %LogFolder% for the stats CSV file Run, Explorer "%LogFolder%" exitapp Return }

With the help of ChatGPT 4 for inspiration and Mr OpenXR toolkit himself I made this janky but functional 'proof-of-concept' to consistently capture openXR performance data during track replay. This is an AutoHotkey V1 script. Download from https://www.autohotkey.com/. Open notepad and save as, select "all file types" and name the file "BenchmarkDCS.ahk" ; manually Start DCS with the track msgBoxShown := 0 MsgBox, 1 --- DO NOT CLICK [OK] BEFORE COMPLETING THESE ACTIONS --- `n1 Place your VR headset perfectly horizontal on a table. `n2 Select the DCS desktop mirror.`n3 Load the track in DCS you want to replay. `n4 Do NOT select FLY at the briefing screen YET! `n4 Select numpad 5 to center the view. `n5 Only now you can close this messagebox `n6 ALT-TAB to DCS briefing screen and use the Pause Key to start replay. `n7 OpenXR stats recording will autostart and stop after 10 seconds. msgBoxShown := 1 ~Pause:: if (msgBoxShown = 1) { Run, `"C:\Program Files\OpenXR-Toolkit\companion.exe`" -record-stats toggle Sleep 10000 Run, `"C:\Program Files\OpenXR-Toolkit\companion.exe`" -record-stats toggle msgbox, Finished! Open %localappdata%\OpenXR-Toolkit\stats for the stats CSV file Run, `"%localappdata%\OpenXR-Toolkit\stats`" exitapp } return Please note: you need to specify the time in ms at the SLEEP function for how long you want to record data. 10000 is 10 seconds, which is used in this example. To run a benchmark: Just load DCS in VR put your headset perfectly horizontal on your desk goto the DCS desktop mirror select numpad 5 select your track in replay Do NOT select FLY yet... Right click BenchmarkDCS.ahk script below and start with AutoHotkey launcher When ready: press OK in the messagebox. ALT-TAB to the briefing screen in the DCS Desktop Mirror Press the PAUSE Key to start the replay (do NOT mouse click on 'Fly', press the Pause key instead) After you close the messagebox the script will wait for a Pause Key Press. When the Pause is pressed the replay is started, and OpenXR performance statistics are automatically started at the exact same time by this script After 10 seconds (this is configurable at the Sleep function in the script) you can review the CSV file in %localappdata%\OpenXR-Toolkit\stats. Have fun benchmarking :))

Check, thanks! It worked. I made a proof of concept for DCS benchmarking.

Thanks. Does 'toggle' mean on/off? Ah I found it: NO/YES

@mbucchia Is there way to start en stop frame times and fps logging in OpenXR via command line? It would really help us out to simplify benchmarking replay tracks. See our discussion here:

Haha, ChatGPT always goes for python first. Creating a CMD script is so much simpler. So I asked my AI friend and he delivered. @echo off set "dcs_executable=Path\to\your\DCS.exe" set "track_file=Path\to\your\DCS\Tracks\your_track_file.trk" set "openxr_dev_tools=Path\to\OpenXRDeveloperToolsCLI.exe" set /a capture_duration=120 start "" "%openxr_dev_tools%" -CapturePerformanceData start "" "%dcs_executable%" --track "%track_file%" timeout /t %capture_duration% start "" "%openxr_dev_tools%" -StopPerformanceDataCapture Replace the placeholders "Path\to\your\DCS.exe", "Path\to\your\DCS\Tracks\your_track_file.trk", and "Path\to\OpenXRDeveloperToolsCLI.exe" with the correct paths to your DCS executable, the track file you want to replay, and the OpenXR Developer Tools CLI executable, respectively. Adjust the capture_duration variable to match the duration of your track replay in seconds. Run the batch file: To start DCS, replay the track, and automatically capture OpenXR performance, simply run the "DCS_performance_capture.bat" script. You can do this by double-clicking the script file ------------------- Before you run the batch file: the trick is to lay your head-set horizontal and stable on the table and press Numpad 5 first to ensure replay consistency. Lemme see if this works... EDIT: LOL: OpenXRDeveloperToolsCLI.exe is a hallucination of ChatGPT 4, it does not exist. This seemed indeed too easy EDIT2: the --Track commandline option for dcs.exe is also pure fantasy by Chat GPT 4 it seems EDIT3: the --track does seem to work, but the track is only automatically loaded, not started, you need to choose "Fly" at the briefing screen. There are too many caveats: logging is started when DCS.exe starts (off course): it should only start when the replay starts. Nice try, but we need some help from Dcs devs here. EDIT4: I found a solution:

Agreed, in VR your headset movements will override the view in the replay. Would be nice to disable head-set spacial inputs during track replay. If not possible, we could at least just fix the view in the track: put your headset on the table, press numpad 5, then start the replay track. This way tracks replay is consistent, which is key.

I gotta agree, if Replay is fundamentally broken, that need to be fixed first. As an intermediate solution: keep track and mission relatively static? BTW I asked ChatGPT 4 for help... How can I automatically start and stop capturing OpenXR performance when I replay a track in DCS? To automatically start and stop capturing OpenXR performance when you replay a track in DCS, you can use a combination of scripting and OpenXR Developer Tools. Here's a step-by-step guide to achieving this: Install Python: To run a custom script, you'll need Python installed on your computer. If you don't have Python, download and install it from the official website: https://www.python.org/downloads/ Install OpenXR Developer Tools: If you haven't already, download and install the OpenXR Developer Tools for Windows Mixed Reality from the Microsoft Store. Create a Python script: Create a new text file and save it as "DCS_performance_capture.py" (or any name of your choice with the ".py" extension). Open the file in a text editor and add the following code: import os import time import subprocess # Configuration dcs_executable = "Path\\to\\your\\DCS.exe" track_file = "Path\\to\\your\\DCS\\Tracks\\your_track_file.trk" openxr_dev_tools = "Path\\to\\OpenXRDeveloperToolsCLI.exe" capture_duration = 120 # Adjust this value to match the duration of your track replay in seconds # Start OpenXR Developer Tools performance capture subprocess.Popen([openxr_dev_tools, "-CapturePerformanceData"]) # Start DCS with the track subprocess.Popen([dcs_executable, "--track", track_file]) # Wait for the track to finish time.sleep(capture_duration) # Stop OpenXR Developer Tools performance capture subprocess.Popen([openxr_dev_tools, "-StopPerformanceDataCapture"]) Replace the placeholders "Path\to\your\DCS.exe", "Path\to\your\DCS\Tracks\your_track_file.trk", and "Path\to\OpenXRDeveloperToolsCLI.exe" with the correct paths to your DCS executable, the track file you want to replay, and the OpenXR Developer Tools CLI executable, respectively. Adjust the capture_duration variable to match the duration of your track replay in seconds. 4. Run the script: To start DCS, replay the track, and automatically capture OpenXR performance, simply run the "DCS_performance_capture.py" script. You can do this by double-clicking the script file or executing it from the command prompt: python DCS_performance_capture.py The script will start the OpenXR performance capture, launch DCS with the specified track, and stop the performance capture after the specified duration. Make sure to close any running instances of DCS before starting the script. ------------------------- If this works then "HAIL CHATGPT" PS: I have zero Python experience. EDIT: Close but no cigar; see below. EDIT2: HAIL CHATGPT!! sort of...

I'm sorry, but it does not make any sense what your saying. You are over-complicating something that is not. Example: fly one of the more complex missions on heavy duty maps (marianas) with the AH64. Fly and record the action for 2 minutes. You have a track. Share it with others. Done. Additionally, I am sure DCS members love to design missions for performance testing and share them. This already has been done many times before.

It does not have to be. If DCS allows any module for replay purposes only, the community can design tracks that are focussed on CPU or GPU or both. Guidance can be improved for sure: however there are already plenty of guides, but the world is continuously evolving and users have very different setups and even more different preferences. No guide will ever take away the need for performance testing. How do you know something right or wrong, and what the impact is of a configuration change?

That would be awesome. (BTW I designed the benchmarking software that AMD used in their Epyc CPU keynote last year) We could start simple, all ingredients are here: allow disabled modules in Replay; disable all inputs, automatically center view before start, and disable view changes/headset movements during track replay; and automatically start and stop frame time logging in OpenXR/SteamVR. We can use external (community or freeware) tooling for analysis. It is that straightforward.

I agree. I'm not sure you can. However, modules can be installed and deactivated when you do not have a license. All modules already support the temporary license regardless. ED should just allow disabled modules to be used during replay and disable all inputs and view changes: this is essential for consistent benchmarking anyhow. While it is dangerous to say something is easy to implement, this does not sound dramatically complicated. All ingredients are here: allow disabled modules in replay, disable all inputs and view changes/headset movements, and automatically start and stop frame time logging in OpenXR/SteamVR. It is that simple. We can use external/3rd party tooling for analysis.

While for pancake (2D) simmers in DCS performance tuning is also a critical topic, it is imperative to do so with VR. The stack to render DCS to your eye's retina is in VR so much more complicated than in 2D: we VR users are constantly tweaking and tuning. Frame-times spikes, jitter, fps swings, CPU bottlenecks, and GPU limits have a massive impact on our VR experience. Currently, performance analysis is so cumbersome, we are really missing a standardized, consistent, precise, and easy-to-use solution to measure and compare performance in VR. I believe we really need a simple, in-game, standardized benchmark solution to analyze (community build) replay tracks with fixed views for consistency. This allows us to easily compare fps statistics and frame-time data to tweak, tune and troubleshoot DCS the VR stack. Importantly, it would be essential to integrate performance statistics from the render stacks like OpenXR and SteamVR. ****EDIT**** I created a proof of concept below, you can use any track you like:

Excellent explanation!

What FPS counter are you using?

On the system TAB of open XR I have set an output resolution of 3700x3600. On the performance tab I set 80%: this results in a render resolution of 2950x2900 being upscaled to 3700x3600. This means that the GPU is doing all the rendering at 2950x2900, then FSR upscales with sharpening to 3700x3600. This is the image resolution actually received by my G2. You are doing nothing wrong: 80% rendered upscaling works great with FSR. Set sharpening at 100: it works really well. Leave pixel density a 1.0.

I am lazy, so I asked Chat GPT explain: Can you explain how both CPU frame time latency and GPU frame time latency affect fps Certainly! Both CPU and GPU frame time latency can affect frame rate in Virtual Reality (VR) applications. The CPU is responsible for managing the overall system resources and directing the flow of data between the VR application and the GPU. If the CPU is unable to keep up with the demands of the VR application, it may take longer for the data to be sent to the GPU for processing, resulting in higher CPU frame time latency. When CPU frame time latency is high, the GPU may have to wait for the CPU to finish processing before it can start rendering the next frame, causing the frame rate to drop. In other words, if the CPU is not able to feed enough data to the GPU in time, the GPU will have to wait, and the frame rate will suffer. Similarly, GPU frame time latency measures the time it takes for the GPU to render and display a frame. If the GPU is unable to keep up with the demands of the VR application, it may take longer to render each frame, resulting in higher GPU frame time latency. When GPU frame time latency is high, the CPU may have to wait for the GPU to finish rendering before it can send more data to be processed, again leading to a drop in frame rate. Overall, CPU and GPU frame time latency are closely linked to frame rate in VR applications. If either the CPU or GPU frame time latency is high, it can cause delays in the frame rendering process, leading to a lower frame rate and potentially causing motion sickness or breaking immersion. Therefore, it's important to ensure that both the CPU and GPU are capable of handling the demands of the VR application to achieve a smooth and responsive VR experience. What CPU frame time latency and GPU frame time latency do you need to render at 90fps? To render at a consistent 90fps frame rate in Virtual Reality (VR), the CPU frame time latency and GPU frame time latency should ideally be under 11 milliseconds (ms) each. This is because 90fps means each frame needs to be rendered within 11.11ms (1 second divided by 90 frames), and any delay beyond this threshold can cause lag, motion sickness, or break immersion. Therefore, both the CPU and GPU need to be capable of processing and rendering the VR application's data within the required time frame to maintain a smooth and responsive experience. It's worth noting that achieving this level of performance can depend on various factors such as the complexity of the VR application, the graphics settings used, the hardware specifications of the CPU and GPU, and other factors. However, as a general rule, maintaining low frame time latency for both the CPU and GPU is critical for achieving a consistent and high frame rate in VR.

Guys: you really need to report more detailed information. Like what hardware are you using and how are you running VR?

Let me start off by saying that this is a great conversation. It is very clear that many, like you, do not experience the significant improvement in fluidity so many are reporting. We need to figure out what is going on. I tested your track again until the end: I experienced zero stutters, perfectly smooth. The only reason I went 46 fps is that I have enabled all eye candy (that would destroy performance in ST, btw) and I am running at a very high resolution. Seems like there is a trend: folks on streamVR are generally not happy. It seems like this first version of MT DCS is optimized for native openXR. ED is aware of these stutter problems: they mention it specifically at release. I am hopeful they can fix this: because it seems for open XR native this does not seem a problem. I also suspect that SteamVR and Oculus have a considerably higher CPU overhead than native Open XR. (conversely: reprojection is no way near as good in openXR) Also, it is clear that DCS MT seems to prefer newer CPU's with higher core counts. MT can even render worse results on old CPUs with only a few cores. This makes sense because managing MT processes instead of ST does incur a sizable overhead for tracking and syncing all those threads. If you do not have enough cores, ST will the better option. Lastly, it is also clear that when somebody is GPU limited you should not expect higher FPS. But this is only half of the story: DCS always has been severely CPU bottlenecked: just check multiplayer, Supercarrier, high complexity missions, and even maps like the Marianas: CPU latency is all over the place. With MT these are fundamentally more fluid now. That is why I put so much emphasis on the Carrier example: Total CPU latency combined (app + rdr) in ST: 41.1ms, and in MT CPU combined is only 16.2 ms: this is x2.5 faster. Especially the 'app CPU' 22.5ms (ST) vs 4.0ms (MT) difference is stark: this is more than 5x faster. In VR this means that the chances of the CPU bottlenecking your VR experience is so much lower. I am a casual flyer since Flanker 2.0. (Yep I am that old). Many moons ago: only the DX11 update improved performance in DCS. But never in the history of DCS updates have we got this kind of performance improvement. But I do think we need to manage expectations: Always 90fps in VR without any drops in a simulation like DCS is close to impossible. DCS is such a complex program, simulating the constraints of reality like AI, war logic, physics, technology, weather, multiplayer, and graphics. DCS IMHO dwarfs MSFS in complexity: There is absolutely nothing (for consumers) that comes close. That is why I am so appreciative of MT in DCS.