Mixedrealitytoolkit-unity: "Sharing with UNET" example - Anchor isn't shared with Client

[hansbickhofe]

Overview

When testing the Hololens Example "Sharing with UNET" with two Hololenses the Anchor isn't shared from the Server "Lens" to the Client "Lens".

Expected Behavior

One Device starts a Session, second one joins the Session, both Devices can "fire" Balls, see the moving remote "Head" and the Debug-Button (Anchor) at synced Positions.

Actual Behavior

One Device starts a Session, second one joins the Session, both Devices can "fire" Balls, see the moving remote "Head"and the Debug-Button (Anchor) at different Positions.
When we look into der Debug Output we notice the following Message right after tapping the "Reset Anchor" Text:

"This script is not intended to be run from the Unity Editor" - (MixedRealityToolkit-Unity/Assets/HoloToolkit-Examples/SharingWithUNET/Scripts/GenericNetworkTransmitter.cs Line 132)

Further Clicks at "Reset Anchor" Text show that the "recived" Ancher was empty and a download of the new Anchor was requested.

Steps to reproduce

https://github.com/Microsoft/MixedRealityToolkit-Unity

Unity Editor Version

2017.4.4.f1

Mixed Reality Toolkit Release Version

2017.4.0.0

[StephenHodgson]

HoloLens can never be the server.

Server can only be hosted from PC or hosting service.

[hansbickhofe]

Hmm, as far as I remember this worked for us in a Project a Year ago, but maybe I'm wrong about this, because for the most Projects we used the sharingserver. What Kind of "hosting service", that you mentioned, could we use to connect multiple Hololenses together?

[StephenHodgson]

There is direct pairing. Maybe that's what you had used be?

I've put the sharing service on an Azure service before, but it's been sume time since I've done it, but it's possible.

[hansbickhofe]

But we don't wanna use the sharingservice.exe. We use the sharing with UNet Example.

[StephenHodgson]

Ohhh, sorry I was confused.

[hansbickhofe]

Any Hints on this Issue? Our old Project works as expected.

[zachyale]

Also tagging in on this- my old project worked as expected, but on Unity 2017.4.5f1 and HoloToolkit 2017.4.0.0 I am also running into issues while using the UNET sharing approach.

[Redge-Ballard]

Ran into this same issue as well. It seems like the second lens that joins creates an anchor at its current position rather than at the position of the correct anchor which causes an offset in position/rotation. It's weird because the debug logs show that the anchor gets downloaded and the IDs match, but the actual location of the anchors is completely off.

[keveleigh]

I believe I've root caused this issue and have opened #2319 with a fix. Please take a look and let me know if it fixes your issue! I was able to repro it before this fix and now the test scene works for me.

[hansbickhofe]

@keveleigh @StephenHodgson We are happy to confirm that the fix #2319 works as expected! Thanks for your efforts!

[isurfraz]

@keveleigh @StephenHodgson I am currently working for PAULEY on the MRPP current cohort and have run into this issue a number of times, but now we are focusing on the multilens portion of our development and need to mitigate this. Will pulling the june18 branch fix this ,or is there a way someone from ms can get a intermediate release of this out? Important we get around this ASAP

[keveleigh]

@isurfraz Not a master pull yet, but a pull of the june18_dev branch will.

[isurfraz]

Okay many thanks!

[isurfraz]

Hi Pulling June 18 branch did not fix this issue, the anchor placement is still off by the same amount. If anything it seems to have made no difference other than made the color of the session list UI change to blue from red...

[hansbickhofe]

@isurfraz You're right. The june18_dev Branch only fixes the initial Issue withe the Error "This script is not intended to be run from the Unity Editor". We ran into the same Problm only 2 Days ago.

[isurfraz]

Update: this is still being experienced by us using the latest MRTK release from 4 days ago