加强现实技术在Web端的技术原理

鉴于Web技术的最新进展，在开发基于AR的解决方案时，它提供了一组新的选择。网络浏览器的最新更新为AR的应用打开了大门。使用Web或本地应用程序构建AR体验更好吗？在本文中，我将简要概述JS在本机应用程序世界中的使用，而后将深刻探讨什么是WebAR，它如何工做，如何与本机应用程序竞争以及哪一种是更好的解决方案。

如下内容由公众号：AIRX社区（国内领先的AI、AR、VR技术学习与交流平台） 整理

前面咱们经过一篇文章相信介绍过WebAR：万字干货介绍WebAR的实现与应用这篇文章主要详细介绍WebAR与native AR的区别。

JS在应用程序端扮演什么角色？

Javascript无处不在，包括嵌入在本机应用程序中。使用JS代码执行C ++代码的能力使Blippar，Zappar，Facebook，Snapchat和其余此类平台可以使开发人员更好地控制其AR体验。JS具备许多吸引人的特性，但最引人注目的是Java语言由iOS和Android原生。

为了提供有关JS和C ++如何协同工做的上下文和详细信息，我将使用Blippar的移动SDK做为示例。Blippar SDK的核心是一个基于C ++的OpenGL渲染引擎，该引擎使该应用在各个平台之间的比价更高。Blippar的Javascript API容许第三方开发者使用JS控制底层引擎，但得到了C ++的全部响应能力并为用户提供了本机效果。

前面提到的全部SDK / API都比ARKit和ARCore早。如今，每一个平台都有本机实现，Viro Media建立了一个React插件，该插件能够实现本机和跨平台AR开发。

当咱们讨论使用Java的AR平台时，咱们不能忽略Amazon。亚马逊推出了Sumerian平台，旨在弥补创做者/出版者立场之间的差距。亚马逊在AWS之上构建了本身的XR渲染引擎和Studio。容许用户在AWS基础设施的全部支持下扩展他们的游戏/应用/体验。

显然，这是亚马逊吸引新开发人员并保留现有客户以在其平台上进行构建的一种方式。这里有几件事要注意，对于后端和架构师，这代表亚马逊看到了明确的平台。对于前端人员而言，Somerian工做室所有基于网络，脚本编写所有使用基于Javascript的API完成。

Adobe是创做者领域的另外一位强大参与者，他们的Project Aero处于私人Beta版，它可使创做者使用USDZ格式。

咱们不能谈论全部人，更不用说Sketchfab了。最初是供3D艺术家上传并很好地显示做品的资源库，现在已发展成为具备API的市场，而且启用了ARKit的iOS应用容许用户在本身的世界中放置3D模型。随着AR和VR愈来愈流行，Sketchfab是一家值得关注的公司。

什么是WebAR？

WebAR不只仅是AR的子集，它仍是一个笼统的术语，涵盖了许多不一样的实现。WebAR解决方案的范围很广，既可使用设备的陀螺仪/加速度计传感器做为背景，也可使用相机输入，也可使用更复杂的解决方案，例如AR.js，TensorFlowJS和USDZ。

根本上，AR正在使用移动设备的传感器来跟踪其在加强场景中的位置。在过去的几年中，移动浏览器已经增长了对JS Sensor API的支持，例如照相机，陀螺仪，加速度计，方向，磁力计（阅读：指南针）。利用这些传感器，开发人员能够创造一系列的体验。

Blippar是最先经过横幅广告启动浏览器内AR体验的公司之一；在AR的背景下，该布局是一个相对新颖的概念，但在推出时引发了极大的轰动。该广告是汽车内部装饰的360⁰体验³，其中按钮重叠，以切换显示汽车的详细信息。

我问的第一个问题是响应速度如何？AR在计算上很昂贵，那么它如何在浏览器中工做？WebAssembly是网络标准，容许浏览器执行汇编使用二进制文件代码。WebAssembly文件是经过将C / C ++编译为.wasm使用JS代码执行的文件来建立的。

让咱们考虑一下这里的含义。使用WebAssembly，可使用原始Javascript在Web浏览器中以接近本机的性能运行计算密集型操做。WebAssembly使TensorFlowJS和ML5JS等项目成为可能。

WebAssembly很酷，可是仅占WebAR的一半。WebAssembly在AR的计算机视觉方面完成了全部繁重的工做，而咱们拥有用于渲染的webGL。WebAssembly和WebGL是基础，可是咱们如何使用这些API建立基于Web的AR体验？输入由Jerome Etienne编写的框架AR.js，该框架使用A-Frame（在Three.js之上构建）和JSARToolkit5 （ARToolKit的脚本端口），还有其余一些WebAR框架，可是大多数都须要特殊的Web浏览器应用程序或利用专有的API。AR.js是开源的，不须要任何特殊的应用程序，它可在默认浏览器中运行。

为了讨论AR.js及其对WebAR的含义，值得快速浏览一下为框架提供支持的组件。A-Frame是在Three.js之上的基于JS的API框架，使其更像具备实体组件关系的游戏编码。这简化了Three.js的语法，使开发人员能够专一于体验/游戏。而后，AR.js使用JSARToolkit跟踪3D场景到标记，并利用Computer Vision检测特征点。这是大多数早期基于应用程序的AR体验的动力。AR.js为移动网络提供了前进的脚，并能够与基于应用程序的AR竞争。

看一下苹果和谷歌的努力，咱们看到他们已经采起了一些措施，以实现3D模型与其各自的移动浏览器之间更深层次的集成。让咱们从Apple的.usdz文件格式开始。

什么是USDZ，它如何运做？用最简单的话说，Apple已将ARkit功能内置到iOS的Safari中。带有几行html和一个文件.usdz，任何网站均可以包含AR元素。

<a rel="ar" href="model.usdz"> 
  <img src =“ model-preview.jpg”> 
</a>

.USDZ是Apple的标准本机文件格式，用于在其移动浏览器，iMsg，电子邮件和Notes应用程序中显示3D。

在谈论USDZ和Apple以前，咱们不得不说起Google在WebXR Device API和WebXR Hit Test API（Chrome Canary中）方面的进步。Google但愿将基于Web的AR放在首位。
我将假设Google使用与Poly项目相似的文件类型.obj以及.glTF文件格式。与苹果公司不一样，谷歌选择采用流行的标准格式，这代表谷歌已经在考虑下降3D生态系统中已经采用的障碍。

无需应用程序

无应用程序AR是指使用本机Web浏览器来提供AR体验，使其能够在全部平台，设备和移动OS上运行。当Blippar启动AR数字展现位置（在网络浏览器中启动AR的横幅广告）时，咱们看到了大量潜在客户。代理商，零售，娱乐，制药等机构都有巨大的需求，全部这些机构都但愿与用户互动，而无需下载应用程序。大多数代理商和品牌都愿意将AR体验添加到现有应用程序中，但他们也意识到这种参与与删除应用程序下载时的体验不一样。网络无摩擦，每一个人都有一个带有QR扫描仪的相机应用程序，能够连接到网站。回到我前面提到的AR广告展现位置；当时最大的争斗集中在浏览器兼容性上。迄今为止，基于Web的AR体验仍然是一个问题。

并不是每一个移动浏览器都支持Sensors API，或者设备缺乏某些传感器，这是咱们在Android设备上尤为看到的一个巨大问题。经过商店发布应用程序时，能够控制能够在哪一个设备上安装该应用程序，可是在网络上则没有该控件。是的，它能够在网页中添加检查，可是随后你会看到一个屏幕，上面写着“抱歉，不支持您的设备”，这就很让人崩溃！

WebAR竞争力

当前，Web浏览器在AR摄像机方面没有足够的访问权限。AR摄像头与传统摄像头的不一样之处在于，它在OS级别而不是其顶部处理加强。当前基于Web的AR的实现要求在OS之上进行计算，从而致使计算滞后，限制渲染，有时甚至致使可见滞后。

