Jittery motion on Oculus Quest

okay so I upgraded to latest Oculus integration in Unity and then I had to update Oculus Quest as well. Now it is working but its the same results. Multi-Pass still renders only on Left Eye and black on Right Eye even after upgrading the project to latest Unity 2019.3.0f6. And this is through using Legacy XR System.

 

Got a confirmation from support that a fix for this will come in URP 7.2 update. Would be nice to know the ETA, since deadlines and stuff.

 

URP 7.2 is available now in Unity 2019.3.0f6.
https://forum.unity.com/threads/universal-rp-status.826323/

 

Did the issue get solved?
I was actually getting much better performance with mobile vertex lit shader instead of URP

 

This issue disappeared for us after upgrading, although I haven't looked to see if it has re-occurred.

 

I am using URP for Oculus Quest. There is alot of camera jittery motion and it is visible when UI elements are near the camera. What is the render scale you have set for URP and what are the best settings to enable for Oculus Quest?

 

You need to post more info than that, what is your framerate

 

Okay so basically I am using URP. The render scale of URP is set to 1.3f. Everything looks sharp but the camera starts to jitter with movement. This can be reflected with the UIs infront of the camera. However when I reduce the render scale to 1.0f, then there is no jitter motion in the camera, the movement is smooth, however the UIs in the scene look compressed and bad quality. So how do I make sure that the render scale is set to 1.3 as well as there is no jittery motion?

 

What is your framerate in FPS?

 

72fps

 

Here is the fixed timestep used in the application.

 

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.

 

@saifshk17 The UIs probably look compressed because they're using Mipmaps based on distance. Upping the render scale is not a good way to improve clarity. It increases the resolution of the render textures for the eyes, therefore increasing your rendering and memory costs.

Instead try moving the UI closer to the player camera, and see if that makes a difference. Likely you'll just need to find a distance where they don't get mipmapped, and a size that is legible.

 

Yes but my UI is in world space so it needs to stay in the position where it is. This UI is an image with written text. So is there an alternate solution?

 

After the Lightbaker made problems in all 2019 versions, I was happy with the latest Unity 2020.xxx. The Oculus Integration & XR also run without problems. Simple 3D model scene, with a few animations and no other code features. The head tracking is super smooth. Timestep 0.1111 (90hz) for my Quest 2. But the animations jitter as well. Is there a solution for this now?

 

You have a variety of options, but we'd need to know more about your setup. You can disable mipmaps on textures, but that can result in a shimmering effect on your text as the camera moves. You can also try increasing the font size, and then decreasing the scale, or try adjusting the dynamic pixels per unit on your canvas scaler.

Lastly, if none of these solutions work, you may want to consider changing or redesigning the way they're positioned in world-space so that they're closer to the player.

 

Left Eye and black on Right Eye even after upgrading the project to latest Unity 2019.3.0f6. And this is through using Legacy XR System.https://get-mxplayer.in/mx-player-for-pc-download/

 

HEAVY jittering/stutter still in 2019.x and in 2020.x - whatever unity is talking about, there is nothing fixed! They have other problems, like how many sexual predators are still in the company, for example. Helgason left the company, maybe because he was the predator. *fg "WHO CARES?!" ..... And NO - I wont always "DELETE THE LIBRARY FOLDER" and reimport everything, just because Unity has forgotten to do its job and someone in here thinks that's the solution for everything. That is so embarrassing and thousands of miles away from being professional!

If I start a simple project - AS A VETERAN! - and I publish it to my stupid, S*** OCULUS quest 2 - then it has to run smoothly from the beginning, because we have 2020!!!! and not 1984!!!!!!!! Jittering, Stutter, TimeDelta problems, Lightbaker for the trashbin!!!!! (look at plugin Bakery plus realtime tool as well!), Collab = BULLSHIT!, URP problems wihout any end - URP 9.x (which is still in development) ETC:..........

Is here anyone, who still has the jittering issue? Timestep to 0.11111 doesn't make ANY difference!
tested with ALL 2019,.x versions... as well with 2020.1, which is the one I need, because that stupid, F*** engine does have so many URP problems on 2019.x that I ask myself, how can a company go with that thing into production?!


appendix for hippocoder: it's not the fault of the developers. It's always the fault of those who run the company! but hey, tell that a developer -.-

