edmuss

Absolutely, hence my caveat of the additional CPU load, essentially if your CPU frametimes are anywhere near close to your GPU frametimes then dynamic foveated rendering isn't going to help.

In theory you can sort of replicate the expected performance by changing your current headset resolution to suit the different pixel counts to see how it impacts on performance. I'm using the varjo aero using varjo_foveated, rather than the crystal using quadviews/pimaxXR but the same still stands as the functionality of the software is very similar. Running the aero at 39ppd foveated gives an equivalent stereo resolution of around 4620x3960 per eye (around 36.6mp total pixel count) and at this I get 85 - >90fps, if I were to uninstall varjo_foveated and override the resolution in openxr toolkit I guess I would be getting around 40fps. The total pixel count with my varjo_foveated settings is about 5.8mp, equivalent of 1700x1700 per eye stereo. So essentially, run your headset at stereo resolution of 4620 wide per eye and then run it at 1700 wide per eye and you should be seeing the performance delta between the two systems. Bear in mind that there is additional CPU load from having to render the scene 4 times with dynamic foveated rendering. Now the fixed foveated rendering that is being touted by pimax can never gain the performance uplift of dynamic foveated rendering without absolutely slaughtering the visual quality, from what I've seen, it's only a 5-15fps performance increase; nothing to be sniffed at but far from the 80-100% increase I see in the aero. Do note that the varjo implementation of dynamic foveated rendering is more efficient than quadviews and does garner slightly improved performance, likely because it is working with native code implementation within the runtime and DCS. Also that the higher the resolution, the larger the potential gains will be with eyetracking.

I've noticed recently that the leap motion tracking has been causing regular CPU spikes which are causing performance to momentarily drop and cause stutter when flying heavier missions (pretense syria modern specifically). I've only really noticed these in the last week or so. Will be flying along at >90fps but every 5 seconds or so the CPU spikes on main thread and fps dips to 85 for half a second or so causing a bit of a hitch. Setting the leap tracking service to low priority (from high) and affinity to cores 14&15 (DCS has no affinity set) seems to eliminate this without any noticeable detriment to the tracking, can anyone corroborate? edit: have carried out further testing and low priority with default core affinity is sufficient to stop the hitching, I've reached out to ultraleap to see if there's any way to automatically manipulate the tracking service priority edit: updated to the latest varjo base and it appears to have solved this issue, normal service is resumed with no CPU spiking at the normal high priority and core affinity. Must have been some negative interation between varjo base and ultraleap.

@Keith Briscoe if you want to fine tune your setup, use openxr toolkit advanced performance overlay and pay attention to the appgpu frametime number. For 60Hz I would recommend aiming to keep a minimum of 65fps to give you a little overhead. For this you want your appgpu to be less than 15.4ms, adjust your settings accordingly in the worst case scenario you fly in and you can bask in buttery smooth VR

Test out 60Hz refresh rate, there is a display panel associated with it in the G2, some people can stomach it, some can't; if you fall into the former camp then welcome to refresh rate DCS VR Also try running QVFR (https://github.com/mbucchia/Quad-Views-Foveated/wiki) with a fixed foveation as it saves a big chunk of performance.

If my warthog ever dies then I would probably be stealing using this to form a basis for a replacement cyclic but look at integrating my maglock trimmer into it

In the latest update, this appears to be fixed. No longer seem to have any major fps drop once the rotors are at full speed @BIGNEWY can you confirm if this is the case officially or has it been fixed in along with something else?

Unless you have a full blown simpit then I think passthrough XR is more immersion breaking for the purposes of a simulation game. For me, a well setup leap motion is far more immersive to reach out and flick a virtual switch as you retain the lighting from DCS, added bonus you can use the leap hands to shade the MFDs in bright sunlight Regarding the xr4, a lot of reports are of display artifacts which haven't been solved as of yet; it's far from mature and I wouldn't want to think about dropping that value on a headset without it being perfect.

Yeah, it is only a vague notion that it might do something, certainly no hard and fast change. For reference, don't rely on the VRAM usage in task manager as that will always show full with DCS (what DCS has allocated), use the expanded performance metrics and that will show you the actual VRAM in use.

