As for not wanting to follow the flow of having the user point their camera at the localization target
That is not the flow I am referring to. Obviously a visual positioning system is going to require visual input. The flow I am referring to is this, as proposed by niantic:
- Go to a VPS activated Wayspot (guided by the VPS Coverage API)
- Start VPS localization (no map specified, VPS will attempt to localize device with any maps in vicinity).
- Create and/or resolve WayspotAnchors. These are what you should be “anchoring” your experiences around (ie link game content to a WayspotAnchor instead of to a map identifier).
Step 1 requires me to guide a user to a specific location before localizing them. This is backwards. I want the VPS to tell me where I am. I don’t want to have to tell the VPS where I am and then have it just trust me so long as it can reach a state of “localized” anywhere.
Step 2 points out that this is by design. The VPS will attempt to localize to any maps in the vicinity. What is that vicinity exactly?
It may require a little extra time to diagnose and test as the reproduction steps have specific physical requirements.
As I stated before, you can repeat this bug with any two VPS wayspot anywhere regardless of vicinity. Load the demo scene. Place anchors. Save Anchors. Go localize to any other scene. Reload anchors. They will appear and they will be wrong.
Niantic proposes that we build our own gps-based geo-fencing system to try to guess at what wayspot has been localized (this is what I was told at the summit). What I am pointing out is that such a system would not be reliable as it would have to be based off of gps and would fail when multiple wayspots are “in the vicinity.”
The issue doesn’t necessarily have to do with proximity, just that the proposed workaround would not work due to proximity and the paradoxical design choice to make us rely on GPS to try to localize to ~cm accuracy. The issue is the wayspots provide no meaningful information off of which we can build or confirm what wayspot has been scanned.
IMHO the VPS works beautifully but the implementation is fully broken and backwards. I can’t rely on players in a competitive game to just not scan the wrong vps point on their honor, as an example.
Lastly, I have three wayspots I can localize to without standing up from my desk. You can follow the documentation here to make your own as well. VPS provides no way to differentiate between them. Again, we are being required to tell VPS where we are when it should be able to tell us.
Working around this issue is requiring a huge amount of development time and I am being forced into a user flow I don’t want to implement or use. I have my own ideas.