指南

从扫码到揭幕之间，手机在做什么。

二维码打开的是一个普通网页。这个网页请求使用相机，之后便以每秒约 30 次的频率循环运行：在画面中找出有辨识度的点，与作品的“指纹”进行匹配，解算出印刷品在空间中的位置，再用同一个变换把图层绘制上去。没有任何服务器会看到哪怕一帧画面。

循环

四个步骤，每秒 30 次。

  1. 1

    找出值得追踪的点

    角点和高对比度的纹理——也就是图像同时在两个方向上发生变化的地方，因为只有这样的点，才能在手机移动时被可靠地重新找到。平坦的区域和笔直的边缘在这里毫无用处。

  2. 2

    与作品进行匹配

    作品在上传时就已分析过一次，被提炼成由这些点构成的“指纹”。把实时画面与它匹配，就能知道画面中的哪个点对应印刷品上的哪个点。

  3. 3

    解算印刷品的位置

    只要匹配上的点对足够多，一次运算——单应性变换（homography）——就能还原出这个平面矩形在相机画面中的位置和倾斜角度。错误的匹配会通过一致性投票被剔除，而不是被直接采信。

  4. 4

    按这个变换绘制图层

    同一个变换决定了你的视频和文字的位置，让它们贴在印刷品上，而不是浮在屏幕上方。接着下一帧到来，一切再重来一遍。

不涉及浏览器的概念版本，请看：图像追踪的原理。

背后的支撑

三个浏览器 API，无需插件。

getUserMedia——相机

标准的权限提示，和视频通话用的是同一个。视频流就是一个普通的 video 元素，网页可以从中读取像素。权限按网站分别授予，观众也可以撤销——这比安装的 App 通常给的还多。

WebAssembly——视觉计算

特征检测和匹配都是密集的数值循环，而这恰恰是 JavaScript 最不擅长的。把这一半编译成 WebAssembly，才让中端手机也能守住每帧约 30 毫秒的时间预算。

WebGL——画面合成

图层在 GPU 上按追踪器解算出的位姿绘制，并且就画在解算所依据的那一帧上。如果用旧帧算出的位姿去合成当前帧，叠加内容就会漂移晃动。

直说限制

这对你要对准的作品意味着什么。

这些是方法本身的特性，而不是某个平台独有的——所有基于图像追踪的 AR 工具都一样。

被追踪的是细节

细节丰富的插画追踪效果极好。大面积平涂的极简印刷品几乎给不了追踪器任何抓手，而重复的图案比什么都没有还糟，因为每个点看起来都和其他点一样。

什么都不会上传

相机画面在设备上处理后即被丢弃。在网络上传输的只有设计本身——作品指纹和你的图层——而且只下载一次。这是在设备端完成计算所决定的，而不是一条可能被悄悄修改的政策。

没有深度，没有世界锚点

浏览器拿不到原生 App 可以使用的深度传感器或持久空间锚点。对于固定在印刷品这个矩形上的图层，这毫无损失——矩形本身就是锚点，而且比猜测出来的地板更好。

拿手机对准一样东西，看看会发生什么。

在浏览器编辑器里，从你自己的图片开始——几分钟就能完成第一次揭幕。

开始创作 看看实际效果
常见问题

有疑问，就有答案。

WebAR 会上传我的相机画面吗？

不会。画面在手机上处理后即被丢弃，不会发送到任何地方。这取决于计算在哪里进行，而不是靠一句承诺——追踪在网页里、在设备上运行，因为每一帧都往返一次服务器，根本不可能守住 30 毫秒的预算。

为什么我的作品追踪效果不好？

几乎总是因为不规则的细节太少，或者重复太多。追踪需要彼此能区分开的点；大面积平涂提供不了任何这样的点，而重复的图案提供了很多点，却彼此无法区分。细节丰富、有纹理、不对称的作品追踪效果最好。

需要安装 App 或插件吗？

不需要。它就是一个网页：用 getUserMedia 调用相机，用 WebAssembly 做视觉计算，用 WebGL 绘制画面——这些都是 iOS Safari 和 Android Chrome 的标准功能。观众扫一下码，它就运行起来了。

浏览器 AR 能把模型放到我的地板上吗？

做不到稳定可靠，而且那是另一种技术。把物体放进房间需要深度感知和持久的世界锚点，而浏览器拿不到这些。图像追踪则锚定在印刷品上——一个已知的平面矩形，因此是精确得多的附着对象。