Pimax Motion Smoothing - Possibly Fixed (via PimaxXR)! (Originally Titled: Something changed with Pitool on version .271 and forward)

It would be nice if you could set the thresholds for 1/2 and 1/3 to engage per app. This is a tuning parameter. Depending on the nature of the game, you may want smoothing to engage more aggressively or less aggressively. 1/3 could be effectively disabled by just setting its threshold to something unreachable.

Personally, I don’t use smart smoothing at all because it would engage earlier than I want. For the kinds of games that I play, I’d only want to use it sparingly at times when frame rate has really tanked badly.

I end up just leaving the automatic setting off and only ever turning it on manually (compulsive smoothing) when I need it. And then only 1/2.


I find myself doing very much the same: Compulsive smoothing 1/2 becomes my most common favorite. Acceptable frame rate; smooth frame-timing. I have to hit the 45fps threshold for 37.5 fps motion smoothing that actually does interpolation (most likely due to overhead costs, I get that now).

At the risk of repeating myself: The problem currently with motion smoothing being active is the second one frame time gets stuttered due to CPU or texture loading you get to spend 3-5 seconds in 1:3 garbage mode until it recovers.

Incredibly, in 120hz mode this was just fine as the 1:3 garbage mode was 40 FPS and not so bad, but I still didn’t want to sit there for 3 seconds because of one frame-stutter!

@PimaxQuorra @PimaxUSA @hammerhead_gal Ultimately, at least for me, the 1/3 option will simply NEVER be acceptable. It causes so much image warping, and stutter, and other issues that I never, ever want to see it. I dislike interpolated frames anyway, so the 1/2 function is as far as I will ever want to go. Things worked OK with Smart Smoothing before the 1/3 function was implemented, but as I’ve complained about over and over; with the implementation of the 1/3 function I no longer consider motion smoothing to be a viable option - it’s now utterly useless to me.

Please, Pimax, simply give us the ability to go back to the way it worked before. I played a bit with it yesterday in Kayak VR Mirage (Unfortunately requires PP if you want to water to look right - it’s just a bit off. Otherwise this title would easily provide 90fps in Wide FOV. Is it stands I can get 60-75fps in Normal FOV.) I can tune a it to give between 60fps and 75fps without issue, then set my 8K-X to 60hz. Turn on smart smoothing and it’s frequently dropping all the way to 1/3 rate. All the way! It doesn’t even need the 1/2 rate! I can cruise that entire area at a rock-solid 60fps. Smart smoothing should not even be activating in that scenario, but it’s dropping me to 1/3 rate. What a deeply disappointing issue.


Im starting to understand where the logic of the 1:3 came from. The overhead thats required is the problem. It makes perfect sense: you turn motion smoothing on and the software says OK no matter what I’ll do motion smoothing after all you clicked it. The software logic makes perfect sense. It is presumed that motion smoothing is desirable at 1:3 over 1/2 compulsive. A hybrid mode is more complex, but gives the best of both worlds. Hopefully we can work positively with Pimax devs to make this leap.

@DJSlanr It is true there is some overhead, but not anywhere close to enough to cause the issues we are seeing. Those lucky enough to be able to use 2.71(?) can go back and use that and see how well the system worked at that point. I do sometimes use the forced 1/2 rate with no smart smoothing. It’s not terrible that way, depending on the title. Anything with quick fluid motion ghosts very badly on movement. Take a game where you have an arm and wave it back and forth in front of your face, or rotate with the stick instead of physically, and you’ll see that ghosting. Some titles it’s fine, other’s it’s really annoying and not a great option. I still think it comes down to one very simply thing; PiTool should have the option to turn the 1/3 off. That’s it. Problem totally solved.

@mbucchia is taking a peak at some of the older versions while trying to adapt the motion smoothing for PimaxXR. Perhaps he’ll discover the error if there is one? Just found an instance where 58FPS cuts to 25FPS motion smoothing. Yeah it can’t just be overhead IMHO.
Turn of motion smoothing:

