I’m testing the Shared Object Interaction Template.
I join two Mi9 devices to a session and try to bring up the rocket on the host device. This fails because the condition SharedSession._isStable is false (should be true).
Documentation about _isStable says:
“this means ARDK has synchronized the user’s scan with the downloaded data from Niantic’s AR Backend and the client is now localized in the shared environment”
Depending on your network connection, the shared session state should become true as soon as both devices are finished connecting to the session. Approximately 5-8 seconds. In other words it should not take long at all. Do both of your devices have access to WiFi?
I noticed that the PeerState stops at WaitingForLocalizationData. It is trying to create a map but a map is never created. Why is that?
Rarely (like, once every ten attemps) I get PeerState.Stable, usually when I keep my phone pretty stable while trying to track the first plane. But most of the time, even this does not work.
I’d say this is a pretty ‘unstable’ behaviour (sic) of this app, am I the only one that has noticed this?
Any combination of the two should be fine. What I asked you was if both of your devices were able to access WiFi? Also have you tried updating your project to the newest Unity LTS? 2020.3.35f1 is the most current LTS version that has been released. Please take a look here
Yes, both devices access the wifi, I don’t see a problem there.
I also upgraded to the latest LTS version just in case, but the issue remains.
My observations after so many rebuilds and tests is that it seems that in areas with lower light than usual (e.g. my room) the PeerState stops at WaitingForLocalizationData, even though plane detection works fine.
On the contrary, it is easier to get a Stable state outside in the daylight. So, it seems that larger open spaces and more light help, but do not fully resolve this issue.
Hi BBIT-Solutions, thanks for the link.
Based on the below image, I can say that the cases on my side are as follows:
Case 1:Device 1 joins as Host only: Device 1’s PeerState stops at WaitingForLocalizationData Case 2:Device 1 joins as Host and becomes Stable, Device 2 joins as peer: Device 2’s PeerState stops at Localizing.
You’re wecome.
I experienced case 1 also several times. Guess the only advice is to walk a bit more around your object, also do some rotation/tiliting with your phone, and also ensure the lighting is good. Or if possible maybe try it with another target object.
To case 2: I guess the better the object is and the faster it can be found by the Host, the easier it can be found by the peer/s, too. But not sure…
Well, it’s a pity because the ARDK has significant advantages over the ARFoundation in Android, however it seems that there are still stability issues to overcome. I have also come across this other post of yours and I can confirm that version 2.0.0’s examples look slower and more imprecise than the same examples in version 1.3.1 which I tested a couple of months back (on the same phones).
Thanks for your patience and I’m sorry to hear that you’ve been having trouble getting the Shared Object Interaction template to work.
Regarding the case when the PeerState stops at WaitingForLocalizationData, this state happens when there is either a networking issue or issues uploading the map. In my experience the amount of time it takes to reach a stable state can fluctuate on a number of factors including your network connection, device you’re using, how you’re moving the device, object being scanned, etc. For case 2 where the issue is with the second device’s PeerState not moving past Localizing, as you already discussed this is most likely due to environmental factors. Not sure if you’ve already seen this but we do have a guideline for scanning best practices found here. I’ve also pasted them below FYR:
Find and scan a stationary object in your environment. Look for an object with many sharp features (e.g. edges with high contrast, non-symmetrical/repeating patterns) and no shiny or reflective surfaces. One example might be an object with distinct features and colors, like a shoe.
Stand 3+ feet away from the object you are mapping.
Have your device camera looking straight at the object, not from a high or low angle. Avoid looking at the floor. We want to understand as much of the 3D scene as possible, and wide, flat surfaces don’t help. You may need to position the object on a raised surface, like a table.
Keeping your camera looking at the object, slowly move a few steps in a circular direction around the object, both to the left and right. Avoid moving in a direction towards or away from the object. Avoid swiveling the camera (i.e. only rotating around a single point without any side-to-side or up-and-down movement).
Continue moving left and right until the scanning completes. This should take approximately 15 seconds, but may take up to several minutes depending on the complexity of the environment and the capabilities of your device.
Following these guidelines should help make localizing with the client easier. Hopefully this helps some. Please let us know how things progress.
Yes, i agree (when it works) ARDK is ways better than ARFoundation. But ok, at least good to know, that 2.0.0 is not only on my device slower
CC @Gilberto
Thank you Mar for the advice, I must confess that I was not aware of these instructions.
I will mark this as a Solution, although I must admit that I won’t get many customers if I ask them to do all these things in order to sync!
Good to know anyways! Thank you for your time.