Have fun repairing what cannot be repaired by you or someone else here in this thread. Therefore every further word here is superfluous. And the ban just ridiculous.

Adios!

 

This is a complete joke from unity clamining they fixed it i mean do they test these fixes? clearly its not fixed basicly any object that is being moved using delta.time is jittery meaning you simply can not use unity for vr development for the quest at this point, as a paying customer of unity i am just concidering moving over to UE at this point

 

SOIL is no longer able to post on this specific thread. No matter how frustrating an issue might be of a technical nature, it must always remain technical, not abusive.

Unity can't improve if the only feedback is anger. Please post bug reports, case numbers etc if issues don't appear to be solved by the forum in a timely manner. Attacking staff or company is not the answer.

 

You should try it then, or post bug reports. I hate to be that guy, but posting real bug reports and including the case # number in your replies is and always has been, the most effective way to get Unity to look at an issue.

The reason for this is that the vast majority of issues are the developer's fault. Unity does have bugs but they cannot respond to all users on the forum without a case number so they can see the problem for what it is, and not what the developer thinks it might be.

 

Prior to OpenXR, it was common practice to set the fixed timestep of a Unity project to match the frame rate of the device to eliminate "the jitters" as discussed above. Is this required anymore with pure OpenXR targeting multiple headsets?

 

We do this on Oculus Quest (non OpenXR, fwiw) and it definitely improves things, but we have almost the entire game running in FixedUpdate, so naturally it's necessary to lock-step the FixedUpdate with the rendering.

 

Hey there!

Since some of you here seem to have insight into what works well in terms of fixed time step with Oculus Quest 2, I kindly ask you to answer some questions (or point me to the answers, if I failed to find them):

1. What is the minimum viable fixed time step the Oculus Quest 2 with Unity 20.3 is capable of (e.g., in case I almost do nothing in the FixedUpdate) and how did you come by this information?

2. How would I notice (e.g. by using Oculus Metrics tool) or debugging via ADB that the fixed time step I chose is too small for the CPU/OS to support (e.g. 0.01)?

3. Some here are talking about correlating fixed time step and refresh rate closely. But won't that introduce interference issues?

4. Does anyone here know a comprehensive and up-to-date best practices guide for the development with Unity for the Quest 2? I have gathered information from places seemingly all over the internet. But for many options in the project settings and player settings I still have no clue if they actually affect how my software will run and what sensible values are for these options.

 

Just consider, unless you're using interpolation/extrapolation (and usually you don't want to because they have their own artifacts), your fixed time step *must* be equal to the display refresh rate. Otherwise you might have two render frames (26ms) that show an object frozen in the same position. This is especially critical in VR where subtle jerks are very perceptible.

1. Oculus Quest 2 supports a min of 72FPS, so 72FPS is the minimum fixed time step for smooth physics. Make sure to set max fixed timestep as well to the same value, so it doesn't take more than one in a single frame (unless you can comfortably afford it).
2. Use the Unity profiler. You should see a single Fixed Update for each frame.
3. Interference?
4. Unfortunately no. It's a hodge-podge of learnings over the last year or two. It's made worse because Oculus Quest is constantly improving, so things like ATW, FFR, change the 'common wisdom' of what the platform can achieve.

 

Hey Kleptine!

Thank you for your reply. After reading your reply I realized that I had the wrong idea about what "fixed update" was.
My application needs to measure user behavior in the VR environment at a rate as fast and as constant as possible. So I put this measuring into fixed update in my first attempt thinking measuring should occur regularly and not be prone to any changes in frame rate. This was me thinking that there were two separate processes running in a Unity 3D application, one for the refresh of the UI per frame (that could sometimes take longer than a frame and therefore be discarded) and another process, responsible for updating the world (physics, etc) in regular intervals (fixed updates). Why else should there be separate values, to adjust these refresh rates in unity, right?

Thanks for your advise, I highly appreciate it.

 

It's completely not necessary to lock the game to 72hz with FixedUpdate. Not only does this increase CPU time and run slower than it could, it also illustrates the project is not using Unity correctly, or it's just a bunch of workarounds.

Physics can and should be entirely decoupled from display frame rate. If there's issues with jitter it is because the developer is choosing to lock the visual rendering with with logical updating - something no-one has recommended since the 90s unless they had a very specific use-case.

