Roughly every 1-2 seconds, there's a small judder/stutter in PCVR games when moving. It's almost like a previous frame is rendered again. It is very noticable in alyx and boneworks using the joystick to move left/right and looking at a static object. I assume people playing with other movement types wont notice it easily.
It does not show:
Only shows in headset.
I have tried two PC's:
Most testing has been done on PC#2, but the experience is exactly the same.
What I have tried:
I have read countless of topics complaining about steamvr/alyx/boneworks stuttering.
My first thought is:
It might be the nvidia driver thing:
However it seems like it should be solved unless you run GPU monitoring software, which a fresh windows install obvously doesn't have. Odds are that this might not be the case, but everyone with new nvidia drivers should experience it, and some people claim to have a completely smooth pcvr alyx/boneworks experience? Are they just not using smooth locomotion and not noticing it?
My second thought is:
My headset is either broken or the stutter is a software error, either with the oculus compositor/encoder or the decoder on the headset. Again here, other people should experience it.
It's just a general thing with quest 2 and people just don't notice it? I experience no issues at all with native headset games.
I have only had the quest 2 for a couple of months and while I've enjoyed native games (mostly beatsaber), it has been a huge dissappointment having so many issues with PCVR.
Anyone have any advice at all? I'm about at that point where I consider returning it as defective.
If you want to test it, just boot up alyx or boneworks, look at a static object fairly close to you and move left to right to left continuously (smooth locomotion). You should see a small stutter every once in a while.
New Quest user running a 5600x, 3070ti 16gb ddr4 3600mhz
Exactly the same issue as @ghodzy has i think. Basically whether running Virtual Desktop, airlink or cable I encounter a frame drop and micro stutter whilst moving. Looking around Im fine.
If i set to 90hz it drops by 2 or 3 frames causing a stutter (minute but noticeable and immersion breaking)
If i set it to 80hz still a drop by 2 or 3
Same at 70hz and at 60hz
PC has plenty of headroom and is smooth on when looking at PC monitor. Running a 600mbps broadband connection running via ethernet to PC and a 5ghz connection to quest 2 with a connection speed of 866mbps
Tried everything and still no joy. I'm assuming its a lost cause considering the number of posts here and across the internet
I too have this exact issue, and I'm at least a little relieved to see I'm not the only one. There is absolutely some sort of tracking bug when it comes to movement of the controllers in SteamVR games. Once you notice it, it becomes very distracting very quickly.
For reference, my specs:
i am also on this endless quest to fix this issue.
Swaped my entire hardware, GPU, CPU, RAM, storage in the hope that would fix this.
I agree with your last point, i think most people don't notice, as a lot of people sensibilities to this kind of stuff is different, it and claims its run fine in their system.
I'd had a similar problem that I thought I'd fixed but has now returned.
I don't know why this is so difficult. Doesn't Facebook WANT their headset to reliably work well through Link?
So this is weird, but seems related.
I've been experiencing this EXACT issue (jitter/stutter that looks like a duplicated frame, while framerate, frametime and latency are all smooth on the graph) on my Pico 4 that I got a couple weeks ago. Happens when using the built-in streaming assistant (wired or wireless) as well as with Virtual Desktop. Made a post on Reddit about it.
Really seems like it must be an encoding/decoding issue. I believe the Pico 4 uses the same Snapdragon chip as Quest 2 so I wonder if it's actually occurring on the decode process on the headset itself.
Yes, it could be at the decoding end. But since both are going through an encoding process on the computer, it could be there too. I suspect that the issue is more likely with encoding.
I think two tests would likely pin this down a little: