# 潛在問題-林彥廷

以下說明AR部分建置

Part I ARCore
用於偵測環境和收集相關數據用的google套件，理解其API非常重要，雲錨點的官方開發文件非常壟統，建議直接從實際案例下手(如其他開發者的專案)會比較容易上手。另ARCore的雲錨搭配Google Cloud Platform服務是最優解(截至2021/11/25)，其服務串接採用API KEY進行，雙邊都要設定服務(即GCP端輸入專案名稱，至於SHA-1指紋是否設定雖然是可選項目，但基本上建議設定，原因出於目前在未設定的狀況下(就是只用API KEY連接時)，雲錨存取時間只有1天且無法調整，所以調整設定是必要的。
未來ARCore可能會推出永續型的雲錨，屆時系統設定將能更完善，期待。

Part II Sceneform
渲染環境和物件使用的工具，簡化了大量的數學運算部分(如投影時的變形量牽涉的旋轉矩陣和投影矩陣的內積)，輕鬆完成影像呈現在AR場景中的工作。但在製作專題的過程中發現，Sceneform已不再被列入Google的維護名單，該項目已經存檔並開源，目前有一獨立開發社群在維護，雖然還有維護但其妥善率和效能已經不受開發者們青睞，甚至到了被遺忘的階段，未來若是繼續使用sceneform將會面臨更嚴峻的開發環境和偵錯時無法求助的窘境。替代的方案截至2021/11/25時共有兩種:
1. 更改繪製工具，使用filament替代sceneform。filament為開發者們在失去SCENEFORM後較常使用的工具，由於涉及不深因此無法做出太多評測，但推估應該是具有和Sceneform相同的特性(如避開投影計算問題等)，因此多數開發者推薦轉移到此工具上。
2. 將開發環境轉移到Unity:這種說法並非是空穴來風，因為渲染的動作對於Android Studio而言是較為複雜的部份，而Unity則完全迎合此問題，且多數開發AR APP的社群也極力推薦使用者轉為Unity環境。目前Unity環境可能無法和GCP直接結合，其替代的方案很可能為微軟旗下的Azure Spatial Anchor，功能與ARCore的雲錨相似，只是其開發難度不亞於ARCore + Sceneform的組合。建議更早著手於相關技術的研究。
以上方法提供參考。當然當初開發時為了實現不加入平面圖之特色而做了相當的取捨，這點對於使用工具而言或多或少造成限制。
邏輯地圖與錨點規劃:當初在設計時，預設了使用者完全按照箭頭之指向進行前進，但仔細思考後會發現對於墨菲定律的消弭採取非常消極的態度，這點對於系統的完整和便利性添上了一絲不確定，因此更正錯誤歸正的功能勢必得加入改良方案內。初步構念為以導航信標之距離判定，但缺乏的是若使用者只是稍微偏離也有錯誤歸正訊息恐怕是矯枉過正，因此二次修正為若偵測到非路線點上的導航信標且數量大於N，此時判定為「標準錯誤移動」，系統的引導箭頭則不再往下一導航點前進，轉而將使用者導回離開正確路徑時的最後一個點。但此做法也存在不完美之處，動態修正路徑應是必要且必須的，若是回到最後路徑點可能會有多走的可能，但動態修正的難度非常難以預測，且牽涉到路徑點該朝哪一位進行設定，進而造成此問題為結構性乃至設計上大幅變動的決定，事前可能需要非常大量的測試去嘗試動態修正路徑的功能。