KST

Thank you to all for your replies! Agree that there is a complex set of variables at play, however ultimately it does boil down to each vendor/developer in the VR pipeline must understand (through design, development and testing) what impacts what in terms of load on systems and resulting throughput/performance. While individual users can invest the time to learn, tinker, retest and change again - it is putting a big onus on users who may not be super tech savvy/time poor and ultimately detracts from the experience within DCS. (BTW, I think Eagle Dynamics is doing a fantastic job with DCS so I have no beef with them.) I'll leave this post here and happy to pick up again if there is interest. Happy flying!

Hi fellow DCS VR users! As a regular casual DCS user using VR (~4 hours/week for last 3 years, 8 months in VR), I've found it a steep learning curve to try to sort through all of the settings in the VR pipeline to get a reasonable visual/framerate outcome in VR - I now have a pretty good configuration going however tweaking settings as I go takes away from actual flying time... While there are some great videos/Discord discussions/posts here, there is a lot of "this works for me" and "different systems behave differently" (which are both true statements and personal preferences apply). I was keen to float the concept of a DCS VR Tuning Guide - it would not be 100% accurate, nor right in all cases but would hopefully help demystify the process for new and experience users alike. The Concept Similar to skill trees in RP games, there are two buckets of units - GPU and CPU Rather than trying to profile all systems to come up with a bucket limit, users set their own limit based on how their system behaves which overcomes different CPU types, RAM levels etc. (over time common bucket sizes could be shared) Each configuration setting is given a Priority - 1 for those that have the most impact on performance/outcome; 2 for medium impact; and 3 for visual 'eye candy'. Users can then focus on Priority 1 settings first, then worry about Priority 2 etc. Each configuration setting has a pre-determined points for GPU and CPU (set as per section below) representing their impact on GPU and CPU capacity Users chose their preference for each setting (Selected), with each setting adding points into the GPU and CPU buckets until they are full - once full, the user can test the system, if it is not working well then repeat the process lowering the one of the bucket limits How could this be created? The "secret sauce" here will be the points for each setting across GPU and CPU (in purple/yellow above) - these would be set by smarter folk than me with deep technical knowledge and shared for use in read-only format. @Wags / @BIGNEWY - I would expect the ED Devs/QA'ers would have intrinsic knowledge around the impacts of each setting. Is this something that ED would support their team to contribute to? Are there internal documentation that could be leveraged? Others - are you a DCS VR technical expert that would be happy to contribute? Do you know of one who may be interested? Rounding out the proof of concept shown above will require documentation of all of the relevant the settings at each layer (Windows, NVIDIA, OpenXR etc.) - I'm OK to populate sections covering NVIDIA/OpenXR/PiMAX settings per my rig - others could step up for other configurations. Focus in the first instance would be solely on Open Beta running in Multi-Threading mode (assuming that would be the most common VR setup?) and it would only be updated for significant releases. It is would be very easy to get caught up on the raft of reasons why this wouldn't 100% accurate however could be a useful proxy to simplify things and be a great support to users. Hopefully I've explained this simply... The million dollar question Are there experts out there willing to contribute?