next gen full body tracking using native wifi drivers
i want to propose a hybrid tracking system using sensor fusion instead of wifi working alone it would complement the quest cameras the cameras track the upper body while the wifi csi data fills the blind spots for the lower body and legs this solves the messy data problem because the system already has the headset and controllers as a base meta could add a toggle for full body tracking or upper body only to save battery it would be an optional feature powered by a low level system driver what do you think about this integration with the current movement sdkExploring Body Tracking via Wi-Fi CSI – A Newbie's Proposal
Hi everyone! I’m new here in the community and I’ve been diving deep into how we can push the boundaries of standalone VR tracking. As a fan of the Quest ecosystem, I’ve been thinking about a challenge we all know: tracking parts of the body that are out of the cameras' line of sight. I’ve been researching Wi-Fi CSI (Channel State Information) and was wondering if we could use the wireless signal already present in the headset to help with body tracking. Since Wi-Fi signals are affected by human movement (even through walls or behind the back), could this data be used to complement the existing IMU and optical tracking? The idea would be to use the CSI amplitude and phase changes as a secondary data layer to "guess" limb positions when the cameras can't see them. I know it’s a technical challenge, but I’d love to hear from more experienced devs here: Does the current Quest hardware allow low-level access to CSI data for this kind of processing? Could this be a viable way to achieve "Full Body Tracking" without external sensors in the future? I'm just starting to develop this concept and would appreciate any feedback or pointers to existing documentation! Best regards, Vinícius (Jurusbango)Proposta: Rastreamento Corporal Total via Wi-Fi
Subject: Proposal: WiFi-based Full Body Tracking using CSI (Channel State Information) Message: Hi Meta Dev Team, I would like to propose a feature that could revolutionize body tracking on Meta Quest headsets without requiring external trackers or extra cameras: WiFi-based Motion Sensing using CSI (Channel State Information). The Concept: Every time a person moves between a WiFi transmitter (router) and a receiver (Quest), the signal undergoes phase and amplitude distortions. By accessing the CSI data from the Quest’s WiFi chipset, we can analyze these signal patterns to identify body posture and movement in real-time. Technical Implementation: Signal Analysis: Utilize the 5GHz/6GHz signal fluctuations to map the user's silhouette and limb positions. Machine Learning Integration: Use a lightweight neural network to translate CSI "shadows" into skeletal data, similar to how researchers have successfully used WiFi for "through-wall" sensing. Hybrid Tracking: Combine this WiFi data with the existing Inside-Out tracking and IMU data to fill in the gaps when the controllers or legs are out of the cameras' field of view. Why this is a game-changer: Zero Cost for the User: No need for Vive trackers or Tundra trackers. Privacy: It doesn't rely on optical images of the room, just radio frequency patterns. Lower Latency: Direct processing of signal data can be extremely fast on modern SOCs. I believe this would make Full Body Tracking accessible to everyone and put the Quest even further ahead in the VR market. Best regards, Vinícius🏗️ Building Smarter, Not Harder: Modular Asset Design for VR
Learn how to create reusable 3D assets that snap together to build full environments faster, cleaner, and optimized for VR. In this session, MHCP Mentor and Creator Jelitza Cintron walks through a modular approach to environment art. Instead of building assets one by one, you'll learn how to design a small set of reusable pieces that work together to build entire spaces quickly and efficiently. What you'll walk away with: Grid and scale systems for designing modular assets that snap together cleanly A reusable asset kit approach so you can build larger environments from a small set of pieces Performance-aware workflows that keep your environments efficient for VR Join on Zoom
[Audit] OS 2.1 Nav Bar: AOSP Java Implementation & The Sideloading Paradox
As a Web/Multimedia Developer (B.A. Comm), I am formally auditing the persistent UI limitations in OS 2.1. Meta continues to treat the Global Navigation Bar and System Menus as a static kiosk interface. The AOSP / Java Reality The Navigator is a View group within a Java-based AOSP (Android Open Source Project) framework. There is zero architectural excuse for failing to implement transparency (alpha) and color customization. If the community can port Quake to HTML5, Meta's engineering team can certainly implement a basic slider for the UI layer. The Sideloading Paradox The claim that UI customization is "too complex" for users is logically inconsistent. A significant portion of this community is already using ADB (Android Debug Bridge) and Sideloading to bypass these restrictions. If a user has the technical literacy to sideload an APK, they are more than capable of using a native hex-code color picker or a transparency toggle. Figure-Ground and Accessibility By hard-coding Elevation and Ambient/Key shadows without user-definable variables, Meta has created a permanent Figure-Ground failure. A professional-grade OS requires user-defined transparency to ensure visual accessibility. Conclusion: We are developers and owners, not tenants. Meta needs to stop gatekeeping basic UI variables. Implement the alpha sliders for the Navigation Bar and Menu.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.
Conflicting Information in the Horizon OS SBC (Shader Binary Cache) Documentation?
In the documentation regarding building a shader binary cache per-platform (link) the documentation states: Using this feature, once one user starts the app and manually builds the SBC, all other users with the same device and software (Horizon OS, graphics driver, and app) will be able to avoid the shader generation process by downloading a copy of a pre-computed SBC. However, later on the same page, it states there is an automation in place to launch the apps and perform scripted prewarming logic if requested. The system automatically identifies and processes Oculus OS builds and app versions that require shader cache assets. It generates and uploads these assets to the store backend and automatically installs them during an app install or update. Does this feature support both of those setups? If I am not scripting any custom warmup logic, will shader binary caches still be shared between users with identical setups? IE, if I simply play the release candidate on the target OS version/hardware, will my SBC be automatically uploaded, or are SBCs only distributed when a scripted warmup sequence is present? Few details are provided regarding SBCs from other users being uploaded, so I'm curious if this is an inaccuracy or not. Thanks, excited to see features like this in Horizon OS. Very important for first time user experience.Unity WebRTC stream from iOS companion app → Quest headset connects but displays black frames
Hello everyone, My name is Mason. I’m a graduate student at Kennesaw State University and a Research Engineer working in XR environments through my Graduate Research Assistant role. I’m currently building a research prototype that connects a mobile companion application to a VR headset so that a VR user can view media stored on their phone inside a VR environment. The system uses a Unity-based mobile application to stream video frames to a Unity-based VR application using WebRTC Environment Sender Device: iPhone 15 OS: iOS 26.3 Engine: Unity 6000.3.8f1 (Unity 6.3) Graphics API: Metal Receiver Device: Meta Quest Pro headset (Unity application) Streaming Technology: Unity WebRTC package Architecture Mobile Unity app acts as the WebRTC sender Quest Unity app acts as the WebRTC receiver Connection established over LAN UDP used for discovery TCP used for signaling Video Source: Unity RenderTexture Goal The goal of the system is to allow a VR user to browse and view media stored on their phone inside a VR environment. The pipeline currently works as follows: The mobile Unity app renders media content to a RenderTexture The RenderTexture is used to create a WebRTC video track The video track is streamed to the headset The Quest app receives the track and displays it on a surface inside the VR scene Current Status Connection setup appears to work correctly. Observed behavior: Discovery between devices works Signaling connection succeeds ICE candidates exchange successfully PeerConnection state becomes Connected Video track is created and negotiated However, the Quest application displays only black frames. Sender (iOS) Behavior Inside the phone application, the RenderTexture displays correctly and the scene renders normally. Frames appear correct locally inside the Unity scene. Despite this, the Quest receiver does not display the frames. Receiver (Quest) Behavior On the Quest side, the WebRTC connection establishes successfully and the video track appears active. The video texture updates, but the displayed output is completely black. Expected Behavior The frames rendered on the phone should appear in the VR scene on the Quest headset. Actual Behavior The WebRTC connection works, but the Quest receiver only shows black frames. Things I Am Investigating Unity WebRTC compatibility with Unity 6.3 Metal texture capture limitations on iOS RenderTexture pixel format compatibility GPU readback or synchronization issues Differences between desktop Unity WebRTC streaming and iOS streaming Questions Has anyone successfully streamed Unity RenderTextures from iOS to Quest using WebRTC Are there known compatibility issues with Metal-based textures being used as WebRTC sources? Are there specific RenderTexture formats or texture types required for WebRTC on Quest Could this behavior indicate a GPU synchronization or pixel format issue? I can provide Unity console logs, WebRTC negotiation logs, screenshots of sender and receiver output, RenderTexture configuration, and minimal code snippets if needed. If anyone has experience building mobile-to-Quest streaming pipelines or using WebRTC in XR applications, I would greatly appreciate any guidance. Thank you for your time.
Glitchy rendering on certain camera angles
This bug only appears in device build and on certain camera angles. Sometimes when the player looks up or when the controllers are out of the camera frame. I have used the default VR Controller from UnityXR Toolkit and this glitch doesnt show. I am currently using the prefab controller for pose detection scene and added the locomotion prefab to add movements. I am using URP for my project. What I've tried: - Removed the tunneling vignette object from the controller because maybe its conflicting with the rendering - Adjusted near and far clippings of left,center, and right cameras - Played with XR settings Single Pass Instanced / Multiview Unity Version: 6000.3.3f1
Question about unexpected 16:9 thumbnails shown in Meta Air Link (Steam app, Unity)
Hello, I am trying to identify the source file or mechanism used for the thumbnails displayed in Meta Quest Air Link, as I am seeing unintended images. Issue description When I start Air Link on Meta Quest and open Steam on the PC, the following thumbnails are displayed: The thumbnail shown when Steam appears in Air Link The 16:9 thumbnails shown in the Library / Apps view after launch In both cases, the thumbnails displayed are not the images I expect. Application setup The application is launched from Steam on the PC Rendering is done via Air Link The application is not registered as a Meta (Oculus) app The application is not registered via OpenVR / SteamVR .vrmanifest The application is developed using Unity What I want to understand I am not trying to customize the thumbnail at this stage. I want to accurately identify where these thumbnails are coming from. Specifically: Which file or resource is used as the source of the thumbnail shown in Air Link? Executable icon Windows window thumbnail (DWM) Steam library image Meta Quest Link internal cache Other mechanism Are the thumbnails generated dynamically from a running window, or loaded from a static image file? Is there any documentation describing how Air Link selects these thumbnails for Steam-launched applications? Any clarification on how Air Link determines and displays these thumbnails would be greatly appreciated. Thank you for your time.
