RedX

I concur.

Seems like a minimum resolution limit on peripheral vision with motion smoothing.

The box might have something to do with shadows and level-of-detail settings? The peripheral and focus areas have different "rules" for lod, which is easily visible when there are trees nearby.

Motion smoothing crash is reproducible for me as follows: It depends solely on the peripheral area total resolution: 1404x1204 or below and it will crash as soon as motion smoothing is on. 1408x1204 or above and it does not crash. Therefore, "Low" and "Very Low" settings in Varjo Base at multiplier=1 will crash motion smoothing. Using the default "High" setting in Varjo Base, the minimum multiplier for peripheral is 0.8482. Focus area may have any multiplier and it does not crash on motion smoothing. Even very low is ok so that your gazing direction is blurred. I wonder if the values are the same for everyone and why this happens.

You are correct. When systematically testing whether a setting or change has impact on performance, I usually leave the headset on table or hold it in my hands so that anything on Windows desktop can be visible all the time. Usually I try to make many simple, direct comparisons and use them as a "bunch" to figure out what is best for me.

Oh, I've missed this one. Sounds like it should be on my PC settings checklist. Thanks for pointing it out.

Have you noticed that Varjo Base itself provides some stats and "live history graph" similar to fpsVR? It is found on desktop by clicking open the analyzer window (one of the icons on left side of main Varjo Base window) and then clicking the grey icon at the bottom left corner of the analyzer window. This brings up a row of new selections at the bottom of the window. One of them toggles the statistics display on/off at the right edge of the same window. Not visible in the headset 3D view as far as I know.

Maybe I should test again, then, to rule out any random error. But, in any case, I doubt that removing the hack gives me improvement. EDIT: Verified without the hack, result on major slowdown persists, maybe by about a quarter (not 1/3). Plus graphics artifacts. With the hack installed, everything is normal.

In my case, the performance is degraded by about one third without the "disable quad views" hack. Both CPU and GPU take a hit.

