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! thanks
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!Need info on Boundary setup in Unreal 5.6
Hello Guys, My app is a mixed reality app and in my app boundary is not required but it looks like with new OS update boundary is a required. I am using Unreal Engine 5.6(Meta fork) . Is it possible for you to provide the steps for: 1) boundary permissions 2) passthrough enable 3) scene api permissions. 4) Hand tracking Please advise. It would be nice if you can provide a sample project. I am using Meta XR v85 plugin. Best regards, Saurabh Saxena
Meta Quest Unity Real Hands Building Block not showing real hands
Hi all! I'm somewhat new to VR development, especially in mixed reality. I am trying to use Meta's Real Hand building block, but I can't seem to get it to work. I have a very basic scene with some of the fundamental building blocks (camera rig, passthrough, passthrough camera access, interaction rig), along with the real hands building block and a single cube. When I build the project to my Quest (Meta Quest 3), and move my hands in front of the cube, I can only see the virtual hands - the occlusion does not work to show my real hands (i.e. it works the same as it did before I added the Real Hands building block). Why is this and how can I fix it? Unity Version: 6000.3.4f1 Meta Quest Packages: Meta XR Core SDK (85.0.0), Meta MR Utility Kit (85.0.0), Meta XR Interaction SDK (85.0.0) Steps to Replicate: Create a new empty scene Add the following building blocks: Camera Rig Passthrough Passthrough Camera Access Interactions Rig Real Hands Add a cube at (0, 0, 3) Build the project and deploy to the Quest Wave your hands in front of the cube - only virtual hands are visible, not real hands
How to make real-world objects appear in front of a virtual environment in Mixed Reality?
I am trying to create a Mixed Reality application in Unity where a virtual environment surrounds the user’s real room, so that the user feels like they are in a different environment while still being inside their real space. I experimented with the SpaceMap sample from the MR Utility Kit: https://github.com/oculus-samples/Unity-MRUtilityKitSample/tree/main/Assets/MRUKSamples/SpaceMap This sample actually does almost exactly what I want. However, I am facing the following issue: Real-world objects, people, and even my own body appear behind the virtual environment objects, so they become invisible. In other words, the virtual environment fully occludes the real world. What I would like to achieve instead is: Real-world objects, people, and my body should appear in front of the virtual environment based on depth. However, the room surfaces (walls, ceiling, and floor) should not occlude the virtual environment. So effectively: Real dynamic objects should appear in front of the virtual world. Static room geometry should not block the virtual environment. From my research, it seems possible to do something like this using opacity or passthrough techniques, but that’s not what I want. I would like the result to feel natural and realistic, without transparent effects. Since this is my first MR application, I might be missing something obvious. If anyone has experience with this or can point me in the right direction (depth APIs, occlusion techniques, or examples), I would really appreciate the help.
OVRCameraRig per-eye camera mode appears to double effective IPD (world scale distortion)
I found what appears to be a stereo geometry bug in Unity when using OVRCameraRig in per-eye camera mode. Sharing this with the community so others can reproduce and verify. Summary With OVRCameraRig per-eye cameras, behavior suggests effective IOD/IPD is being applied twice: Left/right eye transforms are already separated, which is expected for per-eye mode. But the final rendered behavior still looks like additional eye separation is being applied elsewhere. In practice this causes: world appearing too small compressed perceived distances movement gain mismatch versus real-world motion This can persist even when Camera.stereoSeparation = 0, which suggests the extra separation is not only coming from that property. When both per-eye cameras are forced to the center-eye position, with zero horizontal separation, scale and distance perception return to normal while stereopsis remains visible. Testing Environment Unity 6000.3.2f1 LTS Meta XR SDK 85.0 Meta Quest 3 Meta Horizon Link Reproduce Project repo: https://github.com/Danial-Kord/meta-quest-sdk-stereo-ipd-bug Contains: minimal OVRCameraRig setup two behavior-based validation scenes world-space UI and controller tools workaround script: CustomIPDOverride Test A: Dual Iron-Sight Alignment (SampleScene) Two iron sights, one per eye. Adjust horizontal offsets until both sights perceptually align. Measured separation at alignment: Per-eye default: about 12 cm Non-per-eye: about 6 cm Per-eye plus override, cameras centered: about 6 cm This suggests per-eye default behaves like about 2x effective IOD. Test B: Monocular Head-Center Alignment (HeadCenterExperiment) This is a second test independent from dual-sight balancing. Procedure: Align a single iron sight while only one eye is active. Switch to the other eye only. Physically move to align the same sight again. Compare the two saved headset poses. The difference between the two saved headset poses is used as a measure of effective IOD. Compared modes: per-eye mode: about 12 cm after test per-eye plus centered-camera override: about 6 cm after test This provides another alignment-based check of geometry consistency. Interpretation Results suggest per-eye mode in OVRCameraRig may be composing eye separation from more than one source, such as transform offset plus another pipeline stage, yielding doubled effective IOD in default behavior. Possible Fix Direction For per-eye mode, use only one baseline source: Option A Keep per-eye transforms centered and let the internal or native stereo path apply IPD. Option B Use transform offsets of plus or minus IPD/2 and ensure no additional separation is applied downstream. But not both simultaneously. Workaround CustomIPDOverride, my custom camera placement override, hooks into: OVRCameraRig.UpdatedAnchors LateUpdate Application.onBeforeRender It forces anchors from center with a configurable proportion, including zero. In my tests, this restores expected alignment and perceived scale. Request for Reproduction If anyone can reproduce this on other versions or devices, please share results. I can also provide: in-headset videos runtime logs for OVRPlugin.ipd, eye anchor transforms, and camera separation values stripped-down package Links Project repo: https://github.com/Danial-Kord/meta-quest-sdk-stereo-ipd-bug GitHub: https://github.com/Danial-Kord/ Email: danielkordm@gmail.com Our lab: BioMotionLab - Nikolaus Troje | York University Thanks for reading! Let me know your comments on it. Best, Danial KordmodanlouWhy does an MRUK Room sometimes get loaded at an angle?
I'm working on an AR app in Unity which makes used of the global mesh of the room I'm currently in. It seems that on rare occasions the whole room gets created/loaded at an angle. Not a rotation around the up-axis, but an actual tilt. I can easily detect that this happens, but from there on out I seem to be stuck. From what I can tell there is no API to go "hey, please attempt to reload the rooms again". I guess I could reload the scene, triggering a reload of the MRUK prefab, and see if that fixes things, but that's not ideal. So I guess my question is twofold. Is this a known bug/issue? How can I, when I detect this happens, cause a specific room to get "reloaded"? Unity Version: 6000.0.56f1 Current Meta Packages: 81.0.1 (Although the behaviour dates from well before that)
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.
