Problem with SharedSpace and Colocation
I'm currently working on a mixed reality project, the idea is to allow two players who are physically in the same real world space to place objects around the room. Right now I'm working on the multiplayer part of the project. I used a custom script instead of the Building Blocks to connect both users using Photon Fusion and create a room with a code. The problem is that, during testing, the players do not see objects in the same positions. The objects move correctly, but they appear in different locations for each user. To fix this, I started looking into Space Sharing and Colocation so I can ensure both users share the same room alignment and anchors. I started implementing it, but I ran into another problem: I don't seem to be able to test it properly, is the only way to test this with two physical devices? Currently, I'm trying to test using one device and the Unity Editor with XR Simulator. When testing, I can see all the debug logs on the device build. When using the XR Simulator, it does not finish the process of creating the anchor IDs, and if it is running as the client, it never finishes retrieving the anchors either, in both cases, it only shows: "Starts the process..." (<- my debug log) For the Building Blocks, I'm using Passthrough, Shared Spatial Anchor Core, NetworkManager, Platform Init, and Effect Mesh to verify whether both users are sharing the same room.
Add a toggle or remove automatic boundary switching.
I noticed with the most recent firmware updates (yay, they get worse as a new one comes out that keeps breaking my headset), that Meta has literally made my headset unusable for me. Meta, I am disabled. I have issues where I have to take off the headset almost every 10 minutes, and it sucks, really it does. Life is already super hard for me, but what I DON'T need, is for my only source of entertainment, is to come back after a flare up episode of my disability, to find that just because I put my headset down, it switched the boundary from "Roomscale" to "Stationary". Now every single time my disability acts up, I have to take the headset off, deal with my disability, come back, put the headset on, minimize steamlink, go into my settings, turn off stationary and put it back to roomscale (if it lets me because sometimes the stationary boundary gets messed up and only asks me if I want the new stationary circle HERE), then get back into steamlink, only to get motion sick because my boundary changed when I put the headset back on, and once more when switching it back to roomscale, and then have another disability flare up 3 minutes after getting resituated back into VR. You turned my quest pro into a paperweight. I don't know what the hell is going on, but every firmware update after v71 has the quest experience worse an worse, to the point where I can no longer use the headset without it causing an extreme immense of mental anguish. I bought the quest pro to be happy and play games. Not to stress the hell out every time I put it on. Thanks for the $650 paper weight Meta. - A disabled customerUnity – Room creation working on one device but not on another.
I’m currently working on a project using MRUK. It uses room scanning to instantiate walls, floors, ceilings, and so on. The user can place objects in their room. When I test on my device, everything works fine. However, on my friend’s device, it doesn’t work. The objects are not moving and just float in the air. After some debugging, we found that the room was not being created, so there is nowhere for the objects to be placed. I added an effect mesh and immersive debug tools to understand what was happening on my friend’s device. The room is not being created, and the console shows logs like “Room not found,” along with other debug messages I added to check if any room data was being returned from the device. We tried reverting to earlier versions where we are sure everything was working, but the issue persists on his device (mine works fine). This makes me think it could be related to permissions. However, after checking the settings, the app does have permission to access spatial data. We also tried clearing all scanned rooms and spatial data from his device, and even reinstalling the app, but nothing worked. Some additional details that might be relevant: - We are using SideQuest to install the builds - In the latest versions, we added multiplayer using Photon - We tried scanning the room before opening the app, and also triggering a scan from within the app using a button
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 I consistently get: shareLocalScene failed: FailureOperationFailed (-1006) I have already checked the usual setup items. The app is in the Alpha release channel, the App ID is correct, MQDH/device setup looks correct, and spatial data sharing is enabled. 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 Two example anchor IDs mentioned in the failure are: ce6a45dd-d2bd-2115-e2d7-8ec57d8fcd58 9c4d1d9c-7949-392b-c39c-3ca9c3ee1547 I am calling the sample’s local scene-sharing flow from the MRUK room-sharing path, but I also tested a version where I manually built the anchor list from room anchors and child scene anchors. 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? Should the recommended approach be to use only room.ShareRoomAsync(groupId) or mruk.ShareRoomsAsync(mruk.Rooms, groupId) and avoid manual anchor collection? Does error -60001 indicate that the scene anchors need to be recreated or re-persisted before sharing? If helpful, I can also share the exact method I am using and a larger log snippet. Thanks.
Best Method for LBE World Alignment on Quest 3: Shared Spatial Anchors vs QR Calibration?
Hi everyone, We are building a large LBE (Location-Based Entertainment) multiplayer experience on Quest 3 using Unity and Photon Fusion 2. Our play area is around 7.5 × 10 meters. We want to establish a stable, shared world origin across multiple headsets. I’m trying to understand the most reliable method for this and would appreciate clarification on the following: 1. Shared Spatial Anchors Are Shared Spatial Anchors considered the recommended solution for large LBE environments? Is there a clear, up-to-date development workflow or sample project for implementing SSA on Quest 3? 2. QR Codes / Visual Markers Is it technically viable to use QR codes (or similar visual markers) for 100% reliable positional calibration in a 7–10 m play space? Do these marker-based methods maintain accuracy over time for multiplayer alignment? 3. Third-Party Solutions Are there any third-party services or SDKs commonly used in VR arcades or arena-scale setups that provide spatial alignment for Quest devices? I’m looking for the most stable and commonly used approach for syncing the world space across multiple headsets in an LBE scenario. Thanks in advance!
SharedAnchorsFailed
https://github.com/oculus-samples/Unreal-SharedAnchorsSample I packaged this project and set the Appid, then two Quest devices joined the session, created anchors, saved the anchors, and encountered an error when sharing anchors. The error code is 2. My location is China, and I used a VPN. I don't understand what caused the failure to share anchors.Spatial Anchor pose becomes "stuck" and fails to update after device sleep/wake or tracking loss.
I am experiencing a critical issue with Spatial Anchors in my Unity application. When the headset goes to sleep (e.g., by accidentally pressing the power button) or when tracking is temporarily lost (e.g., lights turn off, covering the cameras), the anchor’s pose becomes "stuck" in the last known position/orientation relative to the headset (or the last known coordinate space). Upon waking the device or when tracking resumes (lights turn back on), the anchor does not update its pose to its correct real-world location. It remains locked in the wrong position, essentially frozen in the virtual space relative to the user, rather than staying locked to the physical world. The anchor’s pose only corrects itself if the application is fully restarted and it has been loaded again. I am using Quest3 on v81. Does it need persistent tracking throughout whole session to track anchor? Is there any way to force it to re-localize existing anchor without loading it from shared group again?
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.