Jittery motion on Oculus Quest

Unity Engine
1

Good morning! I’ve recently ported one of my prototypes to Oculus Quest, and I’ve noticed that objects moving in the scene go through phases of smooth motion for a few seconds, followed by jittery motion for around a second, then repeating.

I’ve reproduced this with a super-simple project - one object in scene, bouncing left and right by modifying the transform directly, application.framerate set to match XRDevice.refreshRate, Time.fixedDeltaTime set to match XRDevice.refreshRate. I’ve logged a bug report for it (1157271). I’ve tested on 2019.1, .2b and .3a and get the same results.

The issue seems to be related to FixedUpdate not being stepped correctly - looking in the profiler, the smooth sections will have one set of fixed*** calls per frame, and the jittery section will alternate one frame of fixed*** then one frame where fixed*** don’t appear, for 40 or so frames.

If I set physics.autoSimulate to false, and manually tick physics.Simulate, the same issue happens (although the profiler graph looks different).

If I set physics.autoSimulate to false and don’t tick physics.Simulate, the issue goes away (but obviously nothing physics-related works, e.g. collisions or RBs).

Is anyone else seeing this behaviour on a Quest device?

1 Like
2

Sounds like some general desync issue rather than something related to the Quest specifically. With the variable nature of rendered frame times and the fixed rate of the physics engine what you’re seeing is something where the timestepping sort of resonates with itself.
I’d suggest not matching the fixed timestep to the framerate as closely as you are, as I think this is the primary source of your issues.
If you feel your physics objects still behave jittery you can enable interpolation on the rigidbodies.
Otherwise, if you’re manipulating transforms use Update rather than FixedUpdate to move them around. Respectively manipulating Rigidbodies should be done with Rigibody.MovePosition/MoveRotation in FixedUpdate so interpolation can do its work.

3

I followed exactly that line of thought, Schneider - I tried syncing the fixedDeltaTime slower and faster by various amounts (e.g. FDT at 71 vs DT at 72, FDT at 60) - they gave expected results during the smooth range (e.g. one missed fixed*** every second, one missed fixed*** every 6 frames) but exhibited the same bad behaviour during the jittery time window (alternating frames show no fixed***).

I’ve replicated this in a scene with a single GO (a sphere), transform being moved in Update(), no rigidbody attached. Same issue. Profiling shows (on device) it’s running everything apart from the wait in well under 5ms, 70%+ in XR.waitForGPU so it doesn’t look like a performance related stall.

I’ve tried setting vsynccount to 0 and 1, but that doesn’t seem to make any difference. The only thing that makes the issue go away seems to be not calling Simulate.

4

If you’re seeing the same jitters doing just the transform in Update it doesn’t sound like it’s related to the physics engine stuff, almost sounds more like a vsync issue, but you’ve tried tampering with that as well. Don’t really know what it could be then, sorry.

5

I’ve just tried a build to SteamVR (running on Vive) on PC. I’m seeing the same issue if the game window is fullscreen and has focus! the timing on the jittery window is smaller (1/3 sec every second or so, instead of 1 sec every 3 seconds) but it’s the same behaviour.

It goes away if the game window is windowed (with or without focus) or fullscreen but backgrounded (e.g. when I’ve got the editor foreground with the profiler running). Very strange indeed.

6

I’ve been having a very similar issue for the last couple of days - it’s been driving me up the wall.

Similarly, I did a quick Quest port of a desktop VR game I’ve been working on and noticed a persistent jitter when moving ‘held’ items (tracked to controller physically by modifying rigidbody velocity & angular velocity during fixed update). In my case the jitter is there most of the time with brief periods of clarity. (A bit like a resonance as mentioned above).

I’ve encountered similar judder on desktop before but it was always resolved by matching the fixedDeltaTime to the hmd refresh rate, or related to reprojection.

I’ve been messing around with interpolation, execution order, timesteps but whatever I do, the jitter remains.

2 Likes
7

Just FYI, downgrading unity to 2018.3.14f1 fixed this issue for me immediately.

8

Great into Adam, I’ve just tested the example project I logged with the bug, and the issue goes away for me too (2018.3.14f1). That suggests it’s a behaviour change in Unity, and worth pursuing to resolve.

1 Like
9

I can confirm that the issue is still present in 2019.1.4f1. Reverting to 2018.3.14f1 solves the issue

10

Just trying an almost empty scene on my Quest, with a standard OVRPlayerController, and I see jittery motion in general, even simply moving the head around. I’m using 2019.1.4f1 now but don’t really feel going back to 2018.x.x in this moment, this was just a random experiment after all. But I hope for a fix soon, I still want to try some stuff on Quest during the next days.

11

Anybody logged a bug report yet? Seeing the same issue in 2019.1.x on Quest

12

Same issue here

13

@Fingerbob , can you provide a link to this bug? We could vote for it.

14

@mohydineName I just got confirmation yesterday that they’d repro’d it, and were moving to fix. I got sent a link:

It’s not valid for me yet, though. Hopefully it’ll work in the next day or so?

The good news is that it’s been recognised as an issue.

15

Awesome. Thank you!

16

The issue is now active on the issue tracker
.

2 Likes
17

@Fingerbob , can you send me your repro project? I will send it directly to Oculus for review. Maybe it will speed things up.
I will send you my email by PM

18

Did anyone manage to fix this or find a workaround ?

I made a character controller that runs smooth on Rift S on Unity 2019.1.8
But on Quest it stutters, almost looks like edges of walls appear transparent cause it misses every other frame or something.
*framerate and regular head movement is smooth, just like posts above.

Does this mean any version beyond 2018.3 is unusable for Quest development ?

1 Like
19

Using VRTK v4 I have also noticed when using free Axis (Smooth Locomotion) Movement, the player movement can suddenly stop or begin to move in a direction (almost randomly) for an unlimited amount of time and no way to stop it by pushing the analogue stick in the opposite direction to the constant movement. It just gets stuck and sometimes movement stops working completely.

Whereas the same scene works fine using a WMR headset on the PC in editor, same controller inputs everything. Odd.

20

Hi everyone,

This has been fixed and will land in:

2019.3a12
2019.2.1
2019.1.13

Thanks for your patience and help!

-Will

5 Likes