Recent Discussions
Yellow overlay over certain scene objects
Hi there! We've encountered a strange bug in our Unity build where some scene objects appear with a yellow overlay when running on Meta Quest 3 or 3S devices. This issue does not occur on the Meta Quest 2. The bug appears intermittently—sometimes, after restarting the application, the objects display the correct colors, while other times, the yellow overlay returns. What do you think this could be the problem with? Please let us know if you need more information. Unity Version: 6000.0.51f1 SDK: Open XR v1.14.3 Devices: Can be reproduced on the Meta Quest 3/3S, can not be reproduced on Meta Quest 2 Graphics API: OpenGLES3
OneGrabRotateTransformer Enquiry
Does the Meta SDK v77 still support OneGrabRotateTransformer? If yes, how should I properly reset it? In my case, when I rotate a door using OneGrabRotateTransformer and leave it open, then click a 'Restart' button that resets the door's rotation to its initial state, the door doesn't behave correctly when I try to interact with it again. It doesn't rotate the same way as it did the first time. How can I fully reset the transformer and allow the door to be grabbed and rotated as expected?
The Meta Full body avatars are kind of a nightmare to work with
This post is not a question as much as just general feedback after working with the SDK. I want to gage if other people have had a similar experience. I work on a multi user app that was built originally with half body avatars in mind but with Meta announcing that they would discontinue support for them, we had no choice but to migrate to full body. Our app is very versatile and covers a lot of different movement and sitting types so solving for each individually is not ideal. What I expected: All current VR hardware (with the exception of additional trackers) gives us three fundamental inputs on the position of the user: head + both hands. Logically, all of the avatar systems I have worked with up until this point take that into account. They take a head + two hand positions as input and voila the avatar is now in the right place in relation to the floor. In the case of a sitting avatar, you would probably input another location that defines where the avatars butt should be to sit in the chair. I fully expected the full body avatars to work like this. Having a body and legs adds the extra difficulty of using IK to animate those other parts but I figured Meta had some good algorithms for figuring that out and would provide a simple way of giving inputs and getting an animated avatar as a result. What I got: Meta decided that bifurcating the first and third person avatar animation and restricting the appearance of the third person avatar to remain in realistic positions was more important than the reliability of the position data. The entire system is built around displaying different head and hand positions in third person compared to first person. Crouching does not just match the avatars head to the position of the user, it measures how far down your head is and then plays a crouching animation to a level that mostly lines up. Hand positions are then placed relatively to the head to maintain a normal body structure. This causes a tornado of problems if you want to do anything that does not come pre packaged in the SDK. Even just allowing the user to sit in a chair and freely look around 360 degrees is not included. The user pointing at a specific spot in the environment or at a specific place on another user's body becomes this confusing multiverse conversation about everyone seeing different things. Metas hybrid of IK and normal rigged animations is a nightmare if you want to accommodate more than one thing. Our app allows users to switch between standing, walking, sitting on the floor, or sitting in various chair sizes and shapes seamlessly. We also have a lot of objects that the player can grab and move which track their position independently and synchronize it over the network. The provided sitting behavior that you can find in the LegsNetworkLoopback scene is totally unusable for me. All of the movements of the users head are clamped to stay still in third person, meaning that lots of body language is removed and also objects they may be interacting with appear to float around unconnected to their hands because the first person hand position that the local user sees gets totally altered by the sitting animation. I had to make my own alteration on all of the crouching animations to get a more versatile sitting animation in which the user could actually move their head and be seen doing so. One of the things we rely on to make all of our different seating scenarios work is that we apply offsets within the rig to raise or lower the user and get their head to end up in the right place. You can remain sitting in real life but we will adjust where your head ought to end up in relation to the floor by shifting your play space around. This totally wreaks havoc on the meta system. Just to make it so that the user could transition between virtually sitting and standing without changing positions in real life and KEEP THE AVATAR HEAD IN SYNC with their actual head position was a large undertaking. I think one of the biggest problems is that the rig that applies animations to the avatar does not even match up with the position of the rig in the scene. You have this totally invisible rig off in the middle of nowhere that defines what the avatar will look like for others but does not actually line up with anything in the local scene. There are just so many scenarios in which the third person rendering of the avatar deviates greatly from what the user in first person is actually doing that networking a sensible world in which all users are experiencing the same thing becomes a struggle. We used to have high fives that worked pretty well and now everyone's hands render slightly different in third person and it ruins the feature. Meta have abandoned the one idea that I would have thought to be the most obvious critical feature. In first and third person, the head and hands of the avatar should always match the inputs given by the user. TLDR: Zuckerberg was clearly scared by everyone making fun of the avatars before and so meta ended up sacrificing absolutely everything to put large restrictions on the movement of the third person avatar to keep them from looking silly. For Horizon that's great, for a bunch of apps that were built on a different system and would like to be able to provide the same inputs, it's a nightmare. My request: Please add a normal IK system, where all I do is tell the avatar where my head, hands and butt should end up and it will do the rest. I understand that I'll get some funny VR chat looking stiff movement or stretched limbs from this but at least the position data will be reliable and I won't have to figure out this complicated puppeteering system that only renders for other users.
How can I run a Unity app as a background process while I play another game on the meta quest 3?
I’m trying to develop a meta quest 3 application that runs in the background so I can record controller data (IMU and button actions) while I’m playing a PCVR game like SkyrimVR. my headset will be connected to my pc with an oculus link.
Passthrough on windows desktop VR
I'm finding loads of guides for how to get passthrough working on a standalone android build, but what about when running on windows and connecting via a link cable? Is this possible? I haven't been able to get this working on either OpenXR Meta or Meta XR SDK. I understand there might be some security thing preventing the headset from streaming its camera output to a PC... in that case, can I at least call some API to put the headset into passthrough mode so that just the user in the headset sees through the cameras, and not stream this data to the PC? Would like to be able to programmatically allow the user to see through the cameras for a few seconds, and then put them back into the unity scene again Best, FredXR Composition Layers are invisible when the MetaXR feature group is enabled
I am using Unity's XR Composition Layers to render a canvas (like a floating desktop) on a Meta Quest 3. The problem I am facing is that the canvas is invisible as soon as the Meta XR Feature Group is enabled. I am using: Unity 6000.1.2f1 Meta XR Core SDK 77.0.0 XR Composition Layers 2.0.0 OpenXR 1.14.3 URP 17.1.0 Unity OpenXR Meta (for passthrough) 2.1.1 The composition layers work well as long as the ‘Meta XR’ Feature Group is disabled in the XR Plugin Management settings for OpenXR. As soon as it is checked, without changing anything else, the composition layer is invisible on device. All my tests on device were done with an actual build, not via Oculus Link, as a build is where is should eventually work. The same issue was posted here on the Unity Discussions Forum. Unity has confirmed that it is caused by a bug in the Meta SDK package, which appears to be disabling certain layers at runtime, which prevents Unity's code from executing properly on the headsets. Is this already being looked into? When can an update be expected? Thank you in advance!
MRUK 77.0 LoadSceneFromDevice() Doesn't Work
I just updated my MRUK package from 69 to 77, and now MRUK.LoadSceneFromDevice() doesn't work. It instead logs an error: Error Unity [XR] [OpenXR Meta] xrLocateSpace failed with result XR_ERROR_HANDLE_INVALID Error Unity [XR] [OpenXR Meta] [AnchorProvider] xrLocateSpace request failed with error: XR_ERROR_HANDLE_INVALID I am using the Meta OpenXR plugin. Note that the MRUK MonoBehaviour's checkbox "Load Scene On Startup" does still work. But the problem with this fallback is after my app launches Space Setup and the user completes it, then returns to my app, the new room the user created will not be available. So the user will have to restart my app.Tracked hand pushing away menu (canvas) attached to other hand
I am keeping my left hand almost completely still here in the video demo below, but something pushes the left hand or the menu away when I get the right hand near the other hand/ menu (hard to tell if tracking issue due to other hand being near left hand vs hand interacting with menu or menu item colliders or rigibodies. Video of error in demo Video of unity project setup I have an empty gameobject called 'menu-hand_attatcher' with this script on: using System.Collections; using System.Linq; using UnityEngine; using Oculus.Interaction; // for OVRHand & OVRSkeleton public class AttachMenuToHand : MonoBehaviour { [Tooltip("The disabled Canvas or prefab you want to spawn")] public GameObject menuPrefab; // assign your menu_0 prefab here [Tooltip("Which bone/joint to anchor the menu to")] public OVRSkeleton.BoneId anchorJoint = OVRSkeleton.BoneId.Hand_WristRoot; [Tooltip("Offset from that joint in metres")] public Vector3 localOffset = new Vector3(0f, 0.05f, 0.06f); private OVRHand hand; // we’ll find this automatically private bool attached; private void Awake() { // Auto-find the first active OVRHand in the scene (left or right) hand = FindFirstObjectByType<OVRHand>(); } private IEnumerator Start() { if (hand == null) { Debug.LogError("❌ No OVRHand component found anywhere in the scene!", this); yield break; } // Grab the OVRSkeleton attached to that hand OVRSkeleton skel = hand.GetComponent<OVRSkeleton>(); if (skel == null) { Debug.LogError("❌ OVRHand has no OVRSkeleton component!", this); yield break; } // Wait until the system has tracked the hand & built out all bones while (!hand.IsTracked || skel.Bones.Count == 0) { yield return null; } // Find the specific bone (wrist, index tip, etc.) by BoneId OVRBone targetBone = skel.Bones .FirstOrDefault(b => b.Id == anchorJoint); if (targetBone == null) { Debug.LogError($"❌ Couldn't find bone {anchorJoint} on the skeleton!", this); yield break; } Transform jointTransform = targetBone.Transform; // Spawn or enable the menu prefab GameObject menuInstance = menuPrefab.activeSelf ? menuPrefab : Instantiate(menuPrefab); menuInstance.SetActive(true); menuInstance.transform.SetParent(jointTransform, worldPositionStays: false); menuInstance.transform.localPosition = localOffset; menuInstance.transform.localRotation = Quaternion.identity; attached = true; } private void LateUpdate() { if (attached && Camera.main != null) { // Keep the menu facing the user’s camera transform.LookAt(Camera.main.transform.position, Vector3.up); } } } Anchor joint is set to XR Hand_Start Items in menus have collider + rigidbody (no gravity) to allow acting as trigger It's not so clear in the video but it appears going near the colliders for the buttons freaks it out and flips the menu around, but so does just crossing the right hand over the left (menu anchored to left wrist), or getting it near the canvas. So hard to tell what its interacting with. 1. What can I try using this method I'm already using? (I'm very new to Unity and coding so redoing things or doing them a different way could take me a lot of time and I don't have much) 2. If I were to - is there a better way to do this menu/canvas and hand attachment? Here's my script of my menus using UnityEngine; using UnityEngine.UI; public class MenuNavigator : MonoBehaviour { [Tooltip("Prefab of the submenu to open when this button is poked")] public GameObject submenuPrefab; // debounce flags private bool _hasActivated = false; private bool _ignoreNextTrigger = true; private Transform _canvasRoot; void Awake() { // cache the Canvas transform so we know where our menus live Canvas c = GetComponentInParent<Canvas>(); if (c != null) _canvasRoot = c.transform; else Debug.LogError("[MenuNavigator] No Canvas found!", this); } void OnEnable() { // every time this menu (and its buttons) become active: _ignoreNextTrigger = true; _hasActivated = false; } void OnTriggerEnter(Collider other) { if (_ignoreNextTrigger) return; // ignore the initial overlap if (_hasActivated) return; // and only fire once per exit/enter // 1) Spawn the next submenu prefab under the Canvas if (submenuPrefab != null && _canvasRoot != null) { var newMenu = Instantiate(submenuPrefab, _canvasRoot); newMenu.transform.localPosition = Vector3.zero; newMenu.transform.localRotation = Quaternion.identity; newMenu.transform.localScale = Vector3.one; } else { Debug.LogWarning("[MenuNavigator] Missing submenuPrefab or Canvas!", this); } // 2) Find *your* menu panel: the direct child of the Canvas Transform panel = transform; while (panel != null && panel.parent != _canvasRoot) { panel = panel.parent; } if (panel != null) { Destroy(panel.gameObject); } else { Debug.LogWarning("[MenuNavigator] Couldn't find menu panel root!", this); } _hasActivated = true; } void OnTriggerExit(Collider other) { // 1st exit after spawn turn off ignore, subsequent exits clear the activated flag: if (_ignoreNextTrigger) _ignoreNextTrigger = false; else _hasActivated = false; } } Many thanks :)Passthrough play mode doesn't work since Quest 3 update yesterday
I don't know how long the update was but it was working before the update and now it's not working. Normally I open unity and as long as I have quest link open on the headset and on my pc, clicking play in unity will launch the passthrough app preview on my headset. Now, when I go to launch link on the headset, it begins the colourful loading screen animation and then after a moment says "headset/pc disconnected - please disconnect and disconnect your headset" (or similar. Even though the desktop app shows the header as connective and active, and the quest home settings menu preview shows link as active.
