Unity详细介绍AR开发设计工具MARS

　　(映维网 2020年01月07日)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充当从可用特征集导航到应用程序所需的完整集合的桥梁。