unity 框架设计
We set out to build workflows that give creators the ability to make AR applications that work the way we want them to: context-aware, flexible, customizable, functional anywhere and with any kind of data – without requiring tons of code.
我们着手构建工作流，使创建者能够按照自己希望的方式制作AR应用程序 ：上下文感知，灵活，可自定义，可在任何地方使用任何类型的数据进行操作-无需大量代码。
As we near the release of Unity MARS this year, we wanted to share the backstory of how and why we’re building this work environment and companion apps – which we believe are a major step toward ushering in the next generation of spatial, contextual computing across experience levels.
在我们今年即将发布 Unity MARS时 ，我们想分享有关如何以及为何构建此工作环境和配套应用的故事，我们认为这是迈向下一代空间，上下文计算的重要一步跨经验水平。
引发Unity MARS的问题 (The question that spawned Unity MARS)
How could AR make better sense in Unity? Real world and application coordinate frames rarely align. Developers need a tool that allows them to author precisely for an uncertain world. This tool would need to accommodate a variety of situations with “fuzzy” placement rules.
AR如何在Unity中变得更有意义？ 现实世界和应用程序坐标系很少对齐。 开发人员需要一种工具，使他们能够针对不确定的世界进行准确的创作。 该工具将需要使用“模糊”放置规则来适应各种情况。
To get there, our answer is breaking one large coordinate system into a series of small ones. Each represents a known space. These spaces then procedurally adapt to reality. The solution is symbiotic: the aspects of the real world we base our content on also define the bounds of our coordinate systems.
为了到达那里，我们的答案是将一个大坐标系分解为一系列小坐标系。 每个代表一个已知的空间。 然后这些空间在程序上适应现实。 解决方案是共生的：我们以内容为基础的现实世界的各个方面也定义了坐标系的边界。
We tested this idea during a Unity Labs hackweek, where we were able to create a multi-plane experience. This was unheard of a few years ago, and it’s still rare today without Unity MARS.
我们在Unity Labs黑客周期间测试了这个想法，在那里我们能够创建多平面体验。 这在几年前是闻所未闻的，而今天在没有Unity MARS的情况下仍然很少见。
Our solution was so effective that we wanted to make it possible to create even more ambitious AR experiences. This leads to more challenges. The development of Unity MARS has been a two-step cadence of question and answer ever since. Each step evolves what MARS can do, then pushes us to develop the platform further.
我们的解决方案是如此有效，以至于我们希望创造更加雄心勃勃的AR体验。 这带来了更多挑战。 从那以后，Unity MARS的发展一直是问答的两步节奏。 每个步骤都会演化出MARS的功能，然后推动我们进一步开发平台。
初步学习 (Initial learnings)
We identified several major challenges with AR development during that initial hackweek:
在最初的hackweek期间，我们发现了AR开发的几个主要挑战：
Describing the world digitally is an intense dependency graphing challenge. It requires a real-time database that continuously grows and gains new data types.
用数字方式描述世界是一个严峻的依赖图挑战。 它需要一个不断增长并获得新数据类型的实时数据库。
Game code and platform management do not mix well. The further we can keep these elements apart, the better.
游戏代码和平台管理不能很好地融合在一起。 我们可以将这些元素分开得越远越好。
We want users to write scripts that affect the layout of an entire AR scene – without knowing about the entire AR scene.
我们希望用户编写影响整个AR场景布局的脚本，而又不了解整个AR场景。
We also had core values we wanted Unity MARS to embody:
我们还拥有我们希望Unity MARS体现的核心价值观：
Feels like Unity – Our team’s motto is “Reality as a build target,” and we mean it quite literally. Unity MARS extends Unity to make it an Editor for reality, but it is still fundamentally Unity.
感觉像Unity一样 -我们团队的座右铭是“将现实作为构建目标”，我们的字面意思是。 Unity MARS扩展了Unity，使其成为现实的编辑器，但从根本上来说，它仍然是Unity。
Safe – Spatial computing is a new frontier, and users should feel safe exploring and experimenting there. Good development patterns should be frictionless.
安全 –空间计算是一个新领域，用户应该在此进行安全的探索和试验。 良好的发展模式应该毫无摩擦。
Welcoming to all developers– Any part of MARS should be tailored to the technical level of the developer we expect to use it.
欢迎所有开发人员– MARS的任何部分都应根据我们希望使用它的开发人员的技术水平进行定制。
These problems are complex and comprehensive, so their solution needed to be so complete and separate from the application logic that it felt invisible. The Unity MARS Data Layer was created to meet this challenge.
这些问题既复杂又全面，因此它们的解决方案必须如此完整，并且与应用程序逻辑分离，以至于看不到它们。 创建Unity MARS数据层就是为了应对这一挑战。
数据层 (Data Layers)
The Unity MARS Data Layer can be separated into four parts that combine to form a versatile abstraction of reality.
Unity MARS数据层可以分为四个部分，这些部分结合在一起形成一个通用的现实抽象。
| Proxy system |
| Query and Data Events |
| Data ownership |
| Data Description and Storage |
| 代理系统 |
| 查询和数据事件 |
| 资料拥有权 |
| 数据描述和存储 |
Our base is a digital description of the world. Semantics are the foundation of our universal AR language, and traits applied to surfaces like ‘floor’ and ‘wood’ are simple semantics.
我们的基地是对世界的数字描述。 语义学是我们通用AR语言的基础，应用于“地板”和“木材”等表面的特征是简单的语义。
Spatial semantics model something generic that can adapt to many variations in the real world. Let’s use a face as an example – there are many different shapes and sizes. Authoring AR content for a face would involve knowing which part of a body is the face and where the eyes are. Every face is different, but by targeting these pieces of data the content can adapt. The true power of Unity MARS (and AR) comes when you move from authoring against specific low-level data into this higher-level semantic realm.
空间语义学为可以适应现实世界中许多变化的通用事物建模。 让我们以一张脸为例–有许多不同的形状和大小。 为面部创作AR内容将涉及知道身体的哪一部分是面部以及眼睛在哪里。 每个面Kong都是不同的，但是通过针对这些数据片段，内容可以适应。 当您从对特定的低层数据的创作转移到此高层语义领域时，Unity MARS(和AR)的真正威力就来了。
Data ownership is layered on top. For digital content to coexist with the world, there needs to be clear boundaries about what data is available. Data ownership allows aspects of the real world to be reserved for content – automatically. Managing the ideal arrangement of real-world data to digital content can be an impossible problem for application developers, but it’s solved by the Unity MARS Data Layer.
数据所有权位于顶层。 为了使数字内容与世界共存，需要确定可用数据的界限。 数据所有权允许 自动 为内容保留现实世界的各个方面 。 对于应用程序开发人员来说， 管理现实世界中的数据到数字内容的理想安排可能是一个不可能的 问题，但Unity MARS数据层已解决了这一问题。
Unity has a consistent pattern for data access in AR. Events are raised when data is detected, updated, or lost. The Query and Data Events system takes this concept to a higher level. Users set up queries, which are specified combinations of data and values. The Unity MARS Data Layer then raises acquire, update, and lost events. This means that instead of knowing that just any plane was found, a user can know when a plane of the specified size, orientation, and light level was detected. Remember that Unity MARS data storage is designed to dynamically work with new custom types of data. This means that users can get events for literally any kind of scenario, regardless of how complex it is.
Unity在AR中具有一致的数据访问模式。 当检测，更新或丢失数据时引发事件。 查询和数据事件系统将这一概念带入了更高的层次。 用户设置 查询， 这些 查询 是数据和值的指定组合。 然后，Unity MARS数据层会引发 Acquisition ， Update 和 Lost 事件。 这意味着用户可以知道何时检测到具有指定大小，方向和光照水平的平面，而不是仅发现任何平面。 请记住，Unity MARS数据存储旨在动态处理新的自定义类型的数据。 这意味着用户可以在几乎任何情况下获得事件，无论它有多复杂。
At the very top of this structure is the proxy system. The proxy system represents the physical world with Unity objects. It automatically handles the conversion of this native Unity representation into queries. The AR proxy objects are hooked up to data events to give them an object lifecycle that matches purely digital Unity content.
此结构的最顶层是代理系统。 代理系统使用Unity对象代表物理世界。 它会自动处理此本地Unity表示形式到查询的转换。 AR代理对象连接到数据事件，以为它们提供与纯数字Unity内容匹配的对象生命周期。
每种开发人员类型的数据 (Data for every developer type)
MARS Data needs to work for every AR developer. We’ve organized them into three core groups:
MARS Data需要为每个AR开发人员工作。 我们将它们分为三个核心组：
Designers, who have no interest in the minutiae of the data and want to create new AR apps in the semantic and visual context of the real world.
设计师对数据的细节不感兴趣，希望在现实世界的语义和视觉环境中创建新的AR应用程序。
Providers, who add novel data to the AR ecosystem through cutting-edge hardware and software techniques.
提供商，他们通过尖端的硬件和软件技术向AR生态系统添加新数据。
Engineers, who make clever use of data and interaction to bridge the gap between a designer’s vision and a provider’s data.
工程师，他们巧妙地利用数据和交互作用来弥合设计师的愿景与提供商的数据之间的鸿沟。
Each group has a specialized way to interact with the Unity MARS Database. This way, each developer type can interact with the others while each benefiting from an experience tailored to their own needs and workflow.
每个小组都有与Unity MARS数据库进行交互的专用方法。 这样，每种开发人员类型都可以与其他开发人员进行交互，同时每种开发人员都可以从针对自己的需求和工作流定制的经验中受益。
Unity MARS数据提供者 (Unity MARS Data providers)
Providers work exclusively with the Data Storage and Description features of the Unity MARS Data Layer. As you can see from the architecture above, Unity MARS is hungry for external data and functionality. Providers are given a simple API to work with, consisting of just a few functions to add, update and remove data of any type. Providers can add multiple types of data, such as orientation, position, rotation, color, light, and roughness, then associate them together.
提供者专门使用Unity MARS数据层的数据存储和描述功能。 从上面的架构可以看到，Unity MARS渴望外部数据和功能。 提供者可以使用一个简单的API，该API包括一些用于添加，更新和删除任何类型数据的函数。 提供者可以添加多种类型的数据，例如方向，位置，旋转，颜色，光和粗糙度，然后将它们关联在一起。
Here is an example of how AR Foundation planes are piped into Unity MARS:
这是如何将AR Foundation平面通过管道传输到Unity MARS的示例：
|
1
2
3
4
5
6
7
8
9
10
|
void AddPlaneData(MRPlane plane)
{
var id = this.AddOrUpdateData(plane);
this.AddOrUpdateTrait(id, TraitNames.Plane, true);
this.AddOrUpdateTrait(id, TraitNames.Pose, plane.pose);
this.AddOrUpdateTrait(id, TraitNames.Bounds2D, plane.extents);
this.AddOrUpdateTrait(id, TraitNames.Alignment, (int)plane.alignment);
if (planeAdded != null)
planeAdded(plane);
}
|
|
1
2
3
4
5
6
7
8
9
10
|
void AddPlaneData ( MRPlane plane )
{
var id = this . AddOrUpdateData ( plane ) ;
this . AddOrUpdateTrait ( id , TraitNames . Plane , true ) ;
this . AddOrUpdateTrait ( id , TraitNames . Pose , plane . pose ) ;
this . AddOrUpdateTrait ( id , TraitNames . Bounds2D , plane . extents ) ;
this . AddOrUpdateTrait ( id , TraitNames . Alignment , ( int ) plane . alignment ) ;
if ( planeAdded != null )
planeAdded ( plane ) ;
}
|
It’s important to note that the provider interface uses a functionality injection pattern. By decoupling the API from implementation, we are able to easily switch between data sources. This is critical for data simulation and playback while authoring.
重要的是要注意，提供程序接口使用功能注入模式。 通过将API与实现分离，我们可以轻松地在数据源之间切换。 这对于创作时的数据模拟和回放至关重要。
Providers are required to list which data they add to the system in the class definition. This is the trait list for the Unity MARS plane provider:
提供者需要在类定义中列出他们添加到系统的数据。 这是Unity MARS平面提供者的特征列表：
|
1
2
3
4
5
6
7
|
static readonly TraitDefinition[] k_ProvidedTraits =
{
TraitDefinitions.Plane,
TraitDefinitions.Pose,
TraitDefinitions.Bounds2D,
TraitDefinitions.Alignment
};
|
|
1
2
3
4
5
6
7
|
static readonly TraitDefinition [ ] k_ProvidedTraits =
{
TraitDefinitions . Plane ,
TraitDefinitions . Pose ,
TraitDefinitions . Bounds2D ,
TraitDefinitions . Alignment
} ;
|
By having this data available at compile-time, we can see exactly what data is available to our application on each platform. This lets us know whether an application will function, or if it needs additional support scripts in the form of Reasoning APIs.
通过在编译时提供这些数据，我们可以确切地看到每个平台上的应用程序可以使用哪些数据。 这使我们知道应用程序是否可以运行，或者是否需要其他推理脚本形式的支持脚本。
应用工程师 (Application engineers)
AR engineers often have to reason about the world with incomplete or unexpected data. Consider this simple example: an application that displays an educational graphic around a statue. Object recognition for the statue will be available on some devices, while image markers can be used on others. Relocalization to a space that has the statue’s location pre-authored in it is available on yet another platform.
AR工程师经常不得不用不完整或意外的数据来推理世界。 考虑一个简单的例子：一个在雕像周围显示教育图形的应用程序。 雕像的对象识别将在某些设备上可用，而图像标记可在其他设备上使用。 在另一个平台上可以重新定位到预先拥有雕像位置的空间。
This example no longer seems so simple. Let’s add some more complications: what happens if a user views a picture of the statue? Or a small-scale replica? What about users who want the experience but don’t have access to the statue? What about users in VR?
这个例子似乎不再那么简单。 让我们增加更多的复杂性：如果用户查看 雕像 的 图片 会怎样？ 还是小规模的复制品？ 想要体验但无法访问雕像的用户该怎么办？ VR中的用户呢？
It’s possible to make an application that can handle a subset of all of these scenarios and contingencies. In the past, this might have been the only solution to create this kind of AR experience, but it’s not a good one. The resulting scene would be a confounding web of objects and fragile fallbacks with application logic, platform abstraction, and world analysis all mixed together. Platform-specific problems are common, and debugging is difficult at best.
可以使一个应用程序能够处理所有这些情况和突发事件的子集。 过去，这可能是创建这种AR体验的唯一解决方案，但这并不是一个 好的方法 。 由此产生的场景将是一个混杂的对象网络和脆弱的后备状态，其中应用程序逻辑，平台抽象和世界分析混合在一起。 特定于平台的问题很常见，并且最多很难进行调试。
Reasoning APIs are the solution: these are scripting interfaces that provide engineers with the power and knowledge to handle all of these complex scenarios. Unity MARS handles the logic of when these scripts are needed. The list of traits supplied by available providers is combined with the list of traits required by Unity MARS content to determine which reasoning APIs most efficiently bridge the gap. In a case where there is no suitable reasoning API available, we can alert the developer to this fact.
推理API是解决方案：这些脚本脚本接口为工程师提供了处理所有这些复杂场景的能力和知识。 Unity MARS处理何时需要这些脚本的逻辑。 可用提供者提供的特征列表与Unity MARS内容所需的特征列表结合在一起，以确定哪些推理API最有效地弥合了差距。 如果没有合适的推理API，我们可以提醒开发人员这一事实。
The reasoning API interface interacts with the Data Storage and Description feature of Unity MARS. Reasoning APIs are given the ability to access entire lists of Unity MARS data at once, such as an entire list of vertically sorted planes, for example.
推理API接口与Unity MARS的数据存储和描述功能进行交互。 推理API可以一次访问Unity MARS数据的整个列表，例如垂直排序平面的整个列表。
Reasoning APIs use the same function calls as data providers to add, update, and remove data. This means Unity MARS can mix and match data from reasoning APIs and hardware providers. The gap in functionality is filled seamlessly without the application having to make any changes.
推理API使用与数据提供程序相同的函数调用来添加，更新和删除数据。 这意味着Unity MARS可以混合和匹配来自推理API和硬件提供程序的数据。 功能上的差距可以无缝填补，而无需应用程序进行任何更改。
设计者 (Designers)
We want to represent the properties of the real world in Unity as visual objects that users can reference. Visuals enable users to author and validate their digital content quickly. Object references allow Unity scripts and events to work with their existing game code without any additional scripting. This point is critical – we want Unity MARS to work with all Asset Store and other user packages without modification. Cross-compatibility is strongest when our workflows follow Unity’s best practices.
我们希望将Unity中现实世界的属性表示为用户可以引用的视觉对象 。 视觉使用户能够快速创作和验证其数字内容。 对象引用使Unity脚本和事件 无需任何其他脚本即可 与它们现有的游戏代码一起 使用 。 这一点很关键–我们希望Unity MARS无需修改即可与所有Asset Store和其他用户软件包一起使用。 当我们的工作流程遵循Unity的最佳实践时，交叉兼容性最强。
Our object system is designed to be simple – complex structures are made by combining these simple pieces together in different ways. It is designed to be self-contained. It works in all the ways regular Unity objects do: directly in the scene view and in all types of Prefabs.
我们的对象系统设计得很简单–复杂的结构是通过将这些简单的片段以不同的方式组合在一起而制成的。 它被设计为独立的。 它以常规Unity对象所做的所有方式工作：直接在场景视图和所有类型的Prefab中。
The three components that make up Unity MARS content are the Proxy, ProxyGroup, and Spawner. We go into more detail about these objects here.
组成Unity MARS内容的三个组件是Proxy，ProxyGroup和Spawner 。 我们 在这里 详细介绍这些对象 。
A Proxy defines a single object in AR – this is the limit of most AR toolsets. ProxyGroups allow users to describe scenarios where multiple things in the real world must relate in some way. No other AR authoring experience offers this functionality. It is an incredibly complex problem to solve algorithmically, which is why we created the Unity MARS Data Layer to handle it for you. The last component is the Spawner. Spawners are objects that contain a Proxy or ProxyGroup and duplicate them repeatedly, transforming them into a ruleset that reskins your entire reality.
代理 在AR中定义了一个对象–这是大多数AR工具集的限制。 ProxyGroups 允许用户描述现实世界中必须以某种方式关联多个事物的场景。 没有其他AR创作经验可以提供此功能 。 通过算法解决这是一个非常复杂的问题，这就是为什么我们创建Unity MARS数据层来为您处理它的原因。 最后一个组件是Spawner。 生成 者是包含Proxy 或ProxyGroup 并重复复制它们的 对象 ，将它们转换为重新呈现您整个现实的规则集。
从上到下 (From the top down)
We’ll recap how everything fits together by referring back to the layer diagram:
我们将通过回顾图层图来概述所有内容如何组合在一起：
All Proxy, ProxyGroup, and Spawner components are authored by designers. They create queries and respond to events.
所有Proxy，ProxyGroup和Spawner组件均由设计人员编写。 他们创建查询并响应事件。
Queries search the database for matches and control ownership.
查询在数据库中搜索匹配项并控制所有权。
Reasoning APIs and Providers add and remove data from the database.
推理API和提供程序从数据库中添加和删除数据。
Each aspect of the data layer comes together similarly to ensure the best experience on every platform.
数据层的每个方面都类似地组合在一起，以确保在每个平台上获得最佳体验。
Providers define the set of traits available to an application.
提供者定义应用程序可用的特征集。
Reasoning APIs act as bridges to navigate from the set of available traits to the full collection an application requires.
推理API充当从可用特征集导航到应用程序所需的完整集合的桥梁。
We are beyond excited to see the boundary-pushing applications that users will be able to create with Unity MARS. With your help, we will continue to push spatial computing even farther. If you’re interested in learning about Unity MARS and receiving the latest news as we move toward a wider release, please sign up for updates and check out our new Unity MARS webpage.
我们很高兴看到用户将能够使用Unity MARS创建突破边界的应用程序。 在您的帮助下，我们将继续推动空间计算的发展。 如果您有兴趣了解Unity MARS并在我们向更广泛的发行版发布时收到最新消息，请 注册以 获取更新，并查看我们的新 Unity MARS网页 。
unity 框架设计
3240
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