The above is also related to a similar issue Pimax Low GPU Utilization on Oculus Games

My observations so far are that there is something seriously wrong about how pi_server is handling the frame throttling for motion smoothing, and unless your app is running in SteamVR, you are always getting into 1/3rd rate any time your frame time is over 10ms… This is not correct.

I’ve looked at calls to the PVR client API for begin/end of frame (pvr_beginFrame() and pvr_endFrame()) and pi_server is inexplicably making me wait > 20ms/frame when the app frame time is 10ms, effectively taking me down to 30 FPS when at 90 Hz.

Interestingly, running the same app (which was DCS) through OpenVR in SteamVR, the calls to begin/end of frame are never blocking. It never gets throttled. Instead, it appears that the SteamVR driver itself is managing frame timing, and throttling down to the appropriate frame rate for motion smoothing. I want to be able to do that too!

I initially assumed that I misused the PVR API, but then I took Pimax’s very own sample code (SimpleVRDemoDX11) and I bumped up the amount of rendering in the app to ~16ms, I get 60 FPS as expected without motion smoothing, but then immediately 30 FPS with motion smoothing… So the issue is reproducible with Pimax’s very own sample code.

I spent the day searching what SteamVR is doing differently when using the PVR API, logging every simple PVR call, disassembling and searching both the PVR client library and pi_server, but in vain… until I finally had the idea to rename SimpleVRDemoDX11.exe to vrserver.exe (which is the name of the SteamVR compositor process). And there it was, all frame throttling is gone!

I inspected the initialization sequence in the PVR client library, and it is indeed looking if the running process’ name is vrserver, and if it is, it toggles an additional bit when establishing the session with pi_server. This magic bit seems to give total frame timing control to the application.

EDIT: I also just found a magic openvr_client_render_ms PVR property that the SteamVR driver must set every frame and that seems to control the activation of Smart Smoothing. Anyway, none of this stuff seems documented anywhere! :slight_smile:

I’ve sent an email to my contact at Pimax to shed some lights on what’s going on here. Meanwhile, I am writing a hack in my Pimax OpenXR runtime to impersonate the vrserver process and implement my own timing management, and hopefully be able to force apps to use 1/2 when possible.


Anything new?

Meh, yes and no.

I was wrong about this statement. I spent a lot of time now instrumenting the Pimax sample, and it behaves as intended (can do 45 FPS aka 1/2 rate under the expected circumstances). My original experiment was flawed and has some hidden CPU load not accounted for.

In fact I went pretty far and added to both the sample and to PimaxXR a “simulate workload” mode where I can precisely adjust the amount of CPU/GPU load per frame (using hotkeys, and you can see the app CPU/GPU numbers reflect it in OpenXR Toolkit for example). So I can create pretty much any situation. I was able to show that with a sample OpenXR app and with a simple OpenVR (+ OpenComposite) app, the motion smoothing rate is selected properly. I could go up to ~19ms on both CPU and GPU and still get 45 FPS motion smoothing. This is very different from what we’re seeing in DCS where anything above 14ms triggers 30 FPS (aka 1/3 rate).

So there is another variable introduced by DCS (and probably other titles) that is left undiscovered.

This behavior was confirmed by Pimax engineers, along with the use for the openvr_client_render_ms property. What my original experiment missed is that an application named vrserver.exe won’t do motion smoothing unless the timing reported via openvr_client_render_ms indicates that motion smoothing is needed. So when I said “all frame throttling is gone” it was not a true statement. Frame throttling was gone, because motion smoothing was gone too. Obviously not what we want.

I’ve done all that but unfortunately, it also only works with simple applications, and any larger application still had this unknown variable interfering with the proper behavior. Even reporting fake timings to pi_server doesn’t change the rate from 1/3 to 1/2.

1 Like

