ARCore初探

時間 2019-11-08

標籤 arcore 初探简体版

原文原文鏈接

ARCore初探

1.關鍵技術的由來

SLAM是什麼？

根據Wikipedia的介紹：「Simultaneous Localization and Mapping (SLAM) is the computational problem of constructing or updating a map of an unknown environment while simultaneously keeping track of an agent’s location within it.」
最簡單而又直指本質的理解，SLAM指的是當某種設備（如機器人、VR設備等）來到一個徹底陌生的環境時，它須要精準地創建時間和空間的對應關係，並能完美地回答如下一系列問題：我剛纔在哪裏，如今在哪裏？我看到了什麼，如今看到的和以前看到的有哪些異同？我過去的行走軌跡是什麼？我如今看到的世界是什麼樣子，和過去相比有怎樣的變化？個人軌跡抖嗎，個人位置飄嗎？我還能跟蹤到本身的軌跡嗎，若是我丟了應該怎麼辦？我過去創建的對世界的認識還有用嗎？我能在已有世界的抽象裏快速對我如今的位置進行定位嗎？java

SLAM方向分類：
1.基於傳感器的slam
2.基於視覺的slamnode

基於視覺的slam: 分爲sparse, denseandroid

sparseios

densegit

visual SLAMgithub

Slam變種VIO - Visual Inertial Odometry視覺慣性里程計

VIO和以前的幾種SLAM最大的不一樣在於兩點：
首先，VIO在硬件上須要傳感器的融合，包括相機和六軸陀螺儀，相機產生圖片，六軸陀螺儀產生加速度和角速度。相機相對準但相對慢，六軸陀螺儀的原始加速度若是拿來直接積分會在很短的時間飄走（zero-drift），但六軸陀螺儀的頻率很高，在手機上都有200Hz。
其次，VIO實現的是一種比較複雜而有效的卡爾曼濾波，好比MSCKF（Multi-State-Constraint-Kalman-Filter），側重的是快速的姿態跟蹤，而不花精力來維護全局地圖，也不作keyframe based SLAM裏面的針對地圖的全局優化（bundle adjustment）。它並非瞭解到了周圍完整的3D結構,能作的是根據像機反饋進行估計。
最著名的商業化實現就是Google的Project Tango和已經被蘋果收購的Flyby Media，其中第二代Project Tango搭載了Nividia TK1並有主動光源的深度攝像頭的平板電腦，這款硬件可謂每一個作算法的小夥伴的夢幻搭檔，具體在這裏很少闡述。算法

相機和慣性測量單元IMU

相機單目，雙目編程

IMU慣性測量單元是測量物體三軸姿態角(或角速率)以及加速度的裝置。通常的，一個IMU包含了三個單軸的加速度計和三個單軸的陀螺，加速度計檢測物體在載體座標系統獨立三軸的加速度信號，而陀螺檢測載體相對於導航座標系的角速度信號，測量物體在三維空間中的角速度和加速度，並以此解算出物體的姿態。
涉及到的sensors: 陀螺儀，角速度傳感器；g-sensor加速度傳感器api

2.ARCore 進化

在 ARCore 發佈以前，確實有一些手機廠商在自研算法，也有一些手機廠商已經與 Google 對接中，可是從進度和可推廣的能力來講，Google 確實是首選，因此安卓的 AR 能力依靠 Google 這是目前最理想的方式。
自研的表明，Usens 與展訊合做，讓百元手機實現 ARCore 的效果。
由於底層的空間定位算法很是依賴於硬件的校準和標定，任何軟件公司想越過 Google 去支持整個安卓平臺，尤爲還需可以獲得大部分手機廠商的配合去標定 IMU 和攝像頭的參數，這須要和不少OEM 廠商有長期合做的關係，而這幾乎是不可能的。瀏覽器

1到2年內各大廠商確定推出不少支持ARCore手機。

Project tango是Google開發的一個AR平臺，須要專門的硬件配合，效果很好。可是要定製硬件。對於發展不利。現實證實不是那麼成功。而又適逢蘋果在iOS推出了arkit。Google也着急了。把重心移到android平臺。
arcore從projection tango發展而來。
早期的代碼還保留了tango相關的東西。能夠看到preview和以後的版本不兼容，core不同。

版本歷史

還在發展，GitHub提交還很是活躍

不僅android
滲透到已有的工業體系，3D，瀏覽器，IOS等，也反映了google AR的野心和決心

3. ARCore

工做原理和基本概念

ARCore工做時要作兩件事兒，首先跟蹤手機的運動軌跡，而後構建出它對現實世界的理解。
ARCore的運動跟蹤技術是經過 Camera 標識出特徵點，並隨着時間的推移跟蹤這些特徵點是如何移動的。經過這些特徵點的運動數據及從手機慣性傳感器讀到的信息，ARCore計算出手機移動的位置和方向，並稱其爲姿態。

除了識別出這些特徵點外，ARCore還能檢測出像地板、桌面等平面信息以及在某個地方的光線強度。這些信息使得ARCore可以構建出本身理解的真實世界。構建出這樣一個模型後，能夠在上面放置一些虛擬內容了。

ARCore 是一個用於在 Android 上構建加強現實應用的平臺。 ARCore 使用三個主要技術將虛擬內容與經過手機攝像頭看到的現實世界整合：
運動跟蹤
讓手機能夠理解和跟蹤它相對於現實世界的位置。
環境理解
讓手機能夠檢測平坦水平表面（例如地面或咖啡桌）的大小和位置。
光估測
讓手機能夠估測環境當前的光照條件。

運動跟蹤 (motion tracking)

動時，ARCore 會經過一個名爲並行測距與映射（或 COM）的過程來理解手機相對於周圍世界的位置。 ARCore 會檢測捕獲的攝像頭圖像中的視覺差別特徵（稱爲特徵點），並使用這些點來計算其位置變化。這些視覺信息將與設備 IMU 的慣性測量結果結合，一塊兒用於估測攝像頭隨着時間推移而相對於周圍世界的姿態（位置和屏幕方向）。

經過將渲染 3D 內容的虛擬攝像頭的姿態與 ARCore 提供的設備攝像頭的姿態對齊，開發者可以從正確的透視角度渲染虛擬內容。渲染的虛擬圖像能夠疊加到從設備攝像頭獲取的圖像上，讓虛擬內容看起來就像現實世界的一部分同樣。

運動跟蹤demo

環境理解 (environmental understanding)

ARCore 會經過檢測特徵點和平面來不斷改進它對現實世界環境的理解。

ARCore 能夠查找看起來位於常見水平表面（例如桌子和書桌）上的成簇特徵點，並讓這些表面能夠由您的應用用做平面。 ARCore 也能夠肯定每一個平面的邊界，並將該信息提供給您的應用。您可使用此信息將虛擬物體置於平坦的表面上。

因爲 ARCore 使用特徵點來檢測表面，所以可能沒法正確檢測像白色書桌同樣沒有紋理的平坦表面。

環境理解demo

光估測 (light estimation)

ARCore 能夠檢測其環境光線的相關信息，併爲您提供給定攝像頭圖像的平均光強度。此信息讓您可以使用與周圍環境相同的光照來照亮您的虛擬物體，提高它們的真實感。

demo

用戶交互 (user interaction)

ARCore 利用命中測試來獲取對應於手機屏幕的 (x,y) 座標（經過點按或您但願應用支持的任何其餘交互提供），並將一條射線投影到攝像頭的視野中，返回這條射線貫穿的任何平面或特徵點以及交叉位置在現實世界空間中的姿態。這讓用戶能夠選擇環境中的物體或者與它們互動。

定向點 (oriented points)

定向點可讓您把虛擬物體擺放在非水平的表面上。當您運行命中測試而返回特徵點時，ARCore 將查看附近的特徵點並使用它們來嘗試估計給定特徵點處的表面角度。而後 ARCore 將返回一個顧及該角度的姿式。

因爲 ARCore 使用特徵點簇來檢測表面的角度，所以可能沒法正確檢測到沒有紋理的表面（如白色牆壁）。

錨點和可跟蹤對象 (anchor and trackables)

姿態會隨着 ARCore 改進它對自身位置和環境的理解而變化。當您想要放置一個虛擬物體時，您須要定義一個錨點來確保 ARCore 能夠跟蹤物體隨時間推移的位置。不少時候，您須要基於命中測試返回的姿態建立一個錨點，如用戶交互中所述。

姿態會發生變化，這就意味着 ARCore 可能會更新平面和特徵點等環境物體隨時間推移的位置。平面和特徵點是一種特殊類型的物體，稱爲可跟蹤對象。顧名思義，ARCore 能夠隨着時間推移跟蹤這些物體。您能夠將虛擬物體錨定到特定的可跟蹤對象，確保您的虛擬物體與可跟蹤對象之間的關係即便在設備移動時也能保持穩定。這意味着，若是您將一個虛擬的 Android 小雕像放在您的書桌上，即便 ARCore 稍後調整了與書桌關聯的平面的姿態，Android 小雕像仍會看起來位於桌子上。

缺點：

沒法檢測沒有紋理的表面

紋理就是每一個物體表面上不一樣的樣子，也就是事物的特徵，ARCore是基於特徵點檢測的，對於沒有特徵的事物，沒法檢測。好比白色桌面。個人理解是光滑的平坦純色的表面？
日常辦公或小會議室的桌面沒有紋理，前臺大會議室的會議桌有紋理木頭紋路。

平面只支持水平的，不支持豎直的平面，好比牆面。

飄移感（drift）

ARCore從攝像頭捕獲的圖片中探測視覺上不一樣的特徵點和IMU傳感器數據,來了解手機移動時相對於周圍世界的位置,計算其位置的變化。
在小範圍場景內使用不會有明顯的飄移感，但在大場景距離稍遠的狀況下，不許確的計算可能致使虛擬對象在視角中上漂浮游動。
爲了解決這個問題ARCore內置了場景學習(area learning)算法。
場景學習的輸出是場景中的一些特徵，並將它們保存下來，以便未來可以從新定位之前到過的場景，或者用於校訂漂移（drift），提升追蹤算法的總體精度。
可是環境發生一些明顯的變化，仍是會影響場景學習的判斷，產生飄移感。

數據共享

不支持多個設備共享數據。

drift demo? video is not supprot.

Android開發運行環境

開發環境

同時支持SDK和NDK
Android studio 3.0 or higher
SDK platform 7.0 (API level 24) or higher
ARCore SDK for Android

運行環境

Android 7.0 or higher (軟件環境)
你開發應用使用的API在這些Android版本里纔是available的。
ARCore environment is installed (軟件環境)
ARCore環境實際上就是一個ARCore的apk，內置或安裝在手機上，爲ARCore應用提供AR相關服務。也能夠叫ARCore engine。
確保你手機上的ARCore是最新的版本，若是不是最新的在程序運行時候會有相應的提示。由於ARCore在快速發展，接口變化也比較快，有些新的接口只有在新的ARCore中才有。
安裝ARCore engine有兩種途徑，一個是經過Google play

一個是在官方GitHub下載相應的apk

安裝好以後在手機應用裏就能看到相應的信息，再次運行你的apk。
應該不須要GMS的支持，畢竟是獨立的東西，國內的不少固件已經移除了GMS。

ARCore的核心庫

支持的機型 (硬件環境)
並非全部機型都支持ARCore的，實際上支持ARCore的機型是不多的，尤爲國內市場基本沒有，一個是ARCore剛出來不久你們還沒反應過來，還有就是剛纔提到的「須要手機廠商配合google去標定 IMU 和攝像頭的參數」。

在不支持的手機上是能夠安裝ARCore apk的，可是在運行基於ARCore的應用時會收到該手機不支持AR的提示。

「this device does not support AR」
在早期的preview版本里，這個機型列表示在java代碼裏寫死的，能夠經過修改jar包來繞過檢查，使得本身的手機支持ARCore應用的運行。

在後來的版本里，從寫死的改成check設備的相關profile。經過session_ceate_implementation.cc 208 readDeviceInfo()檢查設備是否知足要求，猜想已經不是寫死的，而是設備在出廠前適配了這個調用。
這樣就幾乎沒有辦法hack了。

發佈 (應用商店／google play)

有兩種類型的AR應用
AR optional
表明您的應用起碼有一項只會在支持 ARCore 的設備上才被激活的 AR 功能。可是該應用仍然能夠在沒有 ARCore 支持的設備上安裝和運行。
manifest設置
AR required
表明您的應用必須有 AR 才能運做，僅在支持ARCore 的設備上纔可以使用。
manifest設置

應用與實踐

ARCore Java核心類

ArCoreApk
com.google.ar.core.ArCoreApk類，管理ARCore在設備上的狀態，是否avaliable，是否須要安裝，安裝相關的UI提示等，裏邊都是靜態方法。

Session
com.google.ar.core.Session類，Session管理AR系統狀態並處理Session生命週期。該類是ARCore API的主要入口點。該類容許用戶建立Session，配置Session，啓動/中止Session，最重要的是接收com.google.ar.core.Frame，以容許訪問Camera image和device pose。

Config
com.google.ar.core.Config類，用戶保存session的設置，light estimate模式，udpate模式等。

Camera
com.google.ar.core.Camera類，提供了Cmeara相關的信息，是一個長期存在的對象，Camera的屬性隨着Session.update()更新。

Frame
com.google.ar.core.Frame類，經過調用Session.update()方法能夠得到該對象，獲取AR系統信息，如Camera image， Anchors等。

HitResult
com.google.ar.core.HitResult類，該類定義了命中射線與估算的真實世界的幾何圖形的交叉點，也就是命中點結果。

Anchor
com.google.ar.core.Anchor類，描述了現實世界中的一個固定位置和方向。爲了保持物理空間的固定位置，這個位置的數字描述信息將隨着ARCore對空間的理解的不斷改進而更新。

Plane
com.google.ar.core.Plane類，描述了現實世界平坦表面的最新信息。有兩種平面類型，一種是朝下的如天花板，另一種是朝上的如桌面，地板等。

Point
com.google.ar.core.Point類，它表明ARCore正在跟蹤的空間中的一個點。它是建立錨點（調用createAnchor方法）時，或者進行命中檢測（調用hitTest方法）時，返回的結果。

PointCloud
com.google.ar.core.PointCloud類，它包含一組觀察到的3D點和信心值。

Pose
com.google.ar.core.Pose類，姿式表示從一個座標空間到另外一個座標空間位置不變的轉換。在全部的ARCore API裏，姿式老是描述從對象本地座標空間到世界座標空間的轉換。

隨着ARCore對環境的瞭解不斷變化，它將調整座標系模式以便與真實世界保持一致。這時，Camera和錨點的位置（座標）可能會發生明顯的變化，以便它們所表明的物體處理恰當的位置。

這意味着，每一幀圖像都應被認爲是在一個徹底獨立的世界座標空間中。錨點和Camera的座標不該該在渲染幀以外的地方使用，若是需考慮到某個位置超出單個渲染框架的範圍，則應該建立一個錨點或者應該使用相對於附近現有錨點的位置。

ImageMetadata
com.google.ar.core.ImageMetadata類，提供了對Camera圖像捕捉結果的元數據的訪問。

LightEstimate
com.google.ar.core.LightEstimate類，保存關於真實場景光照的估計信息。經過 getLightEstimate()獲得。

Trackable
com.google.ar.core.Trackable類，是一個接口類，表明了一些ARCore能夠跟蹤而且錨點能夠貼上的對象。好比Point，Plane等他們都是Trackable的子類。

TrackingState
com.google.ar.core.TrackingState類，描述了Trackable的跟蹤狀態，有三種狀態paused, stopped, tracking。

ARCore C核心結構體

跟java核心類基本同樣，除了語法的不一樣，其餘都差很少。
這樣的設計，下降了sdk和ndk開發之間切換的學習成本。
api都在arcore_c_api.h裏包含，接口格式ArClass_method()，例如ArSession_create()，ArAnchor_getPose()等。

代碼結構

3D models

obj文件是3D模型文件格式。由Alias|Wavefront公司爲3D建模和動畫軟件"Advanced Visualizer」開發的一種標準，適合用於3D軟件模型之間的互導，也能夠經過Maya讀寫。利用了現有的工業成果。
obj包含了物體的幾何信息，可是不包含材質顏色光照，動畫，貼圖等信息。
因此須要一個材質庫文件，就是mtl。
obj(shape)

one of the materials

the final look

其餘3D模式文件格式，3ds,awd,max,fbx,mesh,blend,dae,c4d等

shaders, opengles

一段在gpu上執行的程序，編程語言OpenGLES SL語言。

實例分析
瞭解了原理以後，分析下demo程序的流程。
建立Session和Config
在 Activity中的 onCreate 方法中建立 Session 和 Config是個不錯的地方。

mSession = new Session(/context=/this);

mDefaultConfig = Config.createDefaultConfig();
if (!mSession.isSupported(mDefaultConfig)) {

Toast.makeText(this, "This device does not support AR", Toast.LENGTH_LONG).show();
finish();
return;

}
Session：是ARCore的管理類，它很是重要。ARCore的打開，關閉，視頻幀的獲取等都是經過它來管理的。
Config：存放一些配置信息，如平面的查找模式，光照模式等信息都是記錄在該類中。目前該類還比較簡單，裏邊沒存多少東西。
isSupported：該方法主要是對 SDK的版本及機型作控制。目前官方只支持幾款Google和三星的機子作測試。其它機型還都不支持ARCore，固然有一些機型經過破解後的SDK是可使用 ARCore的。該方法中的 Config 參數沒有用到。

建立 GLSurfaceView 用於AR展現
在 Google 提供的Demo中，AR的展現部分使用的是 GLSurfaceView。作視頻開發的同窗都清楚，Android 可使用三種View進行視頻渲染。分別是：

SurfaceView
GLSurfaceView
TextureView

其中，SurfaceView最靈活，效率也最高，但使用起來比較繁瑣。而GLSurfaceView是SurfaceView的子類相對 SurfaceView就是簡單不少，只須要實現它的 Render 接口便可。而 TextureView使用最簡單，不少工做都由 Android 的窗口管理器幫你作了，但靈活性相對較差。
選擇GLSurfaceView的緣由是它能夠很方便的支持OpenGL渲染。

爲了渲染的高效，Google在Demo中大量使用了OpenGL技術。

mSurfaceView = (GLSurfaceView) findViewById(R.id.surfaceview);
...
mSurfaceView.setPreserveEGLContextOnPause(true);
mSurfaceView.setEGLContextClientVersion(2);
mSurfaceView.setEGLConfigChooser(8, 8, 8, 8, 16, 0); // Alpha used for plane blending.
mSurfaceView.setRenderer(this); mSurfaceView.setRenderMode(GLSurfaceView.RENDERMODE_CONTINUOUSLY);

該段代碼首先經過資源文件建立一個GLSurfaceView對象，而後初始化 GLSurfaceView 管理的EGL display的一些信息。並將Activity做爲GLSurfaceView的回調對象（也就是說該Activity要實現 GLSurfaceView.Renderer中定義的接口，如onSurfaceCreated、onSurfaceChanged、onDrawFrame等），最後設置 mSurfaceView 的渲染模式爲 GLSurfaceView.RENDERMODE_CONTINUOUSLY，即對 GLSurfaceView 持續不斷的渲染。
建立各類渲染的對象
要理解本節內容，首先你們要知道AR的詳細工做原理是怎樣的。這裏再作個簡要的說明。

背景展現

用過AR的人都知道，AR是將一些虛擬物品放到真實的場景中。那麼這個真實的場景從哪裏來呢？固然是從手機的 Camera上獲取。

咱們把從 Camera中獲取的視頻看成 AR的背景。其實，AR 就是將虛擬物品放到視頻上，只不過不是簡單的放置，而是須要通過大量的計算，找到視頻中的平面位置再放置。

而Android中視頻的採集相對比較簡單，ARCore內部完成了Camera數據的採集，調用相關API便可得到。

平臺檢測

上面咱們已經說了，AR就是實時視頻+虛擬物品。但虛擬物不能簡單的放到視頻上，而是先對視頻中的每一幀進行檢測，找到視頻中的平面，肯定好位置後，再將虛擬物品放置上去。這樣纔算是AR呀。

點雲

上面咱們知道了，AR=實時視頻+平面+虛擬物品。除此以外，它還應該能對虛擬物品進行跟蹤，也就是能夠在不一樣的角度觀察同一個物品，並得出不一樣的姿態，因此就有了「點雲」技術。那什麼是點雲呢？顧名思義，形象的說就是一堆點，這些的形狀有點像雲。點雲中的每一個點都是一個特徵點，它是經過Camera得到的。

放置虛擬物品

找到了平面，有了跟蹤手段，咱們就能夠將準備好的虛擬物品放置到平臺上，如今纔是真正的AR。

好，知道了這些基本原理後，咱們來看看Google Demo是如何作的呢？

建立渲染對象

對於上面的每個方面，Demo都建立了一個對象用來渲染，代碼以下
...

// Create the texture and pass it to ARCore session to be filled during update().
mBackgroundRenderer.createOnGlThread(/context=/this);
mSession.setCameraTextureName(mBackgroundRenderer.getTextureId());

// Prepare the other rendering objects.
try {

mVirtualObject.createOnGlThread(/*context=*/this, "andy.obj", "andy.png");
mVirtualObject.setMaterialProperties(0.0f, 3.5f, 1.0f, 6.0f);
...

} catch (IOException e) {

Log.e(TAG, "Failed to read obj file");

}
try {

mPlaneRenderer.createOnGlThread(/*context=*/this, "trigrid.png");

} catch (IOException e) {

Log.e(TAG, "Failed to read plane texture");

}
mPointCloud.createOnGlThread(/context=/this);

…
須要說明的是在OpenGL中一個EGL context是單線程的，咱們能夠把GLSurfaceView理解成一個EGL context因此GLSufraceView的Render是單線程的，也就是onSurfaceCreated(),onSurfaceChanged(),onDrawFrame()是在同一個OpenGL線程，各個渲染對象的OpenGL操做都必須在這個線程裏，好比建立這些渲染對象都是在onSurfaceCreated()裏完成的，而渲染的動做是在onDrawFrame()裏完成的。

上面的代碼中首先建立了一個背景渲染對象，用來將從Camera中獲取的視頻渲染到屏幕上當背景。數據是從哪裏來的呢？就是經過 Session.update 獲取 Camera 數據，再經過紋理交給背景渲染對象。

對紋理沒有概念的同窗能夠把它理解爲一張2D圖片。

而後建立虛擬物品渲染對象，用於繪製虛擬物品，及發生角度變化時，更新虛擬物別的姿式。緊接着建立平面渲染對象來繪製平面。最後建立點雲渲染對象繪製特徵點。

到此，各類渲染對象就建立完畢了。下面咱們來講一下如何渲染。

命中檢測與渲染
命中檢測

當咱們要向背景繪製虛擬物品時，首先要進行命中檢測。代碼以下
MotionEvent tap = queuedSingleTaps.poll();

if (tap != null && camera.getTrackingState() == TrackingState.TRACKING) {
            for (HitResult hit : frame.hitTest(tap)) {
                // Check if any plane was hit, and if it was hit inside the plane polygon
                Trackable trackable = hit.getTrackable();
                // Creates an anchor if a plane or an oriented point was hit.
                if ((trackable instanceof Plane && ((Plane)
                       trackable).isPoseInPolygon(hit.getHitPose()))
                        || (trackable instanceof Point
                        && ((Point) trackable).getOrientationMode()
                        == Point.OrientationMode.ESTIMATED_SURFACE_NORMAL)) {
                    // Hits are sorted by depth. Consider only closest hit on a plane or oriented point.
                    // Cap the number of objects created. This avoids overloading both the
                    // rendering system and ARCore.
                    if (anchors.size() >= 20) {
                        anchors.get(0).detach();
                        anchors.remove(0);
                    }
                    // Adding an Anchor tells ARCore that it should track this position in
                    // space. This anchor is created on the Plane to place the 3D model
                    // in the correct position relative both to the world and to the plane.
                    anchors.add(hit.createAnchor());
                    break;
                }
            }
        }

在例子中，它查看是否有點擊事件，且圖像處理於跟蹤狀態？若是是，就對其進行命中檢測，看是否能夠找到一個平面或者一個定向點，若是找到就在命中位置建立一個錨點。

渲染背景

// Draw background.
mBackgroundRenderer.draw(frame);
經過上面的代碼就能夠將紋理中的內容推給 EGL，上面建立的渲染對象從 EGL 上下文中獲取數據，最終將Camera視頻渲染到屏幕上。

繪製點雲

mPointCloud.update(pointCloud);
mPointCloud.draw(viewmtx, projmtx);
同理，經過上面的代碼，就能夠將數據傳給點雲渲染對象把點雲疊加在背景上進行繪製。

繪製平面
// Visualize planes.
mPlaneRenderer.drawPlanes(

mSession.getAllTrackables(Plane.class), camera.getDisplayOrientedPose(), projmtx);

經過上面代碼將數據傳給平面渲染對象和前邊數據進行矩陣疊加並繪製。

繪製虛擬物品

for (Anchor anchor : anchors) {

if (anchor.getTrackingState() != TrackingState.TRACKING) {
    continue;
}
// Get the current pose of an Anchor in world space. The Anchor pose is updated
// during calls to session.update() as ARCore refines its estimate of the world.
anchor.getPose().toMatrix(mAnchorMatrix, 0);

// Update and draw the model and its shadow.
mVirtualObject.updateModelMatrix(mAnchorMatrix, mScaleFactor);
mVirtualObject.draw(viewmtx, projmtx, lightIntensity);
                
mVirtualObjectShadow.updateModelMatrix(mAnchorMatrix, scaleFactor);
mVirtualObjectShadow.draw(viewmtx, projmtx, lightIntensity);

}
最後，遍歷全部的錨點，在每一個錨點上繪製虛擬物品。

經過這個例子能夠強化以前介紹的一些概念，比較幸運的是咱們獲得一臺單目的google pixel能夠進行調試，在真機上調試對ARCore相關概念的理解幫助仍是比較大的，京東上有部分機型賣，不過價格稍貴。
期待國產2000檔，甚至千元機支持ARCore這一天的到來。

有了ARCore能夠作一些有意思的事情，好比咱們遠程桌面和遠程camera能夠實現把remote畫面投射到AR場景中。
首先獲取到遠程的數據，經過RTCSurfaceViewRender它是SurfaceViewRender的子類，該類重寫了SurfaceViewRender的renderFrame(I420Frame frame)方法，並將I420Frame經過listener返回，在demo中導入rtcsdk.aar，並註冊這個listener便可獲取到I420Frame
mSurfaceViewRender.register(new RTCSurfaceViewRenderListener() {

@Override
public void onRenderFrame(I420Frame frame) {
    //got the remote video frame here，and add it to RemoteVideoSource
}

});

I420Frame{

int width;
int height;
int[] yuvStrides;
ByteBuffer[] yuvPlanes;
boolean yuvFrame;
float[] samplingMatrix;
Int textureId;
Long nativeFramePointer;
Int rotationDegree;

}
經過繪製yuvPlanes[]或texureId能夠獲得圖像。

根據須要將RemoteVideoSource的圖像綁定在錨點上，就跟demo同樣，實現AR效果。

總結

1.再次領教了google強大的技術整合能力。

利用學術界，工業界現有的成果，結合各方面資源整合出ARCore。

2.目前市場上支持ARCore的手機不多

國內除了新發的小米MIX2S，P20，oneplus5還沒看到其餘機型。
google後邊應該會放開機型的管制，可是看ARCore目前的發展，這個時間可能比較長，做爲手機廠商應該等不到那個時候，18年確定有不少AR或ARCore手機冒出來。

3.ARCore缺點：

不能識別沒有紋理的表面（這個不能優化，VIO決定的）
不能識別豎直的表面（這個google解決了後邊會說到）
飄移感，大幅度移動，距離較遠場景下（能夠優化）
單目相機能夠得到精確的尺度，可是初始化時間較長，識別平面，特徵點時間較長（雙目沒有機器，因此沒有數據）（能夠優化）
沒有多人數據共享的解決方案（這個google已經解決了後邊會說到）

4.不支持前置相機

這個不能算缺點，由於如今ARCore只支持識別平面，很難在人臉上識別特徵點。並且前置相機開啓人老是擋在前邊，不是ARCore關注的場景。因此市面上流行的錄像或即時通信的人臉貼圖用ARCore不是最佳實現方案。
對於系統廠商應該能夠欺騙ARCore獲得想要的前置相機效果，實現的難度取決於ARCore使用相機的方式，還涉及到一些相機參數的標定，先後相機的參數確定是不同的，支持前置的意義能夠討論。

5.ARCore目前的開發學習成本較高

主要是圖形知識，3D模型，opengl等好比高級光照的一些處理等等。
我認爲google下一步會拿出方案下降開發學習成本，也許下一個版本就有免費全家桶了。也許會有一些第三方的團隊提供ARCore套餐，這個須要比較強的團隊實力和時間，免難免費就很差說了。

6.可能手機廠商還要關心的是

與google集成完camera，IMU等數據，後續本身是否還能夠繼續提高，如何作，如何綜合客觀精確評價提高的效果，會不會優化出兼容性問題，有沒有相似於cts，gts這樣的case保證兼容性。
這些問題目前在internet上找不到相關答案，也許只有google本身知道。

7.AR雲

（1）多我的如何融入同一個場景，信息徹底同步。
（2）更有深度的，這個AR雲能夠理解爲現實世界的1:1模型，徹底覆蓋在實體世界之上，可由機器讀取。而咱們的AR設備則是虛擬和現實世界的實時交互界面。咱們的AR設備是這個平行虛擬世界的實時界面，它完美地覆蓋了現實世界。

8.雖然過了preview階段，可是目前還處在完善開發工具的階段

能夠做爲賣點讓市場狂歡，做爲從業人員現階段要抱着理性的心態，腳踏實地不抱有太高的指望，尤爲是還沒弄清楚AR是什麼，AR的意義是什麼的時候。
任何AR應用存在的惟一緣由（與普通的智能手機應用程序相比）是它與現實世界有某種互動或聯繫。

在這個調研完不到兩週，google ARCore又有大動做。

這也打亂了既定學習計劃和技術路線。

ARCore升級至1.2.0

回答了部分咱們以前提出的應用層面的問題，好比不能識別垂直的表面，AR cloud等，開始考慮應用場景，增長了圖像加強的功能。

在以前預測，google ARCore團隊會在下降渲染引擎的開發學習成本方面給出方案

果真，推出了Sceneform SDK簡化渲染引擎的開發學習成本，可是咱們沒想到它來的這麼快。
由於咱們也在這方面作了一些探索工做，嘗試將ARCore和rajawali結合生成一套更加簡化的API。
Rajawali也是google用java語言開發的一個渲染引擎，它封裝了opengles的api，並且內置了不少3D模型的解析，矩陣運算等模塊，擴展了surfaceview實現render，也能夠嵌入Android GLSurfacView。它的核心是Scene，Object3D，Renderer, SurfaceView(extends android surfaceview)等。
學習Sceneform後感受不少思想概念跟Rajawali相似，推斷它是基於rajawali開發的。

加入了更多手機

