A messenger for exchanging passthrough modes between two Oculus Quest 3 headsets
Good day, everyone! I'm working on a project aimed at implementing virtual body swapping using standalone VR headsets. I want to stream the video from the see-through cameras from one headset to another. The problem lies in API access restrictions and processing video with depth data so it looks like the headset's native see-through channel. Ideally, the system application that renders the see-through image captures the camera video and the LIDAR data from the headset. We cannot directly transmit the finished image to another headset. If we use the API, the image will be cropped, according to the documentation, and we'd need to write the rendering algorithm ourselves, as simple flat stereo video doesn't provide immersion. My idea is this: we can transmit the see-through camera and LIDAR data over the network to another headset and trick the second headset's system application into capturing this data from the other headset instead of its own, processing it the same way it processes its own data, and creating a full-fledged see-through mode based on this data. Is it possible at all for a developer to gain access to this system application to adapt it for the messenger's tasks?
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! thanksBroken Quest 3S Cameras
My Meta Quest 3S (SN: 340YC10G8N0PVR) has suffered a total hardware failure. The device is stuck on a permanent Black Screen, and the controllers have entered an Infinite Rumble loop that does not stop. I have already performed the 'Last Resort' Factory Reset, but the hardware remains unresponsive. The Tracking Service has failed entirely, and even the Gaze Dot has disappeared from the display. I have also attempted to boot from both Slot A and Slot B, but the 'Blind Setup' wall persists due to the physical failure of the tracking cameras. Since a full system wipe (Factory Reset) did not resolve the issue, this is clearly a hardware-level defect. I am requesting an immediate warranty replacement to Meta so I can restore my data and return to the Metaverse.
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 sdk
Unity-SpaceSharing sample fails with shareLocalScene failed: FailureOperationFailed (-1006)
Hi, I am trying to use the Unity-SpaceSharing sample: https://github.com/oculus-samples/Unity-SpaceSharing What I’m seeing in the logs is: Repeated local anchor read failures with error -60001 Then shareSpatialEntity failed with GraphQLError code=2128008 A server message saying some anchors could not be found in the cloud by ID Also, Mesh upload through cloudAnchorService is not supported My questions are: Is FailureOperationFailed (-1006) usually caused by anchors not being uploaded or not being available in the cloud yet? Is there a known issue in the sample where sharing a manually collected anchor list can include unsupported scene or mesh anchors?Bug Report MRUK 83.0.4 -> 85.0.0 _cameraAccess.GetCameraPose() bad
It looks like you shifted from "headpos" to "camera.main" in everything. But... _cameraAccess.GetCameraPose() is still using HeadPos which... was somewhere near my chest? To reproduce: Take CameraKit demonstration for QR codes. Run with 83.0.4 in an unmapped space. Works fine, the green quad covers/is close to the QR code. Now copy/paste the code/objects into a newly set up 6003.9f1 project with MRUK85.0.0. Run again in an unmapped space. The QR is off. The green quad is someplace else. if you put tracers and debug flavor in, you will find that -- at least Y is ~34 cm off (look at CP)... Debug Spice: private static Ray BuildWorldRay(QrCodeResult result, Vector2 uv) { var viewport = ToViewport(uv); var intrinsics = result.Intrinsics; var sensorResolution = (Vector2)intrinsics.SensorResolution; var currentResolution = (Vector2)result.captureResolution; if (currentResolution == Vector2.zero) { currentResolution = sensorResolution; } var crop = ComputeSensorCrop(sensorResolution, currentResolution); Debug.Log($"V {viewport} "); Debug.Log($"I -{intrinsics.PrincipalPoint} - {intrinsics.FocalLength} "); Debug.Log($"C {crop}"); var sensorPoint = new Vector2( crop.x + crop.width * viewport.x, crop.y + crop.height * viewport.y); Debug.Log($"S {sensorPoint}"); var localDirection = new Vector3( (sensorPoint.x - intrinsics.PrincipalPoint.x) / intrinsics.FocalLength.x, (sensorPoint.y - intrinsics.PrincipalPoint.y) / intrinsics.FocalLength.y, 1f).normalized; Debug.Log($"CP {result.cameraPose.position} R{result.cameraPose.rotation}"); var worldDirection = result.cameraPose.rotation * localDirection; return new Ray(result.cameraPose.position, worldDirection); } To Fix: private async Task<CaptureFrame?> AcquireFrameAsync() { while (true) { if (_cameraAccess && _cameraAccess.IsPlaying) { var texture = _cameraAccess.GetTexture(); if (texture) { return new CaptureFrame { Texture = texture, Pose = TMJGetCameraPose(), //_cameraAccess.GetCameraPose() is off... Intrinsics = _cameraAccess.Intrinsics, Resolution = _cameraAccess.CurrentResolution }; } } await Task.Delay(1000/fps); //16=60fps } } private Pose TMJGetCameraPose() { var headPose = new Pose(_cmain.transform.position, _cmain.transform.rotation); // Apply VisionKit lens offset in head-local space Vector3 cameraPos = headPose.position + headPose.rotation * _cameraAccess.Intrinsics.LensOffset.position; Quaternion cameraRot = headPose.rotation * _cameraAccess.Intrinsics.LensOffset.rotation; // 4. Compose final camera pose return new Pose(cameraPos, cameraRot); } And in Start(), _cmain = Camera.main(); Result: Now the green quad is in the same place as it was in the Example code that uses 83.0.4 Yay!
Passthrough Camera Access in Unreal Engine
I am on the latest version of the Meta Fork of UE5 (5.6.1-v83) and I'm trying to access passthrough camera images, but I cannot for the life of me manage to do that. I think it only works in a standalone build on the Quest (I have a Quest 3), right? Passthrough works in the MR Sample project (I'm having some priority/stencil issues, but that's not the point). I tried the `ConstructTexture2D` node from the passthrough camera access subsystem and also the `getARTexture` node, but nothing works. I can't find any simple guide or documentation on this. Help, please.New update unable to take inputs?
I've been developing a Unity-based game that takes piano MIDI input from a physical piano and funnels it through my computer and quest-changing overlays, but ever since the new Meta Link quest update, my inputs have stopped working in multiple versions of my game. Is there a fix anyone can provide, or can I'm able to roll back updates from the quest?Passthrough randomly disables during runtime
UE 5.5.4. Meta XR plugin v78. I have an apk that I sideload onto several headsets. The app works fine while connected to my laptop for development. Never an issue. The packaged apk works fine on the headsets during testing. Seems solid. But then I'll launch the app and hand out 10+ headsets to the customers, and they walk around for a while, eventually some of the headsets lose passthrough. The app is still running and tracking. You can see the virtual objects, but they are on the field of black. You can't see and of the surroundings. Double-tapping the side of the headset simply pauses the app and takes me to the menu. I can't get passthrough working again once this happens. I added blueprint code that every 10 seconds checks if the passthrough object is null and, if so, initialize another passthrough, but that didn't help. I've fired up 10 headsets let them run and walked around the room holding several of them, grabbing them all over the headsets (in case the customers are pressing some button), but I can't get the passthrough to stop working. Hence why I don't have a log file to attach. I'm at a loss what could be happening and how to recreate the issue. Any help or suggestions would be appreciated.
Request: WebXR Raw Camera Access (camera-access feature) in Quest Browser
Hi Meta team, I'm building a WebXR mixed reality application on Quest 3 that uses computer vision to annotate real-world objects in AR — think floating info panels anchored to products on a store shelf, triggered by voice commands. The app uses Three.js + React-three/xr and connects to backend AI services for object detection and enrichment. The missing piece is camera-access. When I request it: ``` navigator.xr.requestSession('immersive-ar', { requiredFeatures: ['camera-access'] }); ``` The session is rejected with: `Feature 'camera-access' is not supported for mode: immersive-ar` This is on Quest 3 running Horizon OS v85, Quest Browser latest. Why this matters for WebXR: The Passthrough Camera API is already available on native platforms (Unity, Unreal, Android) since v76. Bringing it to WebXR would unlock a category of browser-based MR apps that currently require a full native build pipeline — real-time object detection, visual search, accessibility overlays, educational AR, and more. WebXR's strength is zero-install, share-a-link distribution. Pairing that with camera access would make Quest 3 a much more compelling platform for MR web apps. Current workaround: I'm using getUserMedia as a fallback to capture camera frames, which works but loses the per-eye reprojected textures, pose-aligned intrinsics, and the tighter integration that the Raw Camera Access spec provides. The app is architected to switch to camera-access the moment it's available— no code changes needed on my side. My request: Is there a timeline for camera-access support in the Quest Browser? The https://immersive-web.github.io/raw-camera-access/ is defined, Chrome has supported it since r107, and the native Passthrough Camera API is already shipping. Would love to know if this is on the roadmap. Thanks for all the work on WebXR support — hit-test, hand tracking, plane detection, and anchors have been great to work with.