Its ok. I revert to pimax .270 everytime I want 1:2 motion smoothing. Its sad, but eventually I may have a 120hz unit where 1:3 is still 40 fps and I can lock the input frame rate to keep it there. Still it will try to interpolate 2 frames vs 1. But it’s all we can do unless PiTool gets an option to explicitly disable 1:3 motion smoothing. Motion smoothing is effectively borked for all users at this time as it will drop to the 1:3 inappropriately.

As for PimaxXR I hope they keep working with you to help identify the issue with DCS and MSFS. I am confident PimaxXr is a just better way to roll !

Thanks for all your endeavors, working with Pimax.
Thank you Pimax for working with great Devs like Matt!


HI ,How about turn on compulsive smoothing at 1/2?

1 Like

What? Im talking about motion smoothing.turning on compulsive smoothing has no effect when the motion smoothing jogs between 1:3 and 1:2. I think I have to refer to the first two posts.

Unfortunately the difference being motion smoothing -which interpolates frames; where compulsive smoothing does not.

If i can get 1/2 the frame rate naturally I should get 1:2 motion smoothing to add in the missing frames for the smoothest experience. Simple enough

Regrettably when 1:3 was added/enabled: when you get say just under the 1/2 rate -it shunts all the way down to 1:3, which is far worse than disabling disabling the smoothing altogether.

Example if running 75hz. Maybe try a game that runs a decent 40fps, it should go to 37.5 and smooth up to 75, but no for whatever reason pitool sees one frametime that was 36fps and shunts the whole mode into 1:3 mode and doent get back on track for like five seconds. 1:3 motion smoothing is then 25fps and looks like garbage for 3 - 5 seconds before it reverts back to 1:2 mode which looks good. Regrettably the thresholds are messed up such that we have to acheive FAR more than the 1/ rate to keep it in 1:2 mode…probably closer to 55fps…unfortunately we cant choose frametimes so we sgould have an option to disable 1:3 motion smoothing.

Smart smoothing turns on automatic selection of none, 1:2, or 1:3.

If you turn off Smart smoothing and instead use compulsive smoothing 1:2, it will be in 1:2 all the time.

It’s the same 1:2 as smart smoothing selects. But just forcing the setting. That way it will never go into 1:3. But it also doesn’t go to none either.

