Hi,
Has any one tried upgrade com.unity.xr.visionos from 1.1.6 to 1.2.3?
After upgrade to 1.2.3, I found an issue that the frame jitter now and then.
I checked the changelog Changelog | Apple visionOS XR Plugin | 1.2.3
" Fix VR frame timing issues."
Is this issue ralated this change?
Unity 2022.3.27f1
com.unity.xr.visionos 1.2.3
App Mode: VR
I record a video, show this issue.
It happened also in 1.1.6, at least for me.
@mtschoen Hi, could you help to see is there a way to solve this issue?
Hi there! Sorry to hear that you’re having trouble. Are you using the built-in pipeline with MSAA? There is a known issue caused by changes in 1.2.3 when using these render settings. You should be able to update to Unity 2022.3.27f1 to resolve the issue. While you’re at it, I’d recommend updating to the latest Unity LTS version, 2022.3.31f1 to include any fixes we’ve added since then.
If the issue persists, please let us know and submit a bug.
Edit: my mistake, I see that OP was already using 2022.3.27f1. I’ll look for the bug report.
Thanks for you reply!
I’m using Universal Render Pipiline.
I had test 2022.3.31f1 with URP 14.0.11 and visionOS SDK 1.2.3 the jiiter issue still exists.
And I uploaded a simple project to show this case conveniently.
OK I see what you’re talking about. I hadn’t noticed this kind of issue before because it’s generally considered bad practice to attach objects directly to the camera transform in a VR experience. Some users can experience nausea if any content at all is “head locked” like the cube in your example scene. I recommend that you try using the LazyFollow script from the XR Interaction toolkit, or something like it to make this object smoothly follow the user’s head at a slight delay. The Mixed Reality and Image Tracking sample scenes for PolySpatial demonstrate how this script is used, as well as a few of the XRI samples.
I’m not entirely sure if this is a bug, but it’s something I’ll discuss with the team. I tested the same scene on a Quest 2, and while the jitter is much less pronounced, I can still see the cube jitter a bit if I move my head around quickly. I’m just speculating, but I’m pretty sure this is caused by view re-projection. The system can “nudge” the final texture around to “get ahead” of head movement, and as a result the cube isn’t always quite in the center of the frame. I’m not sure why this is more pronounced on visionOS, but I don’t think it will be an issue if you no longer attach visible content directly to the camera transform. Is there a reason why you need to set up your scene this way?
In my project, I dot not attach objects directly to the camera transform.
This is to facilitate the observation of jitter and reduce other interference factors.
Another example: The cube not attach directly to the camera transform but move near with camera, we can also see the cube moving jitter.If you need this demo, I can upload a mini project to show conveniently.
I found a discussion here, deviceAnchor | Apple Developer Documentation Could it be caused by this design?
@mtschoen I experience this issue only on objects that are NOT attached to the camera transform. Objects attached to the user’s transform are crystal smooth.
Also this issue in not happening on Quest.
We can’t release the visionOS version of our app until this issue is fixed. This is pretty serious for us.
I see. We’re definitely interested in resolving these issues but they can be difficult to track down.
Please do. The more ways we can reproduce the issue, the better! Thanks for your patience with this.
@AdrianAnta have you submitted a bug report for this? As I said above, the more repro cases we have, the better. Thanks!
It definitely has something to do with frame pacing and prediction. We are following those guidelines in our XR plugin, so it’s hard to say where the issue is coming from. We’ve made some improvements since our initial release, and from what I could tell at the time, we had eliminated any jitter issues. I’ll continue to investigate and let you know what we find.
Very happy to know that you are interested these issues.
I upload a new simple project to show that object not attach directly to the camera and move jitter.
Here is link. visionOS_1.2.3_URP_ObjectMoveJitter.zip - Google Drive
I also record a new video.
Thanks for sharing that project. I don’t see anything wrong with the recording, but I think that is because recordings on visionOS are limited to 30 FPS, and the judder is happening on frames that aren’t captured by the recording. In any case, it looks like that object is animating smoothly, albeit quickly, so it appears to jump a significant distance per frame.
It appears that the issue is specific to moving objects, especially ones closer to you. I never really noticed before, but even the particle system in the sample scene (which I created 
) shows this jittery behavior if you are looking for it. It doesn’t seem to happen with static objects. I think that’s why I haven’t noticed it, because the scenes I’ve tested are mainly static with objects that move based on hand tracking, which shows a similar issue but that’s because the hand tracking data doesn’t update at 90FPS. Or at least I thought that was the only reason…
I ended up doing a test with the Xcode Metal template for visionOS. Normally, this just shows a large rotating cube in the distance. But if you modify the sample to resemble the test projects you sent me, the same issue occurs. It’s more infrequent, probably because Unity is doing more work per frame (running the player loop, lighting in the shader, drawing the skybox, etc.) which compounds the underlying timing issues. It’s possible that the device is presenting the triple-buffered textures in the wrong order, or maybe it’s a bug in depth-based re-projection.
Can you build and run this project to confirm that you see the same thing on your device? There’s a section in Render.swift, line 228 where you can swap the update function to lock the cube to your head instead of oscillating side-to-side. In either case, I see a few frames of judder every few seconds, very similar to what I’m seeing in your Unity test projects. I’ve submitted this project in a feedback request to Apple. Let’s see if they can shed any light on this. At this point, I’m fairly confident that this isn’t something we can fix in our Unity projects.
I am facing the same problem. It feels like the problem is not only on moving objects. I also get jittery on static objects. The key is the distance between you and the objects, and how intensively you move your head(like rotating your head and change head height at the same time). I also find that may the near clip plane distance is related to this problem. If I increase near clip plane distance, the jittery turns to be more intensive.
I had build and run this project and confirm that I see the same thing on my device.
This seems to be an apple’s issue.I will continue to pay attention to this issue. Hope Apple can help.
Of course, thanks for your help in moving this forward.
Hi, Is there any new progress?
I want to share some of my recent analysis.
I used xcode 16.0 beta and xcode 15.4 to create visionOS app templates respectively.
There are many differences here.
The main differences related to judder are as follows:
I found two workarounds:
Modify visionOS app template with xcode 16.0 beta, observe oscillating side-to-side and lock the cube to my head. In either case, the judder is gone.
Modify this project as image bellow
My question is: Is there any workaround by modifying Unity or something else?
Hey there! Indeed, the issue in the Xcode template is related to thread priority. I also learned that setting renderThread.qualityOfService = .userInteractive.
Unfortunately, this is more complicated in our case because we don’t actually simulate game state on the render thread like this example. Just setting the thread priority of our render thread doesn’t fix the issue like it does in the template, but we’re working with Apple to resolve this. I’ll keep you posted.
Strategic comment 
Have the same issue, waiting for updates
Hi all! Sorry this has taken so long, but I’m happy to report that we’ve tracked down a number of issues and now we’re in the process of getting the changes landed, tested, and shipped. No time frames yet, and unfortunately there’s a fair amount of risk involved so we will need to be careful and take our time with this stuff. But thanks to some help from Apple and users like you we’ve made a ton of progress on this issue! The result should be fewer dropped frames and generally better performance in GPU-bound titles for visionOS. Again, thank you so much for reporting these issues and being patient with us.
I’ll loop back on this thread when I have specific versions that contain the fixes. Cheers!
This is really exciting news, can’t wait to try the new version.
