Issue: ARMesh offset from the local position after peer’s localization became stable.
The ARMesh scanned from local, will adjust its zero to the host’s zero, therefore, the whole local ARMesh will be offset according to it.
Unity 2020.3.25.f1
iPhone 12 Pro & iPhone 13 Pro
ARDK v1.1
Bug reproduction steps:
can confirm this happens every time I try to use meshing and multiplayer localization
I tried enabling the meshing component after localization, tried setting the AR mesh root to static, but the peer mesh always changes rotation based on the host start position
Hello Alexson,
Thank you for bringing this to our attention. We will investigate and get back to you when we have more information.
Hey I can confirm this as well. Happens to me using iPhone 12 Pro and iPad Pro with LIDAR on Unity 2019.4.33f1.
@Jason_Rose1 is there a way to get the offset that is applied to the scene after the client becomes stable? If yes we could apply the inverted transformation to the meshing for the time being until there is an official fix…
Hello Jan & Alexson,
A potential work around for this issue may lie in resetting the ARMesh and rescanning after the peer has become stable. We do not support doing this automatically yet, but it is on our radar. We will update the community when we have a fix.
Hello everyone,
Can either of you tell me what you are using the meshes for? For example, are you using the mesh for physics, occlusion?
Does that mean that, as a general best practice, you recommend connecting to the peer first, then meshing?
Hello Michael,
Currently, yes it’s recommended that you connect to the peer before meshing since it’s not done automatically (yet). If you do it the other way, the user would have to reset the ARMesh and rescan after reaching a stable state."
Hey Jason,
Exactly. I am using the Mesh for both collision detection and occlusion
Hello, I’m seeing exactly this problem even though I don’t enable meshing until after all the peers have become stable - is there some specific thing I need to do to reset the ARMesh?
(I’m using ARMeshManager not managed via Unity Lifecycle and I call nothing on it until I call Initialise and EnableFeatures after the peers are stabilised.)
Did anybody manage to get this working? thanks
Hello Alexson & Ross,
We are still working on a fix for this issue. Your patience is appreciated.
Hello Alexson & Ross,
We were unable to reproduce the bug using the steps that you’ve provided… Could you please give us more detailed information about the steps that you are using when the issue occurs? Also, what are your expected results vs the actual results when the issue occurs, and does occur 100% of the time? We will close this thread in two days if we do not receive a response, however if you still run into these issues after the thread is closed, opening a new discussion is always available as an option.
Hi Jason - hmm that is curious.
For me the bug was 100% reproducible.
My steps were:
I created the multiplier networking session via the ARNetworkingSceneManager prefab.
Waited until both players were in the Stable state
and then called ARMeshManager.EnableFeatures() on both of them.
At that point they’d both start showing their meshes but only the host’s mesh would fit the environment - the other would be really noticeably offset/rotated -
this was on an iPhone 11 and an iPhone 13 Pro.
(I was seeing the same issue when I enabled meshing before waiting for the players to be stable.)
I’m using the past tense here because I haven’t been able to retest this today - because of this issue → App Freezes when enabling meshing in Multiplayer
You do actually have my codebase there if you wanted to reproduce it with that - because i sent it in for the winter competition.
I saw the bug in ARDK 1.0.1 and haven’t been able to retest in 1.1.0 yet…
Thanks!
Ross
Ok I just did manage to reproduce it.
All I did was add the default ARMesh prefab to the HLAPI Pong demo scene (and let it be managed by Unity Lifecycle)-
and then run the app on both my iPhone 11 and iPhone 13 Pro -
Thank you for the bug report Alexson Chu and Ross Styants! I’ve managed to reproduce the issue locally, and will forward the information to the appropriate teams for follow-up.
My approach to prevent this issue from happening is:
Of course this is only valid if you want all players to share the exact same mesh, but I guess that’s the case very often.
Hello - do you have any idea when/if this will be resolved? thanks
Apologies, this thread flew under the radar for a bit. The issue is still unresolved in 1.2.0.
The current workaround for this is to reset the mesh after becoming stable by using ARMeshManger.ClearMeshObjects. This should be called after peer (non-host) devices become stable. For more information on method usage, please refer to documentation for ARMeshManager.
Thanks will try this out when I get the chance.
