使用云锚点创立 Android 和 iOS 客户可以共享的多人或者协作型 AR 体验。
图片.png借助云锚点，您可以让同一环境中的多台设施使用 ARKit 和/或者 ARCore 锚点。
同一环境中的客户可以将云锚点增加到他们在自己的设施上看到的 AR 场景中。
您的应用可以渲染连接到云锚点的 3D 对象，从而让客户能够查看对象并同步与对象进行交互。
为了实现这些共享的 AR 体验，ARCore SDK 使用 Google 服务器托管和解析锚点。
托管锚点会在给定物理空间的公用坐标系中映射锚点。
在您托管锚点时，ARCore 会将相关可视映射数据从客户的环境发送到 Google 服务器。 上传后，此数据会被解决成稀疏的点图，相似于 ARCore 点云。
解析锚点可以让给定物理空间中的多台设施将之前托管的锚点增加到它们的场景中。
云锚点解析请求会将可视特征形容符从当前帧发送到服务器。 服务器会尝试将可视特征与稀疏的点图相匹配。 这会让您的应用将解析的锚点一致地置于每个客户在他们的设施上都能看到的场景中。
云锚点的数据具备以下存储和访问限制：
托管锚点时上传至云端的原始视觉映射数据在七天后舍弃。
锚点会根据存储的稀疏点图在服务器端解析。
无法根据稀疏点图确定客户的地理位置或者者重建任何图像或者客户的物理环境。
任何时候都不会存储请求中用于解析锚点的可视特征形容符。
随着苹果的ARKit的推出，它开启了消费者AR的起跑枪，我们看到每个大平台都宣布了AR策略：谷歌的ARCore; Facebook的相机平台;亚马逊Sumerian;和微软继续建立其混合现实生态系统。我们现在正在目睹云服务的曙光，这将为AR开发人员提供引人注目的功能，但前提是云服务提供商必需取得客户体验，首先实现消费级UX。
在ARKit和ARCore之前的AR在技术上有效，但客户体验很差。你需要一个打印的标记或者小心地握住和移动手机才能开始使用，而后它工作得非常好。制作了精彩的演示视频，展现了令人惊叹的最终工作经验。直到ARKit推出之前，基本AR的“正常工作”客户体验才可用（这是在牛津活动视觉试验室发明移动SLAM 10年之后）。
客户体验难在：
客户参加具备随机性。客户从任何地方随机加入，即从玩家之间的任何相对角度或者距离。
消除或者最小化“预扫描”，特别是假如客户不了解为什么需要它，或者者取得关于他们能否正确的反馈。
一旦系统同步（即重新定位到共享的世界坐标集），内容就需要精确对齐。这意味着两个系统都同意共同的虚拟x，y，z点与现实世界中的相同点完全匹配。通常在设施之间几厘米的距离在客户感知方面是可以的。然而，当（最终）共享遮挡网格时，任何对齐错误都非常明，底层的ARCore和ARKit跟踪器只能准确到3-5厘米左右，因而对于任何多人重定位器系统来说，取得更好的对齐是不可能的。
客户不必等待。同步坐标系应该是即时的，只要零点击。理想情况下，即时意味着只要几分之一秒，但正如任何移动应用程序设计师都会告诉您的那样，客户在感觉系统速度太慢之前会有2-3秒的耐心。
多人游戏体验应该跨平台工作，并且UX应该跨设施保持一致。
数据管理很重要。安全和数据共享。
那么Google如何做AR Mutiplayer呢？
玩家1启动一个应用程序，而后他们点击一个按钮，表示他们想要“托管”游戏。这会触发向Google服务器上传少量“可视图像数据”到Google的云端。谷歌是准确的非特定的，具体是什么上传，参考视觉数据，在云（在设施上）进行解决并强调它随着时间的推移被丢弃,注意有少量个人识别数据（即一部分来自相机的照片）会自动上传到Google。
玩家1还必需手动输入“房间号”，由于同一wifi SSID中可能有几个锚。谷歌的云而后解决这个上传的视觉数据，创立“锚点”，这是一种3D点云（或者更精确地说是一个SLAM地图，这是一个点云和这些点的少量可识别的形容，甚至可能是少量关键帧图像），它存储在Google的云端。
玩家2出现，并要求加入游戏。玩家1需要告诉玩家2房间号码，以便下载正确的锚点。
Player 2的手机向Google上传更多可视形容符数据，而后Google解决该数据，而后尝试匹配这两个数据集（地图）。这种匹配点云的过程称为“重定位”，假如点云彼此非常类似且很小（即从同一个地方捕获并覆盖一小块区域），则很容易做到，但很难做到当它们不同且大时（即，玩家1和玩家2彼此分开，并且要支持的物理区域很大）。
假如解析/重新定位成功，则将“变换矩阵”传递回玩家2.这只是告诉玩家2的手机与玩家1相关的3D空间中的准确位置，因而玩家2的图形可以是适当地渲染以使其看起来“正确”并且与玩家1看到的物理位置相同。
没有给予玩家2的信息或者指导。
Google已经能够通过Tango的ADF文件（这是一种Anchor形式）实现这一目标，虽然这是一个手动过程。
上述视频演示下载