要使AR经过Web更加可访问性，迈出的一大步就是Web Standards采用API直接访问ARCamera对象。

若是该抽象能够做为标准的Web API存在，则任何浏览器应用程序均可以利用ARkit / ARCore或存在的任何底层平台。Web API一旦存在，就会出现许多不一样的框架。有一些实验性浏览器利用ARKit / ARCore，但它们须要特定的JS框架。

USDZ是一个良好的开端，但缺乏重要的组成部分，而这一层增长了对交互的支持。谷歌的努力仍然仅在Canary版本的Chrome中可用，所以在其正式版中加入以前，它将落后于苹果公司。

当我开始写这篇文章时，个人想法是会有一个明确的利弊清单，可是在坐下来并仔细研究了我认为的利弊以后，不管Web和Native哪里都不足，都有SDK和API能够补充。

视觉搜索只能经过基于应用程序的解决方案来实现。例如，Blippar的识别引擎不依赖QR码，它使用ai识别其系统中的已知实体，并在存在匹配项时提供体验。对于但愿利用其现有印刷材料而没必要更改其设计的公司而言，这很是有用。

视觉搜索的行为仍然是新事物，并非很直观，大多数人不习惯将手机对准东西，即便会出现炫酷的AR内容。

代替可视搜索，WebAR依靠QR码。从设计角度来看，QR码不是很性感，可是自从iOS和Android都在其本机相机应用程序中都添加了对QR码识别的支持后，扫描QR码的行为已获得愈来愈普遍的使用。

能够提出另外一个论点，即互联网和加强现实技术在全球范围内均可以使用，咱们须要牢记，在某些新兴市场中，互联网的速度和可靠性并不那么快。这就须要支持离线使用，这只能经过应用程序得到。另外一方面，让某人下载应用程序比访问网站困可贵多。所以，最终结论是……这确实取决于项目。

WebAR如何发展

许多人都对AR的将来作出了预测，不管它的耳机，投影仪仍是植入芯片的极端特性，等等。为了加入这个世界大胆而勇敢的算命先生的行列，我将分享个人想法。当前，大多数AR内容（体验中的媒体）都托管在设备上或从云加载。Blippar，Facebook，Snapchat，Zappar都使用基于云的CMS，该CMS基于某种触发（连接，标记，面部，qr代码等）下载AR体验。为了提供有关云交付的AR如何工做的背景信息，移动应用程序具备某种触发或进入点（连接，标记，面部，二维码等），能够启动体验。此触发器提示应用程序向后端系统发出请求，以发送体验的资产和代码。大多数平台在启动以前都会下载整个体验，这解释了为何Facebook和Snapchat的上限为4 mb，以保持快速运行。在Blippar，咱们提供了各类体验，所以有时咱们不得不发挥创造力。项目的内容从页面上的视频到3D世界，赛车上山路甚至在Apps上彻底可用。所以咱们的广告系列范围从> 1 mb到85 mb或更大。为何这很麻烦？就像我以前提到的，咱们过去经常经过对场景进行编码以在后台下载资产的方式来发挥创意，那么有什么大不了的呢？事实证实，为何大小很重要，保持正确的平衡对您的AR体验的成功相当重要，但背后还有一些颇具影响力的数字。在Blippar，咱们发现，花费30秒以上才能进行加载（下载和初始化）的全部体验都会减小约50％的体验，而那些最初尝试进行互动的用户还会流失约75％的用户。这意味着，较长的下载时间可能会致使多达90％的受众群体流失，大约有10％的用户会从新参与。所以，如今除了必须以某种方式让某人下载应用程序以外，还可使用户保持您的应用程序须要快速加载。若是您得到适当的平衡，则体验能够看到每位用户最多3倍的参与度，而停留时间是2倍。WebAR使用Web优化进行下载和传送，可是大小仍然很重要。若是不流式传输内容，则体验越大，在移动浏览器中加载所需的时间就越长。

关于更多机器学习、人工智能、加强现实资源和技术干货，能够关注公众号：AIRX社区，共同窗习，一块儿进步！