Quick test result. Settings: Varjo Aero, 3090, R7 5800X3D, X570, 32GB DDR4 3200MHz, Win10 etc.; VR standard preset settings in DCS, Varjo resolution High(default). No reprojections, vsync off. Pre-rendered frames =1 in Nvidia settings. OpenXR Toolkit disabled. Instant action Syria AH-64D hot start at ramp, in cockpit, looking slightly left towards the tanker truck. FPS reported by DCS (ctrl-pause) and Varjo Base analytics window performance tool. Route 1: around 48..51 FPS (DCS counter), 46..49 FPS 18..19ms CPU 20..22ms GPU (Varjo Base counter). Route 2: around 47..50 FPS (DCS counter), 45..49 FPS (Varjo Base counter), flickering when loading missions/menus, sometimes erroneous rendering/tracking, tracking is lost much more easily if poorly visible to base stations??? Route 3: around 34..35 FPS (DCS counter), 34 FPS 28..29ms CPU 24..25ms GPU (Varjo Base counter), no visible quad rendering but poor performance and artifacts in the smoke on the right side. Route 3 plus the extensions wrapper (https://forum.dcs.world/topic/318268-varjo-aero-dcs-native-oxr-oxrtk-and-offset-cockpit-cursor-issues-fixed/#comment-5143050) : 48..50 FPS (DCS counter), 49 FPS 18ms CPU 19ms GPU (Varjo Base counter), EDIT: twitching gone after reboot. a lot of "twitching" when rotating or translating head, very annoying (discussed in another thread IIRC?). Conclusion: Route 1 & 3 (if quad view is disabled) are much preferred in this case. Did not test pure SteamVR/OpenVR at all, since OpenXR allows the use of OpenXR Toolkit and fixed foveated rendering which gives me >10% performance boost at my preferred FFR settings. I did not play around with any of the reprojection/motion smoothing settings at this time.

One more vote here! *** This was working perfectly. Now it is broken. ***

Accurate dialing of cross-eye tool values can be done in at least two different ways: 1. Click on one of the numbers, they are actually input fields; then press TAB and SHIFT+TAB to skip forth and back between them; cursor is now present and you can type in the value you want and the effect is immediate (on the first click the original value in that specific input field is usually lost due to slider movement, but it can be typed back in after returning to that input field using tab & shift+tab); if you make a big mistake, you can always start over by clicking RESET. 2. Use Notepad or Notepad++ to edit a previously saved .lua file corresponding to your headset where the values are stored (in Saved Games\DCS) and they will be read on the next launch of DCS.

The folder: <yourusername>\Saved Games\DCS Filename where the cross-eye setting is stored for Varjo Aero is either "hedy.lua" or just ".lua" depending whether it was running through OpenComposite or not. You can see the .lua extensions on file names by ticking "File name extensions" option on in the View ribbon of File Explorer window. Other headsets use different file names. Valve Index setting is stored in Index.lua, for example. If using OpenComposite with Varjo, there should be no need to change the cross-eye tool values, it will only result to the fishbowl-effect. In SteamVR, a possible fishbowl-effect on Varjo is removed by using the tool and switching the top-bottom values.

Checking the reviews of Vive Pro 2, I get disappointed. Their pricing is much higher than that for Valve, but the only thing where there is improvement is colors and resolution. That FOV improvement over Index is marginal, basically the panels are rotated 90 degrees . For any serious FOV increase there is only Pimax and the expensive industry grade gear. Simultaneously, the audio side on Pro 2 appears to be very poor, sweet spot remains small, and lens glare is significant just like in Index. Very difficult to justify the price bump, I would say. Dburne, please may we have a comparison from you written here on Index vs Pro 2 when you get it?

Replying to myself... I investigated a bit further and found the following. This applies to my case, not sure about others. YMMV. - the slowdown/jitter/cpu frametime increase depends on the mission file - 2.7 has made it worse - deleting saved games\dcs improved the situation a lot on certain missions; at first it was not clear why; it turns out that delete is not really necessary, but instead... - Ta-daa! TACVIEW file recording has some issue with the new version, it was not turned on immediately after deleting saved games folder and thus things looked better. It may have something to do with the number or type of AI units or their activity in the mission. --> if you have this issue, check out whether turning your Tacview completely off helps (options - special - tacview - completely off)

Exactly the same on my AMD 5800x, the CPU frametimes are through the roof with 2.7 update. Maybe this is some kind of thing that is CPU or chipset related as that would explain why not so many are reporting the problem? Perhaps Intel/Nvidia is more tested and optimized? Maybe ED has no AMD hardware to test with due to cryptominers buying it all? In any case, the performance issue has to do with DCS core(?) engine overloading the CPU. Graphics is hardly related, because if I hit "pause" everything is super smooth and un-pausing makes things go slow and jittery again. Tried to remove the infamous windows KBs (500...something) and vortex calculation - no help. Ditto driver updates.

The values are pulled from "somewhere" where they have been written at the factory when the headset was calibrated. The values vary from one individual unit to another, because the mechanical panel placement is not as accurate as needed in this application. Most likely the left-right values are calibrated ok at the factory and the values should need minimal adjustment if the headset is ok. The up-down values seem to have a bug regarding the sign convention somewhere. In some headsets the calibration values are symmetrical enough so that it does not matter.

I'm not sure whether frametimes shown by DCS match those shown by fpsVR. Do they?

CPU frametimes on MP is a difficult test to perform reliably as the workload on MP servers can vary a lot during the time it takes to swap the cards. To tackle this, a cycle of quite a few card swaps would be required in order to make the differences of 10-20% observed reliably. Maybe 3-6 times back-and-forth. I don't plan to perform such a laborous testing at this time. To avoid it, one could have a custom, non-changing MP server with no other clients on it, but it would probably not be any different from SP testing.

@med0ra Tested with that mission 1 you suggested, both 6800XT and 2080Ti. And, well, would you guess, the result was the opposite: now 6800 XT produced slightly faster CPU frame times than 2080Ti. Key figures below. 6800XT: CPU 50% 13.6ms; CPU 99% 22.1ms; GPU 50% 10.6ms; GPU 99% 14.6ms 2080Ti: CPU 50% 14.5ms; CPU 99% 22.1ms; GPU 50% 11.5ms; GPU 99% 15.7ms Despite all the card swapping, driver reinstallation etc. the results for instant action missions (my first post) are still repeated and there, when standing on the ramp / ship, the Radeon card is more taxing on the CPU than Nvidia. I can only conclude that the changes in CPU load may vary greatly depending on the mission. Perhaps the computational workload of different graphics items is differently distributed among the CPU and GPU. Now I have no clue whether I should keep running 6800XT instead of 2080Ti despite the larger amount of VRAM

exil, did you clean up nvidia drivers with utility like DDU when you switched the card? Or did you just insert the new card and leave all the old drivers around? Did you reinstall steamVR? I wonder whether it matters which output port is used for VR headset, too. The RTX 2080Ti is back in the computer and CPU frame times are the same as before as recorded by fpsVR. I think I'll try to install 6800 XT again and see if the result changes by tinkering with the installation procedure or settings.

I benchmarked Nvidia RTX 2080Ti, RTX 3090 and Radeon 6800 XT using the same settings in DCS. While RTX 3090 is of course clearly the fastest of the bunch, I found a weird thing considering the CPU frametime values recorded using fpsVR. It appears as if both Nvidia cards have similar CPU frametime and performance despite the large difference in GPU performance. This is expected. The Radeon 6800 XT, however, shows much higher CPU frametime values. The difference is enough to be of practical importance. Actually, sometimes it seems that the 6800 XT is resulting in lower fps rates than my old 2080Ti due to higher CPU load. I very much prefer lower CPU load, because that is usually what is limiting my frame rate in VR (graphics load is tunable by various settings). I'm not sure if something went wrong when reinstalling SteamVR etc due to the entirely different set of graphics drivers. I attach an example of fpsVR graphs. In this specific case: -all possible settings the same for Nvidia and Radeon -mission is the F-18 instant action "ready on the ramp" in PG -30s fpsVR recording sim stopped, then 60s more fpsVR recording with sim running (plane just idling on platform) --> 2 peaks in graphs corresponding to pause on and pause off -steamVR set at 202% with Valve Index (2864x3184) -CPU is i7 9700K @4.9GHz, Z390 chipset, 32GB RAM @3200MHz -Nvidia CPU frametime is around 15.5-16.5ms paused, 17-18ms unpaused -Radeon CPU frametime is around 18.5-19.5ms paused, 20-21ms unpaused, around 15% worse than Nvidia! Can anyone else verify that Radeon drivers eat this much more CPU than Nvidia drivers in DCS and VR ? Or did I mess up something when switching drivers?

Looking at the results and especially the very nice photographed results above (galinette, excellent simple but functional setup!), it appears that at least some headsets have an issue when the top and bottom values are reported. Whether that is due to DCS or drivers or headset or some other thing, I wouldn't know for sure. However, since I detect less misalignment in other games, I'm afraid that it is DCS that might have some numbers reversed somewhere, not steamVR. In order to not sound too harsh here, I want to say that I've encountered similar things numerous times in my work when there are just 2 options of how things may end up, front/back-up/down-left/right-mirrored/direct etc. It is very easy to confuse those and miss them in testing when dealing with optics and software. The great thing is that DCS allows the tools where such stuff can be corrected as long as the user knows what he/she is doing. More documentation would be appreciated BTW, regarding galinette and his/her images, the remaining misalignment may easily be due to the mechanics imperfection of the IPD adjustment system. (The left-right misalignment I would dismiss for now, because the HUD data display is not really projected at infinity and is modelled so in DCS so there should be small left/right misalignment with infinity-aligned imaging system such as the camera setup used.) Uxi: you can create that file in C:\Users\<your windows username here>\Saved Games\DCS\Config or equivalent on your system. It does not exist by default.

Hi all, I'm having a trouble where I often accidentally click an additional direction of a 4-way hat simultaneously when keeping the intended, original click pressed for an extended period of time (>1s). The switch is mechanically such that this happens very easily when not intended. Especially since the orientation of the 4-way hat changes slightly along with different throttle position so that my muscle memory has a bit more trouble than usual keeping track of the orientation. How to programmatically prevent that from happening? So that when any of the 4-way hat directions are clicked, all three other directions (or the 2 nearest ones) turn inactive so that they do not work/give signal until the original 4-way hat click is released? That way simultaneous / diagonal clicks of the 4-way hat would be prevented. Currently the hat is configured as 4 buttons, not as a POV hat. EDIT: Found it but in such manner that the diagonal click turns off the original click i.e. there is no input when hat is in diagonal direction (Button page - ALPS decoding - mode pulldown list: 4W instead of 8W) . I would like to have the original direction/click to stay on when simultaneously clicking the additional direction/diagonal direction until the original direction click is released. Does this make sense? Is this possible? BR, RedX

I've experienced this on Valve Index both on carrier and elsewhere. MSAA is always off. However, I get a feeling that it most likely appears if I have high graphics settings (despite MSAA off) and especially if Nvidia GeForce Experience driver's video recording function is turned on.