I am having some issues with the networking coordinate system.
I would like to exclude some objects on the peer device from the host’s coordinate system, or be able peers to join a multiplayer session but not use the host’s coordinate system.
I this possible in the current SDK?
I searched the documents but couldn’t find any information.
For example I might want users to place objects before joining a multiplayer session and have their objects remain in their original position (at the moment they will jump to a new position on sync)
The documents state:
However, upon completing localization, the positions of all non-host devices will “move” to new positions corresponding to their relative locations on the host’s coordinate system. At this point, all clients are using the same coordinate system (the host’s), and placing a virtual object at position (X, Y, Z) will look the same for everyone in the real world as well.
I would like to disable this in some situations or for specific objects
Those are excellent questions, and seem like an interesting use case for AR multiplayer game design. I’ve been researching an answer for your questions, and have reached out to engineering for clarification on a couple topics. Thank you for your patience, I’ll let you know as soon as I have a possible resolution to this issue.
Peer objects spawned before they are synced will not be positioned correctly after they sync with the host. After syncing, we apply a transform to each peer’s local position before surfacing it to Unity, and don’t re-apply that transform to any Unity gameobjects. So they will forever be offset by whatever the differences are between the host and peer spaces. It is recommended to spawn or reset shared gameobjects (and things like the ARMesh) after the peer is synchronized.
We are, however, taking strides away from shifting the local tracking coordinate space. It will allow for object placement within local coordinates, and others in shared coordinates. Currently, in multiplayer this is not possible. All peers’ origins are transformed to match that of the host after localization, and there is only one shared space available with no way to retain the original local space. Unfortunately, an ETA for these advanced features is not available at this time, but please check the release notes and roadmaps of future versions.