Mixed and Augmented Reality Studio（MARS）是Unity於2018年發布的用於設計AR應用程式的環境。對日前，Unity資深軟體工程師安德魯·馬內尼（Andrew Maneri）撰文介紹了這款工具，並希望通過一套特定的流程框架來為創作者提供幫助，無需成噸的代碼即可構建靈活，可定製，情景感知的AR應用程式。下面是映維網的具體整理：
隨著我們即將在今年為社區正式帶來MARS，我們希望介紹我們是如何和為何要構建這個工作環境及相關應用程式。我們相信，它們是我們邁向下一代空間情景計算的重要一步。
1. MARS因何而生
AR在Unity中如何能夠更有意義呢？現實世界和應用程式坐標系少有對齊，所以開發者需要一種允許它們夠針對非確定世界進行準確創作的工具，並通過「模糊」放置規則來適應各種情況。
為了做到這一點，我們提出的答案是將一個大坐標系分解為一系列的小坐標系，其中每一個代表一個已知的空間。然後所述空間能夠程序性地地適應現實。這是一種共生的解決方案：作為我們內容基礎的現實世界的各個方面同時定義了坐標系的邊界。
我們在Unity Labs Hackweek期間測試了這個想法。我們當時創建了一個多平面體驗，而這在幾年前是聞所未聞的事情，並且在缺少MARS的情況下依然少見。
我們的解決方案非常有效，所以我們希望再進一步。當然，這提出了更多的挑戰。從那時起，MARS的開發一直是問與答的兩步節奏，而每個步驟都會演化出MARS的各個功能，並推動平台的進一步開發。
2. 一開始
我們在Hackweek的早期就確定了AR開發的數個主要挑戰：
用數字方式描述世界是一個嚴峻的圖形挑戰。它需要一個不斷增長並獲得全新數據類型的實時資料庫。遊戲代碼和平台管理無法完美地融合在一起。彼此分開越遠越好。我們希望用戶編寫能夠影響整個AR場景布局的腳本，同時又無需知曉整個AR場景。
我們同時希望MARS能夠體現下面的核心價值：
感覺像是Unity：我們團隊的座右銘是「將現實作為目標」，這裡不存在任何言外比喻。MARS擴展了Unity，使其成為了現實世界的編輯器。但從根本意義來說，它依然是Unity。安全：空間計算是一個新領域，用戶應該能夠在這裡進行安全的探索和實驗。歡迎所有開發者：MARS的方方面面應該能夠支持不同技術水平的開發者。
上述問題十分複雜且涉及面廣，所以它們的解決方案同樣需要完整，並且與應用程式邏輯分離，以至於感覺無形無影。創建MARS Data Layer（數據層）就是為了應對這一挑戰。
2. 數據層
我們的基礎是對世界的數字描述。語義是我們通用AR語言的基礎，而應用於「地板」和「木材」等表面的特徵是簡單的語義。
空間語義用於為適配現實世界中的眾多變化的通用對象建模。以面容為例，人臉存在不同的形狀和尺寸。為面部創作AR內容將涉及確定哪一部分是面部，以及雙眼在哪裡。每個面容都是不盡相同，但通過針對特定的數據片段，內容可以予以適配。 當你從針對底層的數據進行創作轉換至語義領域時，MARS（和AR）的真正威力就將呈現出來。
Data Ownership（數據所有權）位於上方。為了確保數字內容與世界共存，我們需要確定可用數據的界限。Data Ownership允許自動為內容保留現實世界的各個方面。對於應用開發者來說，現實世界數據到數字內容的理想安排管理或許是一個不可能的任務，但MARS Data Layer已經予以解決。
Unity在AR中具有一致的數據訪問模式。當檢測，更新或丟失數據時，事件就會引發。Query and Data Events（查詢和數據事件）系統將這一概念帶入了更高的層級。用戶可以設置查詢（數據和值的指定組合）。然後，MARS Data Layer會引發獲取，更新和丟失事件。這意味著用戶可以知道何時檢測到具有指定大小，方向和光照水平的平面，而不是僅僅發現任何平面。請記住，MARS數據存儲旨在動態處理新的自定義類型數據。這意味著無論複雜程度幾許，用戶都可以在幾乎任何情況下獲取事件。
這一結構的最上方是Proxy System（代理系統）。Proxy System使用Unity對象代表物理世界。它會自動處理這個本地Unity表示形式到查詢的轉換。AR代理對象連接到數據事件，從而為它們提供與純數字Unity內容匹配的對象生命周期。
Data Layer可以分成四個方面，並一起組成現實的通用抽象層。
3. 適用於各種開發者類型的數據
MARS Data需要支持每位AR開發者。我們將它們分為三個核心組別：
設計師：對數據的細節不感興趣，只希望在現實世界的語義和視覺環境中創建新的AR應用程式。供應者：通過尖端的硬體和軟體技術來為AR生態系統添加新數據。工程師：巧妙地利用數據和交互來彌合設計師願景與供應商數據之間的鴻溝。
每個小組都有與MARS資料庫進行交互的專用方法。這樣，每個開發者類型都可以與其他人進行交互，並從針對自己需求和工作流程的經驗中受益。
3.1 MARS數據供應者
供應者主要是利用MARS Data Layer的Data Storage and Description（數據儲存和描述）功能。我們從上面的結構可以看到，MARS渴望外部數據和功能。供應者可以使用一個包含用於添加，更新和刪除任何類型數據的函數的簡單API。供應者可以添加多種類型的數據，如方向，位置，旋轉，顏色，光和粗糙度，然後將它們關聯在一起。
下面是一個將AR Foundation平面整合至MARS的示例：
需要注意的是，供應者介面採用功能注入模式。通過將API與實現分離，我們可以輕鬆地在數據源之間切換。這對於創作時的數據模擬和回放至關重要。
供應者需要在類定義中列出添加到系統的數據。下面是MARS平面供應者的一個特徵列表：
通過在編譯時獲取所述數據，我們可以確切地看到每個平台的應用程式可以使用哪些數據。這樣我們就可以知道應用程式是否可以運行，或者是否需要其他Reasoning API形式的支持腳本。
3.2 應用工程師
AR工程師經常需要使用不完整或意料之外的數據來推理世界。舉一個簡單的例子：一個圍繞雕像顯示教育性圖形內容的應用程式。雕像的對象識別只支持特定設備，圖像標記則支持其他設備，而重新定位空間的功能則存在於另一個平台。
我們不妨增加更多的複雜性：如果用戶查看雕像的圖片？查看一個小型複製品？想要體驗但無法訪問雕像又如何？VR中的用戶呢？
你確實可以構建一個能夠處理上述所有情況和突發事件的子集的應用程式。這在過去可能是創造這種AR體驗的唯一解決方案，但不是一個好方法。由此產生的場景將是一個混雜的對象網絡，應用邏輯，平台抽象層和世界分析混雜在一起。特定於平台的問題十分常見，而且調試難度最大。
Reasoning API是解決方案：這種腳本接口為工程師提供了處理所有複雜場景的能力和知識。
MARS處理何時需要這種腳本的邏輯。供應者提供的特徵列表與MARS內容所需的特徵列表能夠結合起來，從而確定哪些Reasoning API最有效彌合了差距。如果沒有合適的 Reasoning API，我們可以提醒開發者這一事實。
這個Reasoning API介面配合MARS的Data Storage and Description功能。Reasoning API可以一次訪問整個MARS數據列表，例如垂直排序平面的整個列表。
Reasoning API使用與數據供應者相同的函數調用來添加，更新和刪除數據。這意味著MARS可以混合併匹配來自Reasoning API和硬體提供者的數據。功能方面的差距可以無縫填補，無需應用程式進行任何更改。
3.3 設計師
我們希望將Unity中現實世界的屬性表示為用戶可以引用的視覺對象。視覺允許用戶能夠快速創作和驗證其數字內容。對象引用使得Unity腳本和事件無需任何其他腳本即可與它們現有的遊戲代碼一起配合。這一點十分關鍵，因為我們希望MARS無需修改即可與結合所有Asset Store和其他用戶軟體包一起使用。當我們的工作流程遵循Unity的最佳實踐時，交叉兼容性就會達到最強狀態。
我們的對象系統設計得十分簡單。複雜的結構是通過將簡單的片段以不同方式組合在一起。我們將其設計為獨立一體化，並以常規Unity對象的方式生效：直接體現在場景視圖和所有類型的Prefab中。
組成MARS內容的三個組件是Proxy, ProxyGroup和Spawner。
Proxy定義AR中的一個對象，這是大多數AR工具集的限制。ProxyGroups允許用戶描述現實世界中必須以某種方式關聯多個事物的場景。沒有其他AR創作工具可以提供這種功能。通過算法解決是一個非常複雜的問題，而這正是我們創建MARS Data Layer的原因。最後一個組件是Spawner，它是包含Proxy或ProxyGroup並重複複製它們，將它們轉換為可重新呈現你整個現實的規則集的對象。
4. 從上到下
我們最後回顧一下上面介紹的內容：
所有Proxy，ProxyGroup和Spawner組件均由設計者編寫。他們創建查詢並響應事件。查詢在資料庫中搜索匹配項並控制所有權。Reasoning API和供應者在資料庫中添加和刪除數據。
Data Layer的每個方面都以類似的方式組合在一起，從而確保每個平台都能實現最佳體驗。
場景中的MARS代理對象定義了應用程式運行所需的特徵集。供應者定義應用程式可用的特徵集。Reasoning API充當從可用特徵集導航到應用程式所需的完整集合的橋樑。
在你的幫助下，我們將繼續推動空間計算的進一步發展。如果你有興趣了解MARS，請前往這個頁面註冊獲取最新消息，並關注我們最新的Project MARS官網。
原文連結：https://yivian.com/news/70679.html