edmuss

Nope, you just have it setup and running correctly for your system

Yup you should be able to happily run a G2 at decent resolution as long as you're happy to use reprojection. Note that currently WMR openxr reprojection (for the G2) currently does suffer from increased artifacting, however an upcoming runtime update should go someway to alleviate the issues

Being able to keep above refresh rate is an absolute game changer for DCS. It can be hard though, even 60fps needs hefty hardware and compromises to achieve it; 90fps more so. All being well the upcoming implementation of DLSS will enable the magic value of <11ms to be achieved for many. Regarding reprojection, it's going to get better soon for WMR openxr users all things being well. 45 vs 30 has always been practically impossible to differentiate for me during testing. However there is a slight clarity loss and the artifacting to deal with with reprojection in general.

Out of interest by some rough calculations: - 100% render resolution being approximately 3160x3090 per eye resulting in 9.76 million pixels per eye to render. 300% render resolution would be approximately 5470x5350 per eye resulting in 29.2 million pixels per eye to render. If you then apply 60% upscaling to that resulting resolution you end up with a render resolution of around 3283x3211 in addition to the upscaling overhead which would be around 0.75-1ms. Basically running 100% will always perform better than overriding 300% @60% upscale. If you want to still override massively and upscale 60% to get the image quality then try 275% instead of 300%, this would give a resultant render resolution of around 3145x3075 and should give very similar performance (possibly slightly worse) to 100% once the upscaling overhead is factored in

Shadows high to off gives me an additional 3-5ms, it's a massive boost, similarly clouds low to ultra is 3-4ms - I suspect that you might simply be CPU bound which is why you're not seeing big changes in GPU settings. The graphics options don't always make a huge difference and DCS doesn't scale well to lower hardware (never has done) but the difference between low and high with shadows specifically is pretty apparent. The MT update has unloaded some of the workload onto more cores, however if your cores simply aren't very fast (as yours aren't in terms of throughput compared to a modern CPU) then they can become overwhelmed. Think of a tank full of water, you drill 6 x 10mm holes in it to drain the water out (this is your CPU), now take an identical tank and drill 6 x 20mm holes in it to drain the water out (this is a modern CPU); the 8 holes will pass the water far, far quicker, reducing the bottleneck. edit: just run the hydraulic calculations through, a 20mm hole will flow about 3.8 times the amount of water that a 10mm hole will - obviously it's not directly related but that's what DCS is doing to your CPU. Trying to push too much data through too small a hole. I don't think the high render resolution of the G2 is because of low panel resolution of previous generations of headset, but it's blatently obvious that if you run it at 47% of the total pixel count to achieve the 2160 widre resolution then it gives a rather mushy image. The 100% setting of 3160 is driven by the headset drivers and WMR, HP themselves have set it like that. No one is actually forcing you to use openxr, you're free to use openbeta via openvr but I suspect that your performance is going to be just about the same as via openxr edit: Some cloud performance testing screenshots I took the other night. Reverb G2 @ 2400 resolution, mostly high across the board settings. Low clouds - 9ms = 111fps Ultra clouds - 15ms = 67fps The ultra clouds wasn't hugely consistent, sometimes it was 13ms, sometimes 15ms depending on which clouds I was looking at. However there is a huge gulf in performance between the two.

It does increase the clarity somewhat but there comes a point of diminishing returns. I've never run more than 100% on the G2 outside of testing because I don't have the horsepower

Incorrect, set openxr resolution to 100% and the render resolution will display on the second tab. It was confirmed by HP tech when the G2 came out that ~3160 was the default resolution. I don't know the reason why it's set up the way it is but that's how it works

No it won't, all of the benefits and more can be gained via openxr toolkit though

The CPU bound thing I think is a bug or misnomer, I'm now far less CPU bound than I was pre-MT update (ignoring what the graph says) in that I can now run much heavier AI missions without the CPU dragging the GPU through the dirt - getting appGPU frametimes good for 80fps but only getting 50. I get CPU bound render thread on the menu and it flickers between CPU bound main thread and render thread when in flight. The GPU is typically around 95-100% utilisation (depending on module) and is my bottleneck. The flat terrain shadows in their entirety were bugged for performance with the introduction of 2.8, these are now fixed with the latest MT update. With 2.8, prior to the release of BS3 there was an engine lighting update with the things like canopy glare and shadows being added, additionally the new clouds/shadow engine was introduced. The performance hit is the sum of a multitude of little tweaks, it's not openxr specific, simply DCS 2.8 itself

2.8 introduced a lot of additional lighting which caused a large performance hit, especially to the ka50. I too see the lower GPU frametimes whilst the textures are loading, typically I'll be at around 8-9ms which then jumps up to 12-14 in the ka50. I'm not upscaling by running more than 2160, full render resolution as defined by HP on the G2 is around 3160x3100 per eye, this accounts for lense distortion. I run 75% resolution with 2xMSAA, it gives less aliasing and better performance than 100% without MSAA but the image is not as crisp; I find that if I drop the resolution much more then the reaibility of the MFDs starts to suffer.

