google 云锚工具介绍

使用云锚点创建 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形式)实现这一目标,尽管这是一个手动过程。

上述视频演示下载

参考资料

  • 讨论 钉钉群21745728 qq群144081101 567351477
  • 本文最新版本地址
  • 本文涉及的python测试开发库 谢谢点赞!
  • 本文相关海量书籍下载
  • https://medium.com/6d-ai/dawn-of-the-ar-cloud-1b31eb4b52ac
  • https://developers.google.com/ar/develop/developer-guides/anchors

你可能感兴趣的:(google 云锚工具介绍)