For instance putting it all inside FixedUpdate doesn't guarantee that it won't run multiple times in one frame. It often will. A tragic waste of processing in my view.

The right practise is to decouple your rendering from your physics and interpolate the results. Even DOTS works like this. It will save a lot of CPU time, battery, temperature etc.

 

You're not wrong in general, but VR is has some specific constraints:

• The display rate *has* to run at 72fps, full stop. You will fail Oculus Quest certification if it doesn't. Single dropped frames can cause an incredible amount of nausea, even with the Timewarp measures Oculus takes. So you're already in a fixed frame-rate environment.
  
• Similarly, to maximize comfort, you want the objects in the game to be as close as possible to the the latest input frames from the controllers and headset. Otherwise your hands and held objects will drift slightly behind your real hands, even a few milliseconds of this is noticeable and uncomfortable. Interpolation makes this dramatically worse, and extrapolation causes weird jumping.
• Running physics at a lower rate means you may have two entire render frames where a physics object doesn't update based on your controllers. This is starkly noticeable in VR.
• Both interpolation and extrapolation have cases where it fails and will create non-physical behaviour. Interpolation creates a delay, extrapolation creates jumping.

Additionally, you can guarantee physics only runs once a frame using Time.maximumDeltaTime.

To be clear, you *could* run an Oculus game with 50fps physics and interpolation, but if you want to maximize comfort and polish, 72fps is the better choice.

 

Matching fixedDeltaTime to the HMD frameRate had miraculous effect on my project- no more camera jitter, thanks for pointing!

 

I've been developing on VR for a long time, you just don't need physics to update at the same rate. Things like hands and so forth can have weight - see saints and sinners for example. What absolutely needs to be updated is the head. This is the sickness vector and it is updated at refresh. If you set things up right, your game will scale through multiple refreshes. The concept of sticking to 72hz is incredibly bad engineering. No-one should do that. Carmack explicitly told devs to build a game that can go between 72hz and 90hz.

If you know what you are doing, you have an application that renders at the maximum framerate but physics and logic don't need to be in sync at all. The hmd needs to be at (current) refresh rate. Interpolation for the rest is fine, accepted, proven etc.

This leads to no stuttering or anything like that. That's just bad code.

 

I was using the 2020.3 without jittery motion with objects grabbed on hands, I change my unity version to 2021.1 and now I have some jittery motion problems with objects grabbed, my framerate is still at 72fps and my time configuration is the same, I really don't know what is happening.

 

To be clear, I'm not recommending you only develop your game for 72hz. Just that you should set your fixed update to the refresh rate.

But your point is not unreasonable. If you don't feel strongly about minimizing the latency and are ok with weighty hands, interpolation is fine. That kind of stuff really makes me sick though, so it's not something I consider acceptable for our projects. Even the smallest hiccups is really uncomfortable for a lot of folks, so I think it's worth maximizing comfort. Especially given that 72hz physics is not a major cost vs. 50hz.

Your total frame time has to be under 13ms, so even if physics only runs every other frame, the frames where it *does* run still have to have to be under 13ms. You have to leave enough space in the rest of the frame in case physics does decide to run that frame. So, you might as well run it at 72fps, anyway, unless you happen to have a variable workload that could fill those spots.

But yeah, many ways to tackle the same things.

 

Hi hippocoder. I've been following this thread trying to find the "definitive" answer to Quest 2 jitters as I am experiencing the same thing using Unity 2020.3 and URP. Would you be able to put what you said into practical terms that someone could apply in Unity? While I get what you are saying conceptually, I am not sure what the corresponding setup and implementation steps would look like in practice. Do you have any resource that might spell things out for someone like myself who is in need of a little more hand-holding?

I feel like I am chasing a moving target following the well-intentioned advice from many individuals, but nothing seems to get me any closer to achieving a smooth VR experience with Unity though your response makes me feel as if it is indeed achievable.

Thanks for any help you can offer.

 

Does it jitter if you disable all physics, render the same stuff, but just move your head? if so it's likely you're framerate bound. Even slightly dropping under causes jitters that look like bad physics.

If you've ruled that out then does a ball rolling down a slope with interpolation on jitter for you in a complex scene? if so it means your problem is CPU or GPU performance. If it does not jitter, it's a problem with your code itself, and much more likely an order-of-events thing or your own code somewhere.