Smart smoothing involves Interpolation (and if advanced enough, even used depth buffers to calculate the interpolated frames. Compulsive smoothing does not. Politely and with respect : Compulsive smoothing is entirely different from smart smoothing at 1/2. Simply put, compulsive smoothing is a frame rate limiter only. Nothing else, which is entirely different from smart smoothing 1:2. Im sorry, it is similar in numerics only. Entirely different in output. Im shocked to read that that might not be understood by so many.

This is terrible: the idea that choosing compulsive smoothing 1/2 locks motion smoothing to 1:2 is not correct. Not only does it disable the interpolation, if you get 1 bad frametime it will drop to motion smoothin 1:3 and will look like crap for 3-5 seconds while it recovers.

This is a that needs some kind of fix and it’s possibly getting muddled.

@mbucchia can you chime in here

This is the way I thought it should work. Based on the names, it would make sense that “smart” means make the decision. But keep reading.

Thats my impression too yes. Compulsive smoothing alone doesnt seem to enable the interpolation, effectively making it a frame limiter.

As a matter of fact, the internal property name attached to Compulsive smoothing is dbg_force_framerate_divide_by, which reinforces this theory.

Maybe that is a bug and Compulsive Smoothing was intended to turn on the frame interpolation (meaning Compulsive smoothing should automatically/implicitly turn on Smart smoothing as well).

That said, you can enable both Smart and Compulsive smoothing at once and achieve the desired result (interpolation + frame limiting).
But when you do that, I don’t recall what happens if you select 1/2 but it cannot be achieved… I think it justs falls back to no interpolation indeed, which is bad.

Here’s a good way to tell if the interpolation is running at a given time: use pimax_cli to read the value of asw_active. AFAICT this reflects whether or not the interpolation is happening at any given time.

Would be interesting to turn on both Smart smoothing and set Compulsive smoothing to 1/2, then take a game down to < 45 FPS and observe the value of asw_active. My guess is it with be 0 (no interpolation), aka bad experience.

1 Like

Interesting. I’ve actually tested this before as I didn’t like the automated selections of smart smoothing. In a very busy dance world on VRChat with about 50 avatars, I enabled compulsive smoothing 1:2, and I did clearly observe smoothing in operation. It’s fairly obvious when interpolation is functioning in VRChat. Especially since there are some things it gets wrong with certain shader effects.

The curious thing I found about it is that smoothing only worked one time per session. That is, if I enabled compulsive smoothing 1:2, then it functioned as I expected. If I then switched it off and then back on again, it did not work as expected again ever after for that session. The expected smoothing did not happen. If it was limiting the frame rate, I wouldn’t have been able to tell since the effective frame rate was well below 45Hz. I restarted and rejoined the world a couple of times to verify the behavior of only working the first time I changed the setting.

This wasn’t very formal testing, and I wasn’t testing to see whether interpolation was enabled by compulsive smooth specifically at the time. And this was also a while back on 275 (I think). So it’s possible that I was mistaken or maybe I’m remembering wrong. Unlike other more formal tests that I’ve done, I did not write this down. I was more interested in the dance party at the time.

So if I’m wrong, I apologize, and thank you for correcting my understanding. I may do some experiments with 280 now to verify, but I expect that you are correct.

Ha interesting observation! I tend to turn off/on many times per session for the sake of testing, so perhaps this is why I observed no interpolation most of the time. Checking asw_active might be the only way to know for sure. I don’t have my Pimax hooked up now but I will run the experiment next time.

1 Like

Thats useful. Thanks!

@mbucchia may have a fix in process for this…one that currently works for OpenXR via his PimaxXR and one that he thinks could be applicable to all apps, effectively overriding the way PiTool currently (incorrectly in my opinion) determine the frame-times. I can say it’s working well for me in DCS, but not in MSFS at the moment. It’s very exciting indeed! Someone REALLY cool at Pimax gave him some guidance as to how things work (nothing internal/secret I don’t think, just helpful), so credit to Pimax as well for working closely with devs like @mbucchia. Hopefully it results in an improvement for everyone!

1 Like

@mbucchia has released a PimaxXR 0.2.6
Linked here: GitHub - mbucchia/Pimax-OpenXR: PimaxXR: an unofficial OpenXR runtime for Pimax headsets.

Tested it in DCS and MSFS - and I’m stunned with the improvement.

A few of us have tried it out, for me it seems to resolve the precisely the issues listed above regarding motion smoothing.
The option to employ the fix is a toggle.

First of all, it doesn’t shunt to 1:3 mode until it’s much closer to the appropriate frame-time, (there’s still some overhead to motion smoothing as a process itself), but for example I can fly at 37.5fps with motion smoothing with frame-times @ about 25.5 ms, which would be just over 39 FPS.

It also uses an average of 5 frames to determine whether to shunt to 1:3 mode, so you won’t find yourself in 1:3 mode unnecessarily with single bad frame-time as often occurs with MSFS etc.

Additionally - and this is just my experience - the 1:3 mode looks much more acceptable when it does shunt to 1:3 mode. I would love feedback from others as to their experience

I find this incredibly wonderful for MSFS and DCS, which are so demanding that motion smoothing actually serves an important role. (I think we can all agree we would rather run at full refresh rate when possible).

Most importantly: I’d also love for Pimax to consider the methods used by this to improve their own implementation of motion smoothing, so if I may ask @hammerhead_gal and @PimaxQuorra to continue working closely with Matt as his work is taking the VR frontier forward in so many ways!

Thanks again @mbucchia for everything!

Here’s a discord link to Matt’s discord: