加強現實技術在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社區，共同窗習，一塊兒進步！