Unfortunately your GPU is in no way powerful enough to run a G2 at anything other than absolute minimum resolution and settings. For reference, at 100% resolution, the G2 requires around 19.5 million pixels to be rendered, in comparison a 4k monitor is only 8.29 million pixels; the HTC vive need 2.6 million pixels. I run the G2 at 75% resolution (give or take 2400x2400 per eye) and with the 3080ti I get great performance, in 1080p 2D I get 200+ fps with my normal VR settings. Unfortunately you simply do not have a big enough machine for the G2, even if you were to upgrade the GPU to a 3080 or above you would then be CPU bottlenecked pretty quickly (although MT is going some way to alleviate this). I would suggest the following to attempt to use the G2 with your hardware: - Reduce resolution to around 75% Enable FSR or NIS upscaling provided by openxr toolkit. Enable foveated rendering. Enable reprojection with an unlocked framerate (default setting - this will allow openxr to reproject down to 30hz without much hassle). Disable shadows. Textures you can probably run high with the 1080ti as it has good bandwidth. This should give you a resonable base on which you can tweak settings but it's not going to look great I'm afraid edit: oh and BS3 is a performance hog no matter the settings.

The problem is with your VR configuration somewhere. Reverb G2 here and I get between 9 and 16ms frametimes, map and module dependant. More information on your hardware, configuration and VR setup is needed

3060TI would be on the weaker side for DCS VR unfortunately, depending on headset resolution. You will likely have reasonable performance with a first gen WMR (lenovo explorer or similar) or a riftS but then the resolution is much lower and clarity not as good. Something like a Q2/G2 may be possible but you're going to be having to make so many compromises to get the framerate up enough. I ran the G2 on a 3070 on 2.7 last year, however 2.8 is graphically a fair amount harder on the GPU so the 50-60 fps I could get with the 3070 would likely be 40-50 now.

Turbo mode will only help to recover FPS on WMR when close to or below refresh rate appGPU (16.6ms). If you're below this frametime it will make no noticeable difference. Try locking the framerate to 61 rather than 60, certainly my reverb sits at 61fps when above refresh. Can't help on the the OBS stuff though.

Ah yeah, that's a ripe old age for a CPU You'll be blown away by a modern CPU!

Are you on the open beta MT preview? It makes this mission far easier on the CPU

I have a bunch of RC dampers (spent 10 years racing 1/10th scale electric back in the late 80s/early 90s) so could probably get a couple in there Gone off topic, apologies

I never thought about adding dampers to my H pattern when I designed it, I think the packaging might be a bit small to fit them in there now though! I hand machined all of the pedals with a jigsaw and pistol drill The turned parts I got done at work with by the tame CNC man, laser cut parts (toe brake components) by my mate, simply because it's easier than hand profiling stainless repeatably given the tools I have and kinking the braces for the main arms was done by my mate who has a fabrication shop. As I said, materials could be anything, make them from wood if you're so inclined

LIke I said, you're welcome to the models and drawings if it's of interest. I'm going to replace the two opposed gas struts that act as the main damper, gas struts only dampen motion on extension and the two that are on there have lost some of their capacity, I'll be replacing them with a single hydraulic damper (from a mini moto - 12 quid off ebay) which will give a better, more robust system.

This is the configuration of mine, you could reduce the width very easily. If you have access to a lathe and laser cutting then you could replicate pretty easily. Based on a linkage from the TPR and spring/cam mechanism of the crosswinds. Spring tension is adjustable to nill and the gas struts act as dampers to allow them to be used as anti-torque pedals for rotary wing use. Pedal throw is +/- 125mm from neutral so loads of control. I designed them around material that I had in stock, mostly 50x8mm aluminium bar stock and machined delrin for pivot bearings. The majority of components could be replicated as 3D printed though

If you force a reprojection rate and you don't have the horsepower to sustain the required frametime (18ms or so for 45hz) then it will disable the reprojection. Better to leave it unlocked so that it can drop to 30hz. Steamvr is unable to reproject at 30hz so openxr provides a massive advantage for lower level hardware. In my hundreds of hours of testing I've seen very little difference in artifact amount between 45hz and 30hz.

This isn't quite right, there is a GPU overhead associated with reprojection, typically about 3-4ms on my machine if I turn it on. To achieve 45fps reprojection you need to add your appGPU frametime to those overhead and the resulting total needs to be less than the 22ms needed to hold 45fps. Therefore assuming 4ms overhead you need your appGPU to be <18ms otherwise it will drop to the 1/3rd refresh rate bracket (30hz). edit: 18ms is 55fps so your 50fps likely isn't enough to consistently hold the 45hz reprojection. Running at 30hz isn't actually bad, you're still getting the same smooth performance but you might see more artifacts (this is very hard to quantify).

I designed my pendular rudders to fit a very confined space and could be reduced in width as needed; as I designed them, they are about the same width as the TRPs but I need the hanging arms to be on the outside of the pedals, so as to keep access for the driving pedals. Someone else has asked for a set of drawings/models for them so you can have a set if you want once I've updated them

This is an existing issue that came in with 2.8 and the BS2 cockpit retexture/lighting overhaul, the performance of the IT23 is about the same between the colourised and the greenscreen version Is BS3 still a developement module? Being based on the most mature of any of the DCS modules I would have expected it to be fair well sorted, that is of course not to say that it's not lacking optimisation. I'll have a play at creating an optimised KA50 and see if I can improve performance any.

I know you were referring to the texture size rather than resolution, at lower resolutions the hit is less (on the IT23) but it is always considerably more (~2ms@1024) than the TGP on the A10C (~0.5ms@1024). On 256 resolution the IT23 is still close to 1.5ms hit sometimes, it's also somewhat difficult to use! I'll have a read through thanks