HMD Unmount is treated as pressing the secondary trigger button
I have an application where an action is started when the user presses the secondary trigger button (the trigger button of the right hand controller). During testing I regularly take of my headset to check Unity's Android Logcat window and I noticed that every time I unmount the HMD a new action starts. So it looks like the unmount event is treated the same as a secondary button press event. I do get a notification every time I start the project that it uses the new Input System (which I never activated, so it must be a reault of upgrading to the latest All in One XR SDK or the sample scenes) and that native backends are not enabled and it asks me if I want to upgrade. I select No, because I remember that the new input system is very complex, so I don't want to take that hit right now. Could it be related to this? Is there an InputAction asset in the Meta SDKs? or in the Interaction SDK Samples? I can't seem to find it in the project window. Or is this a bug? Unity 2023.2.22 Meta XR All in One SDK 201.0.0 Meta Interaction SDK samples - Example Scenes
Horizon OS v2.4 breaks hand far-interaction in all OpenXR Unity apps
Posting here to surface a regression that's affecting our production app on the Meta Horizon Store and appears to be hitting the broader OpenXR ecosystem on Quest 3. SUMMARY Since Horizon OS v2.4 rolled out (week of 18 May 2026), the Meta Aim Hand OpenXR extension (XR_FB_hand_tracking_aim) returns a stuck/invalid aim pose. Any Unity app reading pose from the MetaAimHand input device (via com.unity.xr.hands) loses hand far-interaction: the ray is stuck pointing forward, and the grab interaction range tied to the ray is also affected. Reproduces in the Unity Hub VR template project as well as in our production apps WHAT'S RULED OUT - System-level hand tracking is healthy: works in Quest Home, 2D system apps, and via XR_EXT_hand_tracking joint data inside the app itself (near interaction with hands continues to work). - Our MRTK-based sister app, which derives its hand ray from joints rather than from the Aim extension, is unaffected — confirming the breakage is scoped specifically to XR_FB_hand_tracking_aim. - The latest Meta XR Core SDK / Interaction SDK (v201.0, April 15) and Unity's com.unity.xr.hands (1.6.0-pre.3) and com.unity.xr.meta-openxr (2.6.0-pre.1) all predate the v2.4 rollout — no upstream SDK fix available to update to. - The Hand Interaction Profile workaround restores a ray but with pinch detection too sensitive for production use, which makes it unviable for medical/clinical content. VIABLE MITIGATIONS FOR SHIPPING APPS Falling back to controllers, or computing a custom aim pose from XR_EXT_hand_tracking joints directly (bypassing MetaAimHand entirely). ALSO REPORTED - Unity Discussions: https://discussions.unity.com/t/quest-3-openxr-hand-tracking-no-longer-works-after-2-4-update/1721513 - Filed on Meta Feedback Center (Inputs → Hand Tracking) for engineering tracking. ASK Confirmation this is on Meta's radar, ETA on a Horizon OS hotfix or an SDK-level workaround, and any guidance for affected apps shipping today. Happy to provide additional repro details or logs (privately) if useful.How do I access the meta quest device name or id
Hi! Hopefully someone has solved this problem - I'm looking to log some information to a cloud database and I need to access and log the device Id. The ID I'm looking for isn't accessed via "SystemInfo.deviceUniqueIdentifier", nor is it SystemInfo.deviceModel, deviceName, or deviceType. The ID I'm looking for is the same ID that shows up in the Meta Horizon Managed Services devices list. It's a 14 digit device Id like "1WMHH6666V0335". I'm looking to access this Id in Unity. Can someone tell me what property I'm looking for? I think this might be the SERIAL number. Thanks for your time!
Hand tracking no longer works on 2.4
After my headset decided to update itself to 2.4 my hand tracking no longer functions in my OpenXR app. I'm using Unity and the Meta Aim Hand OpenXR feature and the ray is stuck permanently straight. Moving my hand doesn't move my ray in any meaningful way and I can no longer select objects. Here is a video from the built in unity VR sample with no edits made. https://streamable.com/r230zu How did this ever get promoted from PTC? What do I do to fix this? Picking up a controller to do actions in my app that is primarily hand tracked is not a solution.
Meta quest 3 scanner breaks
Hello! I have a Unity project for Meta Quest 3 that uses MRUK. The app starts in a room, but I have "Load Scene on Startup" disabled in MRUK, and I don’t call LoadSceneFromDevice until the user is in the room where the scan was created. The problem is that sometimes the room scan breaks randomly for no apparent reason. What can I do? Since I need to start the app in a different room, should I create and store multiple rooms so the system knows where it is? For example, having two rooms saved and letting it detect which one it’s in. Should I start with the quest cameras covered so it doesn’t try to recognize the space until the user is in the correct room, hoping it will recognize it immediately. Is this the right approach? Thanks, this apk is for a restaurant, where the waiters start the aplication in a room, go to another (where is the scaned room) and gives them to the customers, and the experience start and they don't live the room.apriltag setup for quest 3
Hello I am working out how to crate an Apriltag system on my quest3 with unity. id like to play with mesh objects that I crate in Rhino, and would like to place them in the AR. I want to place tags so I can find my objects back later on. In my set up I have a button to pin the object and one to reposition the object. At the moment I did not succeded yet to project an object onto the tag. very fruatrating pherhaps I missing something. anyone who can help would be great! thanks
Cannot set Meta Quest Link as active OpenXR runtime normally
Hello! We are developing a PC-VR app in Unity with Meta Quest 3 at our company. We use OpenXR plugin to build the code around OpenXR standard in order to support more platforms in the future. However, the button to set the meta quest link as active runtime for open xr never works on our test PCs. We've tested multiple laptops & PCs in the companies and none of them seem to be work without us manually setting the path in the registry. We've tried starting the Link app as an admin, installed it as an admin etc. One time the registry entry doesn't even get added automatically after installing Meta Quest Link App and we had to install "OpenXR for Windows Mixed Reality" to create it without writing a script to automatically create the group entry ("HKLM\Software\Khronos\OpenXR\1") in the registry. Could anyone help clarify what is up with this case and how we can resolve it? Otherwise the setup process is basically impossible for our potential customers without in-depth technical support... Thank you! References: https://community.khronos.org/t/openxr-directory-not-existing/111184
Quest standby breaks OVRCanvasMeshRenderer punch-hole UI tracking. Timewarp offset on wake-up.
Hello everyone, I'm currently facing a persistent issue regarding OVRCanvasMeshRenderer in my Unity project for Meta Quest. The setup: Engine: Unity (using Universal Render Pipeline) SDK: Meta XR All-in-One Version 201 Unity: 6.0 (6000.0.63f1) Features: Using Meta's punch-hole / underlay technology to render high-quality UI over the scene via OVRCanvasMeshRenderer. The problem: Everything works perfectly when launching the app. However, if the user puts the Meta Quest headset into standby/sleep mode and then wakes it up to resume the application, the UI canvas suffers from a noticeable positional offset (displacement). It seems like the projection matrices or the underlying render textures do not resynchronize correctly with the updated tracking data when the application regains focus. The Canvas appears detached or lags behind the head movement. What I've tried: Disabling and re-enabling the OVRCanvasMeshRenderer component upon OnApplicationFocus(true) / OnApplicationPause(false). Introducing a small delay (WaitForSecondsRealtime) before re-enabling to let the tracking stabilize. Forcing an OVRManager.display.RecenterPose(). The displacement still occurs or requires a hard restart of the app to fix completely. Has anyone encountered this specific bug with OVRCanvasMeshRenderer or Any OVR features after standby? Is there a known workaround or a specific lifecycle method we should call to force-refresh Meta's punch-hole rendering system upon resume? Thanks in advance for your help!
Sudden Loss of Body Tracking & Crashes with Unity Movement SDK (Quest 3) since version 2.3 update
Hi everyone, I am experiencing a critical issue with the Unity Movement SDK on the Meta Quest 3, and I've noticed a few other developers mentioning the exact same problem recently. My project relies heavily on the Movement SDK, and it was working perfectly fine up until recently (around April 29th/30th). Suddenly, body tracking has completely stopped working. Here are the specific symptoms and the troubleshooting steps I've already taken: Persistent Crashes: The project now crashes consistently when hitting Play in the Unity Editor. It also crashes when I build and run it directly on the Quest 3. Older Builds Failing: I initially thought I broke something during a project update, but when I tested older, previously stable builds that had perfectly working body tracking, they also failed. My Setup: Device: Meta Quest 3 (Version 2.3.1034) Software: Meta Horizon Link (Version 201.0.0.73.547) Because older, untouched builds are now failing, this strongly suggests a bug or breaking change introduced in a recent Meta Horizon Link or Quest OS update rather than an issue within Unity itself. Is this a known issue currently being looked into by the Meta team? If anyone has found a temporary fix or workaround, please let me know. Any help is appreciated. Many thanks!!
