OS freeze every 60 seconds with hand + body tracking
Not sure if this is the best place or if there's a support place for devs, it is hard to keep track of where best to bring these things up. Anywhoo. Spent that last 2 days tracking this down thinking it was me. But, if you are on the latest OS, in the Meta Home, with hand tracking enabled, and you flail your hands around like a madman, doing "the wave" with your fingers, alternating with making fists and being the worlds fastest drummer, you'll get a little spike, like clockwork, every 60 seconds. May seem a bit much, but my app is a dance game that uses hand and body tracking and makes use of the new fast hand and body tracking that, apart from this issue, is fantastic. It is not a huge spike, but it freezes the entire OS and so in game that translate to a little hitch in the visuals and in the music and the music hiccup is super noticeable. And it is like clockwork every 60 seconds. Though, sometimes it takes 60+ seconds for the first one. It makes my game feel unprofessional :( With hand tracking disabled, the spike does not show up. If you have hand tracking enabled but you don't move your hands much, it does not show up. I did figure out one thing though. I've got a little timer that every 20 seconds requests that fast tracking support be disabled for 10 frames, then turn it back on again. The user won't notice that tracking isn't quite as fast for 10 frames and it seems to reduce the spike about 80%, but even that 20% is noticeable and who knows how long that hack will work, an OS fix would be better. Wondering if anybody else is running into this, any other hacks I could try, and a "we're on it" from Meta or a "file this over here" would be my preferred responses :) Thanks in advance for any and all replies, DamonMetaXRInteraction missing Ray visuals for ISDKControllers, but ISDKHands working as intended.
I recently upgraded to the version 1.81.0 of MetaXRInteraction on the Oculus Unreal engine fork. Version 5.6.1 And the controller components don't have ray visuals when interacting with menus. The functionality works, I can click, and elements change when hovered, but it's hard to aim. What's weird, is that the ISDKHand components, do have proper ray visuals. (Expect for the right reticle not getting blue when pinching) I am not sure what is broken, or how to get this working. All parameters are defaults. And I only turn off/on the Ray and Grab components (for both ISDK Hands and ISDK Controllers) when the user selects a hand preference in settings using the Set Active function. Video demonstrating the issue. https://drive.google.com/file/d/1GZB-dCXpaxryZP92I9jXAnZO34Lg9WHP/view?usp=sharing Thanks!
The Navigator Identity Crisis: A Call for Design Sovereignty and Customization.
To the Meta Design Team, you are making your device worse by trying to be someone else. Meta was the leader because you were the ones who actually figured out how to make standalone VR functional and accessible in the first place. For you to throw away the very leadership you built just to become a knock-off version of Apple is a total failure of vision. You didn’t need to reinvent the wheel, you just needed to polish it. Instead, you’ve scrapped a great, functional interface for a filtered version of the Vision Pro. By forcing the Navigator into a rigid, head-locked position, you’ve sacrificed user sovereignty for a spatial look that you don't even have the eye-tracking hardware to support on your current mainstream headsets. Even if your next device has that hardware, the millions of people using your hardware right now shouldn't be forced into a "look-to-lock" logic that makes the system feel broken. Taking away the ability to freely grab and park windows, forcing us to re-center our entire world just to move a menu is a massive UI/UX regression that makes the system feel less capable and more restrictive. This interface feels like it was designed by geeks who prioritize clean code and data structures over how a human being actually moves their hands and head in a room. Mark Zuckerberg started with a site that was nothing but white backgrounds and blue text a bland, sterile database and that same nerd logic has now infected the Quest. A nerd designs a menu based on where it’s easy for the code to sit; a designer or a real user needs it where their hand naturally wants to reach. Your current interface is the definition of mayonnaise tech: bland, sterile, and corporate. You finally made the Navigator transparent, but you stopped halfway. Transparency isn't just a style choice; it’s a mechanical need in a spatial environment. Why are the store, the menus, and the sub-folders still stuck in these solid gray and white blocks? Every single window should be transparent by default. This is the obvious direction for the medium, yet you're forcing us into light versus dark folders instead of just providing opacity sliders. Users need the ability to choose if they want to block the world out or let their room shine through. It is 2026, so being stuck with gray and white as our only options is a joke. A simple color wheel for the UI would allow for a green aura, a blue glow, or custom highlights for menus. A transparent green theme should be a simple slider adjustment, not a corporate mandate. You already had a winning format with the original Quest interface. You didn't need to scrap it; you just needed to make it transparent and give us the tools to move it. You need to restore the "grab-to-slide" logic so we can orbit windows 360 degrees and park them to our left or right without the system fighting us. Stop trying to look fashionable through imitation. You built your success on utility and being the original in the standalone space, don't throw that away to be a second rate copy of a competitor. Give us back the original soul of the Quest, enhanced with the transparency and the customization that this technology actually demands.Meta Interaction SDK Version Mismatch in UE 5.7.4 (Requires MetaXR 1.233.0 but found 1.201.0)
I am currently working on a VR project using Unreal Engine 5.7.4 and am running into a version mismatch error between the Meta Interaction SDK and the Meta XR Plugin. The Issue: Upon launching the editor, I receive the following warning: “Meta Interaction SDK version '1.201.0' (v201) requires MetaXR Version '1.233.0' (v201) but found '1.201.0' (v169). Mismatched versions may result in unexpected behavior.” Current Setup: Engine Version: Unreal Engine 5.7.4 (Epic Games Launcher) Meta Interaction SDK: Version 1.201.0 Meta XR Plugin: Version 1.201.0 (reported as v169 by the engine/plugin) Despite both plugins showing as Version 1.201.0 in the Unreal Engine Plugins window, the Interaction SDK specifically requests Version 1.233.0 of the Meta XR plugin to maintain compatibility. Troubleshooting Steps Taken: Verified that both plugins are enabled in the Installed > Virtual Reality section. Updated DefaultBuildSettings to BuildSettingsVersion.V6 and IncludeOrderVersion to EngineIncludeOrderVersion.Latest in my .Target.cs files to ensure they align with UE 5.7 requirements. Attempted to find a standalone download for Meta XR 1.233.0, but the current Meta developer downloads page appears to package them differently. Any help or guidance on how to resolve this version discrepancy so I can utilize the Interaction SDK features safely would be greatly appreciated. Thank you!
Accessing controller input in Meta Quest system UI overlays from custom Android-based engine?
We are building a custom engine on top of Android (using the SDK and Gradle, not Unity or Unreal) porting our products and targeting Meta Quest devices (Quest 3 specifically) for the 2D System panels / overlays (the floating windows in the Quest home environment): What we want: We need to capture *any form of controller input* (buttons, joystick, scroll) while the apps system UI panels are visible or focused. Key constraints: We are not trying to modify system UI, only observe or intercept input Even partial input (e.g. scroll events, pointer movement, or indirect signals) would be sufficient What we’ve tried: Standard Android input APIs (onKeyDown, onGenericMotionEvent) Checking for MotionEvent sources from controllers Polling input devices directly Combed through the SDK without luck Is there any supported way (SDK, API, or lower-level approach) to access or intercept controller input when system UI overlays are active on Meta Quest? Any guidance on how input routing works between apps and system UI on Quest would be helpful.
Record and replay real hand pose at runtime (Meta Interaction SDK – Unreal)
Hi everyone, I’m currently working with the Meta Interaction SDK in Unreal Engine (UE 5.6) and using hand tracking only (no controllers). I’m using the ISDK Hand Rig Component for both hands. What I’m trying to achieve is: I want to capture the user’s real hand pose at runtime, save that pose, and then reapply (replay) that exact pose later on command. So, basically my requirement is, Is there a built-in way in Meta Interaction SDK to record and replay hand poses ? What’s the best way to temporarily override hand tracking and apply a custom pose? Any guidance, suggestions, or pointers would be really helpful. help in any way you can. Thanks.Is there a way to make the player not see their own avatar
Hello, I am building a Unity Project with Meta All-In-One SDK and I'm using the Networked Avatar Building Block on top of Matchmaking and Hand Tracking and Passthrough to create an experience where users can see other avatars with their hand movements with Passthrough in the real world , this creates an effect where you can see people walking around, talking and interacting with things in a room that they are not physically in with passthrough. My issue with this is the fact that the player (host) can see other players' Avatar and other players can see the host's avatar but when the host themselves also look down they also see their own avatar arms connected to their hands and body. I do not really want this Is there way for the player to just see their normal hand prefabs/meshes from their perspective while other connected players see the full avatar and vice versa?
