Jittery motion on Oculus Quest

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?

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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.

 

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

 

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.

 

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

 

Same issue here

 

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

 

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

https://issuetracker.unity3d.com/product/unity/issues/guid/1157271/

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.

 

Awesome. Thank you!

 

The issue is now active on the issue tracker
.
https://issuetracker.unity3d.com/is...ition-is-being-affected-by-time-dot-deltatime

 

@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

 

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 ?

 

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.

 

Can you confirm if the fix is implemented in 2019.3.0.a12? I am still noticing this jitter in a project using that version

Edit: I have submitted a new case bug report for this at Case ID 1178806, the jittering is severely affecting an app we have in development, on all PC VR platforms it runs just fine and I created a small example scene to demonstrate the issue.

 

Hi there we still have this issue with 2019.2.4f1
We couldn't go back to 2018.whatsoever. We tried a lot of stuff with different time settings (e.g. 1/75, 1/120, 1/150)etc.
Is there still a an open Case for this? (Didn't find1178806)
Or has someone a workaround on this? (e.g. exact time settings)
Any help is appreciated as we have a Beta launch on 15.11.2019

THANKS and Regards
Rolf

 

You're sure it's not related to performance? We were recently using 2019.2.4f1 and we didn't have this issue.

 

Hi Benjaminlaner,

yes pretty sure it can't be a performance issue due to too many tris or special effects (Just leaving 2 Objects with about 10k tris and 2 textures 2K each. Change from LWRP to old school shaders. No chance) We then use a simple controller without rigid body and the whole scene (without occlusion culling) has nearly 130k tris and about 6 materials with 2k textures and runs absolutely smooth.
Also to note on that... if you use rigid body and don't move (transform or apply physics) to the rigid body the look around in vr is totally smooth.
We think it has something to do with physics timing increase by unity which can't be really match with the time setting in the player settings.

We appreciate any ideas and comments.

Thanks

 

@BuzzLightyear
Have you tried fixing the physics timestep to match the display refresh rate (every frame)?
e.g. put this in a script somewhere in the scene

Code (CSharp):

1.  
2.         void Update()
3.         {
4.          
5.             if (XRDevice.isPresent)
6.             {
7.                 Time.fixedDeltaTime = (Time.timeScale / XRDevice.refreshRate);
8.             }
9.             else
10.             {
11.                 Time.fixedDeltaTime = Time.timeScale / 60.0f;
12.             }
13.  
14.         }
15.  

This also allows for slow motion effects, and when testing without an HMD

 

I'm still struggling with this as well, on build 2019.2.10f1. None of the proposed work-arounds seemed to accomplish anything noticeable.

Is the Unity team still thinking that this issue is resolved? If so, do we need to open a new issue against the latest builds?

 

You should open a new issue if it still affects you.

 

I'm having the same issue in 2019.3.0b12, it looks like it's caused by Multiview single pass rendering. When using MultiPass, the motion is buttery smooth, but it only renders to Left eye ¯\_(ツ)_/¯
Still aiting for a fix.

 

So 2019.3 is out and MultiPass still only renders one eye and Multiview is still unusable.

 

Apparently this is still an issue in 2019.2.16f1. I was banging my head against the wall until I found this forum. No issues when trying via Oculus Link, but if I deploy to Quest -> stuttery hand movements when holding stuff in my hand.

 

That'd be because you're dropping framerate under 72fps. At that point it's running on mobile, not desktop hardware.

Unless you're good at doing 3k resolution mobile games, you're not going to get that far. I have been developing on quest fine in Unity, in fact since it was possible to do so, a few months now.

When you press play, it's still using desktop GPU.

 

I am facing the same issue. Any update on this?

 

Our team did some digging and if you build with IL2CPP and read the debug info from android debugger, there are OpenGL illegal operation errors galore, multiple times a frame when using Multiview. Something is severly broken. Debug is clean on Multipass (which still only renders in left eye).

Still waiting for Unity to fix this

 

Please do report it as a bug using the Unity Bug Reporter and post the case number back here, I'll help chase it as I would also like them to fix that!

https://unity3d.com/unity/qa/bug-reporting

 

Universal RP 7.1.8 fixes this issue. Haven't verified through debugger, but the jitter is gone in a new build I did just now.

 

But I am using LWRP. The jitter is still there. Any update on this?

 

I removed LWRP and added URP, all I am getting is black screen when using Multi-Pass.

 

Multi-pass is broken, try Multiview

 

Multi-view works but it jitters alot which is why I am looking for multi-pass because it runs smoothly.

 

Also there is no multi-view option in Unity 2019.3.0 and no Universal Render Pipeline in Unity 2019.2.13f1, I am using LWRP instead.

 

Lol the official 19.3 release Multiview is still Jittery, and now Multipass is not only rendering in left eye, but is jiterry as well.
Well done

 

Seriously? Still no fix for this??

 

What's your physics timestamp setting for your project?

 

For me its just black screen on Oculus Quest (not even splash screen), neither multi-view nor multi-pass works. Just black screen. I am using XR system and not legacy one.

 

Unfortunately it's probably because the announced Vulkan Support for Multiview on Quest/Go is not actually working properly.

Can you report it using the Unity Bug Reporter and post the Case number back here please?

 

But I am using Color space : Linear and Graphics APIs as OpenGLES3.

 

That combo should definitely work, worth reporting it still as it sounds like a bug.

 

Actually when I create a new project it works properly, only when I upgraded my old project to latest version I get this error. It can't be related to my project right? Since it was atleast working in the older version.

 

Try deleting your library folder (make a backup) and reimporting the project