edmuss

No I meant running 3160 resolution and FSR 68% (I think it's about 68 to achieve the 2160 ish render target) vs FSR 150%. Neither are going to be shimmer free but I've felt that it's lessened by using 150 vs 68.

You've not mentioned which headset you're using but assuming a G2... With the 3070 you're going to need to wind it back a little ideally, leave the render scale as default and use the in-game openxr toolkit menu to override it (you get more granular control of the resolution this way and per app settings). Try running it around 2800-2900 wide to start with (G2@100% is 3160 wide), you should get back a few frames for minimal image clarity loss.

Indeed the shimmer is still present (I think it's unavoidable in DCS currently when upscaling) but is there equal shimmer /performance gain when scaling above the 100% rather than below to achieve the same pixel density? Logically if you're driving the same number of pixels either way then the output should be the same, but then what DCS does isn't always logical I do seem to have seen an improvement in the shimmer by using the upper ratios though, again it could just be placebo?

Using the upscaler shouldn't increase clarity but it will improve performance. With the G2@3160 wide and FSR 150% with no sharpening I can still read all of the dials in the A10 without having to lean forward, it's just a little crisper without the upscaling. It might be purely placebo on my behalf (the difference between image quality with negative/postive upscaling ratio) so try it out yourself. It's quite possible that the code has been modified/improved since I started this thread

Edited the first post regarding running FSR >100% with positive results and better perceived image quality than <100%.

Perhaps something had gone a bit squiffy with your update, have you since tried the latest OB since?

Inversely mines running like a dream on latest OB. I've also discovered that running FSR>100 gives a better image stability than <100. Apparently upscaling in openxr toolkit doesn't behave the same as vrperfkit, above 100% doesn't act as cheap supersampling at performance cost but infact just changes the render target method I think; I've not gotten my head around exactly what the differences are yet. Foothold caucasus, G2 at 100% (3160 wide), FSR 150%, 60hz and I'm reliably sitting at 12-13ms frametimes which is nice

I think in theory, once it's been run with the switcher installed it might then relink back to it? It might be a question to pose on discord

Have you fully cleaned and tuned your system? Use thuds guide for reference, your problems likely aren't down to your hardware unless you're doing silly things like running 400% resolution Firstly, identify what's causing the poor performance, then you can look at solutions.

Indeed, it's great to see that ED appear to be facilitating integration of it in the background

For reference it appears that since the latest open beta, the d3dcompiler file is now removed from the DCS/bin folder which means no more having to delete it

There's no need to have the openxr tools or open composite running in the background, you only need WMRP; I would recommend having WMRP running before starting up DCS. I would do a full repair and slow clean of DCS, change DCS back to steamvr in the open composite switcher and then back to openxr. Delete the d3dcompiler if need be. Where is your DCS installed and where have you saved the open composite switcher app?

The upscaling in openxr toolkit is comparable in performance with regard to the upscaling applied by vrperfkit, however the additional benefits across the board are so much more that it's not comparing apples for apples

This is not the case, there is no need to copy anything to the bin folder if you've implemented the open composite switcher correctly.

Should work fine, it happens that it needs to be set to a negative number though not positive so try altering the setting in the opposite direction that you think you should! It helps a bit particularly with stabilising helmet mounted sights but I understand that it can cause increased artifacting if motion reprojection is enabled.

I would hazard a guess that for DCS you should be using the buttkicker purely as an output transducer and use SSFA + Andre's sound module to handle the telemetry side of things. It will need to be driven by it's own dedicated sound card (unless it has a USB/BT one built into iit. I use my onboard realtek SC purely for the transducer, in VR I use the G2 audio (driven off it's own built in USB SC) and in pancake I use BT earbuds so the realtek is otherwise unused. I bought an old 90's aura interactor vest off eBay for 17 quid. Basically it's a transducer in a crappy plastic wearable vest with a separate amp. Stripped the transducer out and bolted it to the back of my chair, paid for Andre's sound module and hey presto a dirt cheap seat shaker

Assuming it's a pcie USB card it's just a case of put it into an appropriate slot and connecting the power supply to it. It will effectively act the same as the onboard USB ports but with a direct power source.

No reason why it couldn't be done although the throw of the deltasim stick is far higher than the stick nipple so you can easily achieve far more accuracy straight off

Leave HAGS disabled, it doesn't help at all in VR but does cause instability. Check that the cable is fully seated into the headset, there is a dot on the moulding that should intersect with the housing, if it's out at all then there will be bad connections which could be causing the drops. It can be pretty stiff to get in but it will go. My personal choice is to route the cable inside and below the strap frame, that way when the hinge is flexed it doesn't put a harsh kink on the cable just before the plug. I believe that this is a weak spot/failure point of the cable in use, the HP setup guides instruct to run it over and outside the frame but then it get's kinked to a much tighter radius.

Check to see if HAGS is enabled (start>settings>system>display>graphics settings), it caused regular blue screen crashes with my G2 under steamvr. If that solves the issue, then go and read the first post of the openxr thread, it's a must for the G2

Some work (albeit minor) appears to have been done on leap support! DCS now remembers the settings in the options (leap enabled/point options) but doesn't actually apply them; also there is now no need to select the pointers options twice, that functionality works as intended now I don't know if it's the leap implementation within DCS or the intialisation of the sensor that causes it to not be enabled but once in DCS if I replug the sensor and then re-enable in the options the hands work as expected.

When WMRP opens a VR app the screen breaks into hundreds of triangles that then disperse, it's just a generic loading animation. With open composite it does it twice concurrently before DCS loads. You're still using steamvr for DCS, essentially open composite isn't hooking into the openVR runtimes so it's still starting up steamvr when requested. With the runtime switcher running, set open compostie as the default runtime and that should prompt it to hook into openVR files. When you have run DCS and it's hooked in once you can hit the configure button and it will bring up a list of VR apps that have been hooked into and you can set a specific runtime for each one as needed. Delete the d3dcompiler from the DCS/bin folder (or cut it out to a backup location) and open composite should then open up as I described. If you still get the -2 error then try deleting the compiler again, DCS seems to be able to ressurect it occasionally.

For me, turn on headset and let it warm up (so it doesn't condensate, I never unplug it though), fire up WMRP till the home screen comes up, start DCS. That's it. Steamvr is not set to auto start when WMRP is started, I use the infinite expanse environment in WMRP rather than the cliff house (to save the half a gig of VRAM). DCS is running via open composite set using the global switcher. Double click the desktop icon and the WMR home screen with shatter into triangles, then drop back to the home after a second or two and then reshatter. DCS will then start immediately after then second shatter. It works every time without fail with no hoops to jump through

I'm not entirely sure, in theory it should do but can't say for sure. To the best of my knowledge open composite only needs to know the locations of the executables to be able to hook into them; steam hides stuff away in the library but the executable is still there. I know that people who have had issues trying to get it to work with steam have switched to standalone and had no difficulties.

I wouldn't say specifically red but I've found it tracks just fine. I use red because it causes less light pollution and it's easier on the eyes (assuming I'm not in the headset) than blue/green. edit: note that my rig is in a super enclosed area so there's a good amount of edges/faces close to the headset which might make the dim red light more acceptable.