包括不少國內的手機，華爲，小米，聯想，一加(oppo)等。

Rajawali + ARCore實踐

下降學習開發成本

github:稍後會放到github上

Arcore 1.2.0

augmented image:圖像加強

enables ARCore apps to detect and track images.
AugmentedImage，描述了加強圖像在現實世界的最佳狀態
AugmentedImageDatabase，database, up to 1000 images, build tool arcoreimg demo

cloud anchor（錨點雲）

Anchor cloud on google servers
cloud free now
Keep data for 7 days on the cloud
arcore cloud block by the great wall? don’t know yet.
sync anchors not objects，同步的是錨點不是物體
使用anchor cloud的多個設備或用戶必須在同一場景下，也就是全部用戶要聚在一個可能最多100平方米的場景內。極端的例子，用戶在不一樣的地點但類似甚至同樣的場景下？？？
firebase realtime database, for syncing room code and cloud anchor id, it deepens on GMS and blocked by the great wall.
Quotas
Quota type Maximum Duration Applies to
Number of anchors Unlimited N/A Project
Anchor host requests 30 minute User and project
Anchor resolve requests 300 minute User and project
畫了張圖

google arcore usage team demo

vertical plane

HORIZONTAL_DOWNWARD_FACING
HORIZONTAL_UPWARD_FACING
VERTICAL

Sceneform 1.0.0

Sceneform是google ARCore團隊開發的一套API，爲了簡化ARCore應用渲染引擎的開發學習成本，開發者能夠不用瞭解OpenGLES的API便可進行開發。

Sceneform is an render engine for ARCore

the relationship between Sceneform and ARCore

核心模塊

ArFragment

ArSceneView

Renderable

它是一個3D模型，由網格meshes，材料materials，和紋理textures組成，它能夠被Sceneform渲染在屏幕上。
Sceneform提供了3種方式建立Renderable：
(1).standard Android widgets
(2).basic shapes/materials
(3).3D assert files, support OBJ,FBX,glTF

Scene

每一個ArSceneView都綁定了一個Scene。Scene是一個樹狀的數據結構，包含了不少Nodes，這些Nodes就是要被渲染的虛擬物體。

Node

一個Node表明了在scene圖層的一個變換transformation。每一個Node包含一個Renderable，它包含了Sceneform渲染須要的全部信息，包括它的位置，方向orientation和Renderable object.

與Scene交互

(1).觸摸
(2).手勢
(3).客製化nodes，利用Node的生命週期
(4).動畫nodes，利用Node的生命週期
(5).燈光Lights，能夠爲每一個Node指定
(6).陰影Shadows，在Sceneform裏有的objects能夠廣播shadows有的objects接收shadows，一個object能夠同時廣播和接收本身的shadows。

SFA

Sceneform Asset Definition, It points to the models and textures in your source asset and also defines materials by providing material parameters for Sceneform’s physically-based materials.

SFB

Sceneform Binary asset，是SFA編譯生成的結果。

demo

4個Android platform渲染方案比較

android platform渲染方案技術路線從接觸ARCore開始一直在主動變動

(1).opengl es

這不用多說，android平臺圖形3D渲染接口
優勢：原生接口，經驗可複製到其餘平臺
缺點：學習開發成本較高

(2).rajawali

google開發的渲染引擎，封裝了opengl es，抽象了一些opengl的概念
優勢：簡化了學習開發難度，基於opengl es，java編寫，android平臺通用
缺點：java編寫，限於android平臺，經驗不可複製到其餘平臺
核心機制：scene, object3D,surfaceview,renderer

(3).the third party

接觸評估的一個第三方商業方案，技術上分析它是rajawali的變種或再封裝，看它的核心機制
核心機制：XXsceneplay,XXwidget,XXSurfaview
優勢：簡化了學習開發難度，基於rajawali（在android平臺，推測）；並且有ios的版本API，開發流程基本同樣，經驗能夠複製到其餘平臺
缺點：接入；商業方案，money,money,money錢能解決的都不是問題，可是錢是個問題；第三方的技術實力，簡單評估並無暴露的問題，好比和ARCore,以及android的整合是否完美，更新速度是否跟得上google的速度

(4).sceneform

google爲ARCore開發的渲染引擎，技術上分析它也是rajawali的變種或封裝開發，卡它的核心機制
核心機制：scene,node and renderable,ArSceneView
優勢：簡化學習開發成本，基於rajawali（推測），ARCore官方，與ARCore配合較好坑應該少一些，與anroid的view,widget等結合的很好，google技術實力強大，新能力迭代更新速度快
缺點：只有 android平臺，經驗不能夠複製到其餘平臺