some1

Now you're just confusing things. First of all, the guy you quote explains the specific metrics shown by MSFS overlay unique to that simulator. Then he explains what happens when reprojection is turned on: For reprojection to be able to match the display rate mentioned above, it is easiest to lock the app framerate to a rate that is divisible of the refresh rate. This is why for your 90Hz display, we will try to lock at 90 FPS, or 45 FPS, or 30 FPS, or 22.5 FPS. This way for each frame, we will either do (respectively) no reprojection, 2x reprojection, 3x reprojection or 4x reprojection. The OpenXR-Toolkit option to lock FPS also works only when OXR reprojection is enabled. Direct quote: When motion reprojection is not enabled, this setting has no effect. https://mbucchia.github.io/OpenXR-Toolkit/other-features.html#lock-motion-reprojection That happens only when you turn the reprojection on, and do not touch the "lock motion reprojection" option in OpenXR-Toolkit. Without reprojection, you're simply submitting the frames to the headset as they arrive. They are postprocessed using the latest headset motion data, but not as heavily as with reprojection (only rotation is taken into account). This can introduce perceived stutter, mostly with terrain moving outside the cockpit, because even when DCS is making around 45 FPS, that's not in sync with headset display. Some frames will stay on screen for 22ms, while other will show for 11ms. It's like that with every framework, OpenXR is not doing any new magic here, at least not to my knowledge.

I wonder that too. What people try to describe here is simply not possible, headsets are not Variable Refresh Rate displays, and holding the same frame much longer than the other because it missed the display refresh "tick" is the definition of stutter.

Regarding motion smoothing, I can also tell that the one in OXR, when enabled, is not as good as in SteamVR, with more tearing and distortions visible. Maybe the proxy library is not sending all the needed data. You're not the only one who said there's no difference on his system. To me it looks the same without reprojection, with FPS usually hovering between 50-70, and typical stuttering. Either I'm missing some settings, or just different people have different perception levels with this stuff.

Hi, no multimonitor setup, desktop resolution is 3840x1600 (24:10 aspect ratio). The headset is Reverb G2.

Much like in Mi-24, George menu is also stretched horizontally in VR

Oh so that's yet another issue. Helicopters do not get "Confirm Landing" call from ATC until they are on top of the runway, so they don't even get the spotlights in 2.1.11.

That switch is irrelevant. On further search, this behavior may be correct if the knob controls the whole glideslope/marker receiver (R-1963/ARN) and not only the marker lights. Not sure, it may also be wired to VOR radio switch. A strange quirk.

Volume off, glideslope inactive Volume on, glideslope active

If you can't even contact ATC then you have a different issue. Here I can talk to ATC, but it won't turn on the lights until I'm literally above the runway.

I contact ATC and get inbound vectors. But ATC will turn on runway lighting only when tower has given permission to land. For helicopters, tower gives permission to land only when the aircraft is at the runway threshold. The result is you have to fly the whole approach in total darkness. There is a runway straight ahead.... A track with takeoff (ignore) and landing https://ufile.io/tf1wjge0

Sure it looks like it's GPU limited in FpsVR and MSI Afterburner. Anyway, just to do a baseline test and avoid the variation between various DCS settings, I recorded the graphs below when using 100% resolution in both SteamVR and OXR, and with VR preset in DCS. First mission is AH-64 in overcast, the second is MiG-15 in clear sky. Not much of a difference to be honest. The VRAM footprint is the same this time, the fps in the Apache may be slightly better in the OXR with less fluctuations, but hard to be sure. If there's a mind blowing difference somewhere, then sadly not on my PC.

I prefer to run high DCS settings (MSAA, shadows, high res textures) rather than bump headset supersampling. 60% in SteamVR is already higher than G2 screens resolution, not sure if it translates the same in OpenXR, but it seems so, looking at the performance and image quality. 100% in OpenXR certainly tanked the FPS, to the point of being unplayable.

This software lets you map the gamepad axes to keyboard buttons, which you can then assign to triggers in DCS https://github.com/AntiMicro/antimicro/releases/tag/2.23. You triggers look reversed, in the Apache the left fires the weapon while the right one is for laser. Doesn't make much difference, although to guide the Hellfire you need to hold the trigger for a while and slew the sensor at the same time, and the real Apache layout lets you do it with one hand.

