Pitool has Sub-Optimal Timing: Motion Smoothing (Originally Titled: Something changed with Pitool on version .271 and forward)

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
yesterday
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:

6 Likes

This is such good news. A step in the right direction at last. Last time I checked PimaxXR/OpenXR etc. only supported a specific handful of games. I have (some version of it) working for Dirt Rally 2, and it’s a huge performance boost, but the vast majority of titles I have simply don’t work with it. Is that still the case or are new versions providing wider support? (BTW Kayak Mirage would be a good title to look at next if you are adding title-specific support. It’s beautiful, but requires PP and I’m clear down at 60fps in Normal FOV on my 3080Ti. Without PP in testing I was able to push 75fps/hz or 90fps/hz in Wide FOV - It’s been a while and I no longer remember which.)

Generally Kayak Mirage works without pp, only if you see something what I do not see.

DCS, ACC, MSFS, Subnautica 1 and 2 Modded, Dirt 2, and many others are supported in combination with open composite. Performance is usually slightly better, (be careful comparing steamVR vs PimaxXr as the set resolutions may be different) . Theres many more listed in the wiki. Many of them also permit FFR and provide further performance gains. In my opinion the gains are always positive.

Kayak Mirage definitely requires PP. The water is completely wrong without it; especially noticeable as you near the shoreline. Even with PP on the dynamic shadows in some areas are wrong (large snake or lizard shadow in Australia, for example). It’s the first title where I’ve noticed an issue even with PP on.

Thank you for pointing this out, its actually good :point_up::grinning:
i did not use pp on the hl2 mod, btw because there is almost no need for it.

Also noted many new games now work with PimaxXR. KAYak vR Mirage. ELITE dangerous HorizOns. Many others work but the index controllers dont - the folks with open composite need to fix those.

1 Like

In haven’t noticed a need for PP in Kayak VR when using PimaxXR and the newer OpenXR toolkit…keep trying? In any case, MSFS also has a bug with PPmode= off resulting in incorrect shadows. I hace placed a ticket in their forum to fix as they’ve come so far in supporting canted displays.

1 Like

Subsequently noted PP mode aspect ratio is not yet fixed in PimaxXR, but matt intends to fix in future.

I’ll give Kayak Mirage a try again with the latest Pimax XR and see how it goes. Even a performance uplift with PP enabled would be a benefit, and obviously if it has somehow fixed the issue with needing PP in that title in the first place that will make for a considerably performance improvement.

How can this still be a problem left unresovled in PiTool???

Still a problem in .280 - Has anyone tried .284? I can’t believe this persists - if it does - shame on Pimax as Varjo now has their Motion reprojection working (in house beta - not released)

ofcourse it was broken,i was wondering what was all that stuttering,it jumps to 30 when you arent even below 45