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)