I tested SteamVR and OpenXR back and forth on my system a couple of times (5900X, RTX3800, Reverb G2) and the results are, well... inconclusive at best. I used only the three files provided in the first post, did not use OXR toolkit. Set the resolution for both frameworks to 60%, which judging by performance and image quality, match quite well. Used the same settings I normally use for DCS, I don't have any shader mods. At these settings I'm GPU limited almost all the time. Also checked the performance metrics from MSI Afterburner after each session and compared results. The performance between SteamVR and OpenXR is roughly the same for me: In the light MiG-15 clear weather mission, OpenXR seems to be using about 500-1GB less VRAM. In a cloudy AH-64 mission, both frameworks use all the memory of my GPU (10GB). In the MiG-15 mission, both achieve 90 fps, but dip slightly below when looking around. In the AH-64 mission, OpenXR hovers around 38-44fps mark, SteamVR shows a few fps more, maybe because it's being uncapped as mentioned before. Not that it makes a noticeable difference in smoothness. GPU power draw in this situation is also slightly higher for SVR, which would confirm that theory. Image quality in OpenXR seems to be a bit better, in that the image seems to be a bit sharper, but also more jittery. So it's not like a resolution bump, more like a sharpen filter, or just a different scaling algortihm being used. Always hard to compare these things without the actual frame side by side displayed on the monitor. Motion smoothing in OpenXR does not work when set to auto, but works when forced on. However, it's always on, even if the framerate dips below 45 fps. In that case, it's using the next divider (1/3rd or 1/4th) and having motion smoothing from 20fps is a miserable experience anyway. Overall, it's an interesting development, but not a magic boost like some other claim here, at least not for me. May be different hardware, game settings, or just placebo effect at play.

That's still several times too fast for an accurate depiction on a monitor or VR helmet. At 100 fps without special gfx tricks you just get a massive strobe effect.

Maybe try to add a bit of deadzone for the gamepad thumbstics?

ED has already figured out how to get rid of the flicker in the Hind. They just need to implement the same solution here. (And hopefully in older helicopters too when they find the time).

After playing with the gamepad yesterday, a few thoughts. You need to be able to press lrfd trigger and move the right thumbstick at the same time, otherwise you won't be able to adjust lase point when guiding Hellfires. Likewise, you need to be able to press weapon trigger and move the right thumbstick at the same time in order to aim the gun while firing. So the xbox layout from the first post is not very practical in this regard. WAS buttons and sight SEL buttons are not that important to have them on the gamepad, as you can use the same HATs on your joystick that you use for the pilot. That frees a few buttons for other functions. Worst case you can put them on a keyboard. I tried the free AntiMicro software to map the analog triggers to buttons so I can use them as TEDAC triggers in DCS, and it works quite well. Worth a try.

Something seems broken. In Mi-24 there is no flickering in the cockpit, even though there is rotor shadow on the ground. In the Apache, there is flickering in the cockpit and you can't see rotor shadow on the ground. It's like the condition on which surface to draw rotor shadow is reversed.

Ffb trim enabled in special options? I've no idea why ED decided FFB trim Mode is the default option.

TBH I rarely use it myself. I just trim according to the situation. The middle position is not the correct position for hover anyway.

Guys, it's really easy to check if it works or not. Pick one of the models that has the new FLIR enabled, check how it's supposed to look, then check in game how it looks. Done. I'm surprised at this point it's even being questioned by ED. For example, this is how the Land Rover should look in FLIR according to ED's model viewer: notice the opaque glass, hot tires and canvas, cool body. This is how it looks in the Apache: And this is how it looks in other ED aircraft (hint: the new FLIR is not working) Silly enough, it's working in Razbam's Harrier, which is the one aircraft that was not mentioned anywhere in the changelog: zFLIR2.miz

The power levers are coded just like the throttles in other aircraft, the idle cut-off position is not part of the axis throttle range but needs a separate button command.

The reset trim button does not exist in any of the other helicopters simulated in DCS, it was always a convenience function. Looks like ED forgot to add it this time.

Just because 3rd parties say they did not touch anything, does not mean it's working the same if ED made global changes under the hood. More so if they are checking a different version, than the one which was uploaded yesterday for customers.