edmuss

It's the cheap upgrade

Check your environment, the G2 needs quite a lot of clearly defined objects for it to track properly. It doesn't need that much light either but bright sunlight has been known to throw it off.

Bear in mind that the 3080 still has about 50% more bandwidth than the 4070ti, it's going to bog down with the amount of resolution and texture it has to push through currently. Analogous to 1000 cars travelling from point A to point B, put them on a 4 lane motorway that can do 70mph and they will get there quicker than on a single carriageway at 50mph.

100% this, the 4090 is being crippled by the CPU.

From the last generation yes, only the ti is slightly faster. From the current generation I'd only go for the 4090 if budget allowed as it gives a sizeable uplift, I don't know that the 4080 is any faster than a 3090 in VR.

This is correct, upscaling values above 100% reduce the render resolution by the inverse. So 75% upscaling would be render resolution x 0.75, 150% upscaling would be render resolution ÷1.50. Are you definitely running DCS with the force steamvr switch rather than the default oculus runtime?

I believe that there are going to be two upscaling options available in the future, DLSS and presumably FSR

For high res VR it's not ideal, it's memory bandwidth is a little over half that of a 3080ti and can't push enough data through fast enough. Stay with lower textures and resolution and you'll be ok. Rift S or index and you'll be ok, Q2 or above and I think you'll be suffering a bit. Even the 4080 is less bandwidth than the 3080ti although it is a faster card. I'm not sure what the direct comparisons are like for DCS VR though. edit: first review I find for the 4070ti states that is worthless for 4k due to memory bus, the G2 at default resolution is pushing almost 2.5 times the number of pixels than 4k!

Just terrain shadows is generally enough although with your 4090 you shouldn't have a significant issue. I can get 50-70fps with my 3080ti, medium cockpit and default terrain shadows.

It's a known issue and an upcoming release of toolkit should alleviate some of the wobbles

I have my huion tablet portrait, I'm still working out if I want it on left or right leg though - I'm right handed but the angle it sits at means it's more comfortable to write on reaching across. Have to remember to have the huion software running before firing up OKB otherwise the 90° rotation doesn't get translated through and all sorts of fun and games ensues

Quite likely as it throws the AI tensor cores at it, if you like it's a dedicated hardware reprojection solution Still doesn't work for VR though....

We already have frame generation and have done for years, it's called reprojection

You can tune the Jetseat separately to the transducer, set simultaneous output and then adjust the levels for each effect and device as you need

All this talk of kneeboards has enthused me to make a thigh mount for my tablet. Chopped a bit of 100mm thick minicell foam to make a saddle that sits on my thigh, the tablet is velcro'd onto it and I've drilled a 16mm home on one side to act as a stylus holder. With a bit of luck it will be stable enough without needing to be strapped. I shall endeavour to make more use of it

From what I remember you simply open the pdf on the desktop OKB app and it then appears on the virtual kneeboad, it works really well with a tablet as mentioned above, I also use an inspiroy h610p and it's really nice with the inking support so you can add notes with the stylus; additionally the physical buttons on the tablet allow you to switch tabs and pages. The kneeboard can be positioned to suit, made opaque and auto zooms when you look down at it. I could be wrong with the above, it's been a while since I used the kneeboard but I'm sure I've had it working like that

125% and 80% are pretty much identical, what you're seeing is placebo difference in performance between the two. The only way to upscale in openxr toolkit is to override the resolution first and then apply upscaling. Values both above and below 100% achieve the same thing, a reduction in the rendered image and upscale back to the system resolution. I spent months tuning my 3070 in openxr and dropping resolution to around 2500 with zero upscaling and MSAA x2 was best bang for buck image and performance wise. Give it a try

Ah, wrong end of the stick on my behalf The FPS tanking bug (which is what this thread is about) is 9-15 fps at random intervals, it can be alleviated by alt-tabbing for a while till the frametimes settle; I guess that's not what you're seeing? When you say 25% NIS do you mean 125%? 25% gives a render resolution of about 790x780 and quite expectedly looks like a badgers arse, 125% gives a render resolution of around 2530x2470. You might find it advantageous to ditch the upscaling and drop the resolution down to 2500, you should get less shimmer and more performance. Setting 125% in openxr toolkit is the same as running 80% - this is higher than AMD's ultra recommendation of 77% for FSR1.0 (as used in vrperfkit etc.) and actually a negative to performance as the upscaling overhead is often enough to discount the performance benefits. More resolution = more vram usage, especially when using MSAA, add the upscaling overhead onto that and you're actually going to be losing performance.

Simply going by the colour of the WMR overlay means that you're above or below refresh rate. If you're reprojecting then it's blue, interesting that you're not getting any of that? Look at the appCPU and appGPU frametimes, also the postGPU (which is partly the overhead caused by reprojection). I found with my 3070 high textures would show things down but not cause a crash due to lack of VRAM. What was found with the toolkit was that DCS would aggressively allocate VRAM which inadvertently withheld it from the reprojection. This still happens with steamvr and possibly oculus as well but was eliminated with the toolkit by earmarking a portion of VRAM for reprojection alone. What resolution and refresh rate are your using?

I'd try uninstalling the toolkit and reinstalling fresh.

What you've done is disabled reprojection, the auto option only applies to msfs and with any other app turns out off. The reprojection framerate tanking bug was eliminated from toolkit version 112 onwards. Make sure you have the latest version

This is correct, if you have a known good base to start with it's much easier to troubleshoot if it doesn't work @nikoelwrote the guide over several iterations whilst in direct communication with the openxr toolkit devs, he and I were some of the first adopters who got it working in DCS. At first there was virtually nothing you see now, any settings had to be changed via registry edits until the software matured more towards its current state. That guide should be considered THE definitive one for DCS.

You might need to set the ultraleap drivers to openxr, mine is running without any issues. Tracking wise, they're great when you have the environment setup. You have to minimise IR reflecting surfaces where you're using the hands otherwise the software can lose the distinct outline of the hands. Check the ultraleap visuliser to ensure that the coloured bones are present all the time, if they disappear then it's lost tracking; the bones will cycle colours each time it starts a new tracking instance.

You can run openxr without cleaning at all, however if there are left over dlls and the like in there that don't play nicely with the toolkit or open composite you're then chasing your tail to find out what's wrong. If you only ever ran vanilla you'll likely be ok, but given that most VR users have tried every hacky trick, mod and placebo under the sun in order to get reasonable performance then it was always most sensible to start with a clean sheet for the 5 minutes of time it takes to do.

The reasoning for having a clean installation is that it eliminates a whole host of potential pitfalls from previously installed mods and hacks. As this was a very new setup (DCS via openxr) the less time troubleshooting works caused by not having a clean install the better, especially as it takes time away from the devs who have to go on a wild goose chase to fix a problem they didn't cause, thusly delaying further development. ED have actively embraced using openxr, they removed the only file that needed to be manually removed and no modifications are needed to the DCS install at all to make it work. Undoubtedly the new engine will support openxr natively but it's wasted time to add it to the current engine. When this thread was made there was no openxr support with DCS, it was only implemented about 9 months ago