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

PimaxVR Software Report Bugs
1

I’ve been testing for several hours each version of Pitool and I’ve discovered that .271 introduced a motion reprojection error where the motion smoothing kicks in 1:3 mode when FPS are well above the needed amount for motion smoothing 1:2 mode.

On 75hz:
If I’m getting 38-45 FPS Pitool inappropriately initiates 25 FPS Motion smoothing (1:3)
On 90hz:
If I’m getting 46-55 FPS Pitool inappropriately initiates 30 FPS motion smoothing (1:3)

On previous versions it works such that just above the threshold for 1/2 Hz; Pitool simply uses the 1:2 smoothing to wonderful effect! What changed?

I also noted that the frame rates for which 1:2 kicks in are 45fps on 75Hz. 55fps on 90Hz. Which at first seems not important, but It does seem curious to me that 45fps is half of 90hz; and 55fps is half of 110Hz - the next setting up the list. Could it simply be the thresholds got mismatched to the HMD Hz modes?

For some time I thought there was simply a “cost” or overhead to run motion smoothing, but this is simply not the case when I revert to version .270 or before.

@PimaxUSA @PimaxQuorra @hammerhead_gal

Can you please make serious inquiries into this?

Thank you for your consideration,

I’m sure you’re each very busy, but I feel that I’ve either discovered a major miscalculation that severely impacts your software or perhaps there’s more to motion smoothing than I understand. In which case I invite an explanation as I don’t want to debase or defame Pimax and your hard work. I only want to improve the software and experience for all users.

  • GPU:3090 (OC10%)
  • CPU: 12700K(OC to 5GHz)
  • RAM: 32GB(@4GHz) DDR4
  • HMD: 8KX

For other Users: perhaps consider trying 0.270 and try this: Find a scene where you get above your 1/2 threshold (38-44 FPS for 75hz; 46-55? for 90HZ), pause and switch on Motion smoothing - for me it drops to 1:3 ratio when it shouldn’t - or at least doesn’t in 0.270 and before. Perhaps there’s a reason or perhaps this is system specific. In any case I appreciate community feedback and input as I don’t assume this is the end-all-be-all of the situation.

6 Likes
2

Perhaps just an option to disable 1:3 motion smoothing would fix this. Kind of alongside the compulsive smoothing as a checkbox. Primarily the problem is 1:3 motion smoothing is just terrible on 75hz. And the bouncing between the modes is also terribly noticeable, where in .270 if you dropped to say 36 fps, you lost motion smoothing and a frame, but didn’t get shunted to 25FPS as well which looks far worse.

1 Like
3

Hello,

I sincerely appreciate you reporting the motion smoothing issue.
Allow me to escalate this to the Pitool team, and if they need any log files, would you kindly provide it to me through personal message?

Regards,

2 Likes
4

After more testing it appears that 1:2 mode does kick in after a few seconds - but only after 1:3 mode for a few seconds; then it hits a single frame-time that is below the appropriate threshold, resulting in an oscillating behavior between modes when in the ranges described above. Perhaps this is the intended behavior for Motion Smoothing itself, but the oscillation is a problem that did not occur in versions .270 and before. Perhaps a toggle to disable or allow 1:3 motion smoothing would be desirable?

1 Like
5

I can confirm the same. Running in 90Hz on .270 (8k+), smart smoothing keeps me reliably at 45fps (when sitting around 55-60 with it off, but occasional frame spikes). On .271 or higher, it oscillates between 45fps and 30fps, mostly 30. As mentioned above, it seems that any frame-time below the threshold causes it to drop back to 30fps for several seconds before it will try 45 again.

I can see a logic to this, i.e. you’re trying to make 45 feel like 90, but when it drops below 45 then better to make 30 feel like 60 rather than settle for a flat 40-43 or something. This could work well if say the framerate had dropped to 40 and then it kicked it to 30/60 after 5 seconds of staying down there or something perhaps, e.g. if you’ve moved to a more demanding scene. However, as it stands, with any single millisecond framespike causing the shift, the visual experience is much worse than if it was just left at 45/90. Occasional millisecond framedrops below 45 are not even noticeable, but the constant switching between 30/60 and 45/90 is terrible, particularly given that it spends most if its time at 30/60.

I’ll stick with 2.70 until this can be resolved.

2 Likes
6

Please message u/pimaxquorra and or u/hammerhead_gal for consideration of an ability to disable 1:3 motion smoothing in future pitool versions. We Pimaxians beg you! :wink:

7

I have complained about this repeatedly in these forums, so it’s good (well, not, I guess it’s actually bad) to see that other persons complaining about it.

IMHO the 1/3 rate is absolutely useless and should just be removed. I mean, maybe for a 180hz refresh rate HMD it might be kinda OK, but two interpolated frames for every rendered frame just looks like total crud, and 30fps (actual) is way too low a frame rate to be valid in VR anyway, no matter what the refresh.

The upshot of this is that I’ve had to completely reconfigure every game I used to play with smart smoothing so that I can get at least 60fps without smart smoothing, as the moment you try to use smart smoothing everything just goes to hell. As the OP mentioned, it kicks in way too early. For example, in FO4 I can have a scene that runs perfectly at 55fps in Normal FOV, but to get it to stay above 60 I have to reduce the resolution a lot or I have to drop to Small FOV. Therefore I would simply want to configure that game for 90hz 1/2 refresh rate with motion smoothing for an absolutely rock-solid 45fps. That is what I could do prior to the ‘broken smart smoothing’ versions of PiTool. But under current versions of PiTool that same scene will then dip to 30fps instead of 45fps. It will look terrible and play terrible! It’s absolutely nuts.

So yes, please, please ASAP give us the ability to turn off the 1/3 rate - or just remove it since it’s so bad anyway.

On the upside, being forced to play some titles at 60hz/60fps instead of 90hz/45fps has really developed my ‘vr legs’ well. I can now play all day long at 60hz with zero motion sickness even in free-floating/rotating titles such as Lone Echo. So that might be an option for some of you.

2 Likes
8

Perfect example of why it is so important to get this fixed ASAP: Lone Echo 2 requires PP and has terrible performance compared to the excellent Lone Echo 1 (it has worse performance period, but then throw in PP and it’s a fustercluck on Pimax equip.) I can’t quite maintain 60fps on my 3080 Ti; it micro-stutters in complex scenes. I could drop to small FOV, but… no… just… no… If I could run in 90/45 it would be perfect. But I can’t, because it’s all broken due to the 1/3 rate fiasco. So Pimax has implemented a ‘feature’ which is directly responsible for preventing me from playing a title well. It’s not just a bad feature; it’s "Let’s take this critical function (smart smoothing) that works fairly well and completely break it! And then leave it that way revision after revision! Really, it’s a ‘feature’ we promise!

Seriously, this should never have been implemented in the first place, period. Full stop. And once the very bad decision was made to implement a 1/3 rate, it should have been immediately removed.

3 Likes
9

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.

2 Likes
10

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!

11

@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.

4 Likes
12

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.

13

@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.

14

@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.
image
Turn of motion smoothing:
image

The above is also related to a similar issue https://community.openmr.ai/t/pimax-low-gpu-utilization-on-oculus-games/38066

15

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.

8 Likes
16

Anything new?

17

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
18

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!

2 Likes
19

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

1 Like
20

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.