Check the vram usage and budget (expanded performance metrics with right ctrl+pause) when this happens, it sounds symptomatic of overrunning the vram; when it happens the FPS jumps in square steps about 15-10 and the smoothness goes out the window regardless of your FPS. I suffer from it on certain modules (moreso the hind with it's masses of textures) if I run with high textures enabled; older modules like the A10C have a lower texture load so can run high without an issue. Also try the 'no sysmem fallback' option in the nvcpl, it stops the GPU driver paging vram to system ram. Theoretically it should only be for CUDA applications, however the nvidia GPU core architecture is also called CUDA so it might apply across the board? I have it enabled but can't say for certain that it helps, it certainly doesn't eliminate the issue and it may well be placebo.

Yeah, they're not cheap, but I figured having got the top end headset it would be silly to not spend on the controllers As it was, my G2 sold for 250 which covered the index controllers. It's quite possible to pick them up cheap with stick drift and I believe it's pretty simple to replace the sticks.

Likewise, sold my G2 and bought some index controllers Never use them for DCS though, only get turned on for HL Alyx and Into the Radius. I have a leap motion on the aero for handtracking and use mouse cursor slaved to the headset with mouse controls bound to hotas for backup when the leap motion isn't practical.

I typically see about 75% with the 7800x3D and 3080ti as well, I shouldn't worry about it

It's might be a break in the wire between the plug and the daughter board, in one position it breaks connection, flexed another way it makes connection. A multimeter on continuity connected to both ends whilst wiggling the wires would help identify if it happens again.

Possibly a broken solder joint or wire inside, only way to tell is disassembly.

Your settings are higher than I would run with your hardware, ghosting is typically a result of DLAA (Not specifically DLSS) and the lower you fps the worse it will be. However if you still get ghosting with DLAA off it's because you're below refresh rate of the headset and there is a frame desync; two options, get the fps above refresh rate or enable reprojection.

Using the meta PTC? V63 breaks DCS, rollback to V62 is the current workaround.

Not had any issues flying around Damascus, also I'm not using quad views but varjo foveated which is lighter on the CPU anyways. Worth remembering though if there is unexplained performance loss

Now of course with the qpro you might be beyond the point of diminishing returns with the 1200x1200, at some point the panels will become saturated as they're physically a good deal lower resolution than the aeros. With DLAA I find that there is no perceptible shimmer/resolution artifacts on the peripheral, perhaps just wind it down so it's at 60% and see how it goes. I know that the QVFR numbers work slightly differently to VFR but the concept is the same and whilst beta testing QVFR I found that performance was pretty much en par once the resolutions were matched. My reasons for using VFR over QVFR is that there is an eye tracking data bug between varjo base and QVFR and there is a higher CPU load with QVFR. Functionally though, they're pretty much the same system

I'm running the aero at 39ppd (1200x1200 focus 2192x1880 peripheral) with the peripheral hacked down to 0.6 which results in 1316x1128. DLSS quality and I see virtually no DLSS/DLAA artifacts, I am now hitting 90Hz refresh most of the time unless over Damascus etc. in the hind in which case it's 75-85fps. Your 4070 should be about the same as my 3080ti (in theory) so perhaps adjust the values to match and see what happens

DLSS quality / DLAA for me, through either the high resolution of the aero or high enough framerates (75-90 generally) I don't see any noticeable smearing. The DLAA allows me to drop the peripheral resolution right down and it kills all the specular shimmers associated with MSAA. The DLSS just gives me more frames for neglible visual loss, the higher render resolution of the aero gives more information for the upscaler to work with so apart from a very, very minor reduction in crispness it's all positive. In my testing MSAAx2 alone cost me 10fps, DLAA alone cost me 10fps, DLSS quality gained me 20 fps, thereby the net gain of DLSS quality setting is 30fps in my instance.

It's not an oled panel..... Mini LED displays in varjo headsets. I believe that there is an "anti-burn in" routine that varjo can carry out, I would ping their support. If I recall correctly it was something along the lines of forcing the displays to a bright white for a time to reset the panel, not sure if it was a public thing or just a dev option.

I think that's just a generic mount, not specifically design for the varjo xr4. Not sure on best placement on the face plate so as to not obstruct the lighthouse tracking sensors. If you can accurately measure (to 0.5mm or so) the leap motion 2 sensor then I may be able to modify my design to suit and send you and stl.

Can you clarify your message please? Are you stating that Razbam have now got access to the SDK and are implementing leap motion? or Are you pre-emptively thanking ED for releasing the SDK (as and when they do if they haven't already as above) and the message has gotten a little lost in translation?

Not sure, last I heard from Razbam was that they didn't have access to the SDK, I'll go check on the AV8B now, hold on.... edit: nope, not working with the AV8B currently, unless perhaps the SDK has been released and we're now waiting on the DCS release cycle to update each module?