Basically it's time to narrow down where the fault is. Even empty scene with gradual ramp and slow rolling ball with interpolation should be spotless and jitter-free in all VR setups, with fixed update being 30 or anything really. It should be slick.

But if a bunch of post fx or high res shadows are chugging away being drawn then that's a problem too. So test it in the most basic circumstances. Once you prove to yourself physics aren't jittery then you can hunt for the real problem.

 

Hey, thanks for the quick reply.

Head-tracking is buttery smooth with or without physics enabled. As part of my trouble-shooting effort, I have stripped the scene down to just the XR Rig and a single, static cube (no rigidbody). There is no fancy lighting/shadows or post-processing effects being used. Because of the nature of the game, I have gravity set to 0 on all axis so the rolling ball test wouldn't work in my case (though I can change things and try if it comes to it). Instead, I am using Rigidbody.AddRelativeTorque() in FixedUpdate() to rotate the XR Rig around the up axis as this is what I use as part of my player movement in-game. While rotating, head tracking remains smooth. It is only the apparent movement of the cube (camera is simply spinning in place with the rig) that displays the jittering. There are no dips in framerate (steady 90fps).

Other things I have tried:

• Interpolation on/off
• Using MoveRotation() with interpolation
• Adjusting Fixed Timestep setting up/down

UPDATE: Re-enabled standard gravity settings and tried the ball down a ramp with no camera movement. Ball motion exhibits the same jitter.

 

Then this unexpected behaviour - if physics move of their own accord with interpolation enabled on the rigidbody, it is a bug for this to jitter in VR.

If we math this out, so long as the rigidbody never reaches the position of the interpolation, it's impossible to jitter. For it to jitter means a timing bug in Unity, or even a physics bug because at this point, all Unity is doing is moving a transform smoothly between two snapshots.

 

OK, thanks for your help.

I'm starting to reach the unfortunate conclusion that Quest 2 development with Unity just isn't ready yet, at least not with my particular setup. It would be interesting to hear from anyone who has successfully developed for the Quest 2 using Unity and if there was anything in particular they found which helped (specific Unity version, Oculus vs OpenXR plugin, render pipeline used, etc).

 

Are you using the latest version of Unity? There were some fairly serious jitter fixes on the Unity blog a little while ago (earlier this year I think). You should make sure you have those.

 

Hey, just saw this. I'm currently on 2020.3.12. I see there have been a few minor releases since so I will give the latest a try and see if that helps.

Thanks.

 

Still having this issue on Unity 2021.3.2 running on Quest 2.

It only happens to physics objects. Frame rate is solid 72 fps.
I can't reproduce it on PC.
And it also only happens some of the time on device. Sometimes physics will stutter constantly other times it manifests as micro stutters.

Is this confirmed to be a bug or did anyone figure out the issue?

 

I think Unity 2021 LTS has some issues with Quest development, performance is way worse than with 2020 LTS. It might be linked to the fact that FFR is not working at all with OpenGL in 2021 LTS but I too had some serious stutters that I didn't have with 2020 LTS, especially when running at 90hz.

About the jittery motion topic, I ended up making my own solution for interpolation, inspired by this fantastic article.

I hope you found a good setup since your post, but since this thread popped up again I'd like to give my two cents.

My current setup is Unity 2020.3.x LTS, URP 10.9.0, Oculus SDK v40, Oculus XR Plugin 1.12.1, so basically whatever the latest package is that runs on 2020 LTS. I'm using OpenXR backend, OpenGL, Linear colour space. Both MSAA and FFR are working as expected, but I keep Depth Texture and Opaque Texture off since these both hit performance a lot, and cause rendering glitches with UI. I use real-time shadows both on Q1 and Q2, and on Q2 I even enabled Soft Shadows.
I only use shaders made with Amplify Shader Editor, because when I first started using 2020 I found out that even the most barebones integrated URP shaders were causing stutters. ShaderGraph shaders too seemed to be slow regardless of their complexity. Not sure if this is still true, but I'm sticking to my own Amplify shaders for the time being.

I've been running this configuration successfully for months now. I've recently tried Unity 2021 LTS since I got a M1 Mac, but Quest compatibility is not good with 2021 LTS so I reverted to 2020 LTS and all is good again.