指南

從掃描到作品活起來，手機在這之間做了什麼。

QR code 打開的是一個普通的網頁。這個網頁會要求使用相機，之後便以每秒大約三十次的速度反覆執行一個迴圈：在畫面中找出有辨識度的點，與作品的指紋比對，算出印刷品在空間中的位置，再透過同一個變換繪製各個圖層。沒有任何伺服器看得到任何一格畫面。

迴圈

四個步驟，每秒三十次。

  1. 1

    找出值得追蹤的點

    角點和高對比的紋理——也就是影像同時在兩個方向上發生變化的地方，因為只有這些點能在手機移動時被可靠地重新找到。平坦的區域和筆直的邊緣在這裡派不上用場。

  2. 2

    與作品比對

    作品在上傳時就分析過一次，並濃縮成由這些點構成的指紋。把即時畫面與它比對，就能知道眼前的哪些點對應到印刷品上的哪些點。

  3. 3

    算出印刷品在哪裡

    只要有足夠多的配對點，一道運算——單應性變換（homography）——就能還原這個平面矩形在相機畫面中的位置與傾斜角度。錯誤的配對會透過共識被剔除，而不是被照單全收。

  4. 4

    透過它繪製圖層

    同一個變換決定了你的影片和文字的位置，讓它們貼在印刷品上，而不是飄在螢幕上方。接著下一格畫面到來，一切再重來一次。

不談瀏覽器的概念版：影像追蹤的原理。

靠什麼撐起來

三個瀏覽器 API，不需要外掛。

getUserMedia——相機

標準的權限提示，和視訊通話用的是同一個。影像串流是一個普通的 video 元素，網頁可以從中讀取像素。這個權限按網站授予，觀眾也可以撤銷——這通常比已安裝的 App 所提供的還多。

WebAssembly——視覺運算

特徵偵測與比對是密集的數值迴圈，而這恰恰是 JavaScript 最不擅長的。把這一半編譯成 WebAssembly，才讓中階手機也能達到每格約 30ms 的時間預算。

WebGL——合成

圖層在 GPU 上依照追蹤器算出的姿態繪製，而且就畫在算出這個姿態的同一格畫面上。如果用較舊畫面算出的姿態去合成當前畫面，疊加層就會飄移晃動。

直白說明限制

這對你拿來對準的作品意味著什麼。

這些是方法本身的特性，而不是哪一個平台的特性——所有以影像追蹤為基礎的 AR 工具都適用。

被追蹤的是細節

細節豐富的插畫，追蹤效果非常好。有大片平坦色塊的極簡印刷品，幾乎讓追蹤器無處著力；而重複的圖案比什麼都沒有更糟，因為每個點看起來都和其他點一樣。

什麼都不會上傳

相機畫面在裝置上處理完就丟棄。真正透過網路傳輸的是設計——作品的指紋和你的圖層——而且只下載一次。這是在裝置上運算的本質特性，而不是一項可能悄悄改變的政策。

沒有深度，沒有世界錨點

瀏覽器拿不到原生 App 能使用的深度感測器或持久的空間錨點。對固定在印刷矩形上的圖層來說，這毫無損失——矩形本身「就是」錨點，而且比起猜測地板在哪裡，它是更好的錨點。

拿手機對準某樣東西，看看吧。

在瀏覽器編輯器裡，從你自己的圖片開始——幾分鐘就能做出第一個揭幕效果。

開始創作 看看實際效果
常見問題

有疑問，就有答案。

WebAR 會上傳我的相機畫面嗎？

不會。畫面在手機上處理完就丟棄，不會傳送到任何地方。這取決於運算在哪裡進行，而不是一個承諾——追蹤在網頁裡、在裝置上執行，因為每一格畫面若都要來回傳一趟，就永遠不可能守住 30ms 的預算。

為什麼我的作品追蹤效果不好？

幾乎都是因為不規則的細節太少，或重複太多。追蹤需要彼此能區分的點；大片平坦區域一個都提供不了，重複的圖案則提供了許多無法區分的點。細節豐富、有紋理、不對稱的作品追蹤效果最好。

我需要 App 或外掛嗎？

不需要。它是一個網頁，用 getUserMedia 取得相機、用 WebAssembly 做視覺運算、用 WebGL 繪圖——這些在 iOS Safari 和 Android Chrome 裡都是標準功能。觀眾掃描一個碼，它就開始執行。

瀏覽器 AR 能把模型放在我的地板上嗎？

無法穩定做到，而且那是另一種技術。在房間裡擺放物件需要深度感測和持久的世界錨點，而瀏覽器拿不到這些。影像追蹤則是錨定在印刷品上——一個已知的平面矩形，因此是精準得多的附著對象。