@stekusteku Yup, you can, but not all frame rate locks are created equal nor work at the same layer of the rendering pipeline. The RTSS and NVCP ones work at the driver level, and rtss is much much better at it. Weirdly the older Nvidia CP locks worked better, the V1 and V2 ones. The current V3 is pretty terrible.
There is another method of controlling frame pacing at an even finer level, using the Special-K directx injector, but that is a seriously deep rabbit hole, one I can’t recommend if you like your sanity, hehe, and with this amazing latest WMR Tools update it is no longer needed anyway. RTSS is more than good enough to smooth out the remaining bumps in MR.
Some people aren’t very sensitive to micro stutters. For me they’re like stepping onto a stationary escalator, over and over and over again, extremely jarring. MR smoothness depends very heavily on being given highly consistent frame pacing to work with, with as little variance as possible, and ideally when the GPU side has a longer rendering time than CPU. Outside of 2D Vsync MSFS doesn’t have any kind of internal fps lock to handle this (really really wish it did). This means some kind of external lock is required so that MR can have something stable to work with.
In my experience after many months of testing and tweaking with motion reprojection on…
-
NVCP max frame rate setting only = intermittent micro stutters, some hard stutters
-
OpenXR Toolkit frame rate throttling setting only = continuous micro stutters, some hard stutters
-
OpenXR Toolkit reprojection lock (1/3 or 1/2) only = continuous micro stutters
-
(New) OpenXR Tools for WMR reprojection (1/2 or 1/3) only = intermittent micro stutters and occasional hard stutters
-
RTSS lock only (30 or 45fps) = pretty smooth, occasional hard stutter
-
New OpenXR Tools for WMR reprojection (1/3 or 1/2) with prefer framerate over latency set on + RTSS lock (30 or 45 fps) + OpenXR toolkit MR on (unlocked) = ultra ultra smooth
There are a hundred factors that affect frame pacing in the sim in VR. One of the biggest problems is that some of the sim’s rendering and interaction is tied to its own 2D window / mirror. Things like mouse position and line of sight etc seem to be taken from that, and that window runs at the refresh rate of the monitor it’s sitting on, not the HMD’s refresh rate.
This creates a continuous cycling fps conflict in MR due to the fact that windows doesn’t run at precise even multiples of 30hz. Most 60hz monitors actually run at 59.936 hz, most 120 hz monitors run at around 119 hz. This discrepancy isn’t a problem for 2D flying, but in VR it can produce brief rhythmic stuttering when the desktop window manager tries to bring them back in line every few seconds, and in MR this stutter is immensely magnified.
I get around this problem by running a custom desktop refresh rate of precisely 60.000 hz. This refresh discrepancy problem can be seen in the OpenXR toolkit’s dev display, with cpu wait time continuously increasing or decreasing (depending on selected fps lock) until it runs out of room in the frame, hard stutters, and then cycles again. The greater the frequency disparity the more often it happens. When the monitor and HMD are both running at precise multiples of the lock (30.000 fps in my case) it’s rock solid.
I could probably write a pretty awful book about this stuff at this point, hehe.
