Meta分享：如何为Quest 3设计、研发MR体验《初次相遇》

查看引用/信息源请点击：映维网Nweon

在《First Encounters》使用和扩展场景锚点和场景网格的经验

（映维网Nweon 2023年12月06日）所有Quest 3都预装MR体验《First Encounters》。日前，Meta团队的亚历山大·道森（Alexander Dawson）撰文介绍了他们是如何通过使用和扩展Scene Anchors场景锚点和Scene Mesh场景网格功能，从而构建异世界怪兽打破次元壁并走进你家里的MR体验。下面是具体的整理：

对于《First Encounters》，我们可以利用Scene Mesh（Unity | Unreal）的功能来设计一个更具交互性的体验。我们扩展了之前在《Discover》和《Phantom》利用场景锚点和场景网格的理念，构建了一个允许怪兽“砸碎”家中墙壁，并从它们的世界走向你的世界的核心机制。

希望我们在《First Encounters》使用和扩展场景锚点和场景网格的经验可以帮助你加速你的开发旅程，我们开发这个功能所获得的见解可以帮助你构建类似的MR体验。

场景设置

《First Encounters》是为了展示MR在Quest 3中可以解锁的体验类型。尽管我们会在玩家的空间中引入幻想元素，但我们希望确保体验的每个环节都足够真实，有基础，并且具有逼真的交互。为了令游戏感觉无缝且引人入胜，任何新元素都必须成为玩家世界的一部分。

为了实现这一点，我们广泛使用了Scene API（Unity | Unreal| OpenXR | WebXR |）。场景锚点提供了根据标记原语来理解用户空间的能力，最基本的是墙壁、地板和天花板。这三个原语可以通过所述API表示为简单的平面，通过查询平面可以实现用户空间的快速基本分解。场景网格则通过提供用户房间的扫描三角形网格来进一步扩展了我们的理解，它可以更好地近似物理空间。

通过对场景网格的材质应用Passthrough着色器，用户会看到房间保持正常，直到我们开始在网格打洞。

Unity中的原型制作

为了在保证一致性的同时允许实验机制，我们决定在场景网格中打真正的孔洞，而不是使用着色器在视觉上伪造孔洞：

• 投射光线来确定场景网格要打洞的点

• 收集半径内所有顶点的三角形

• 将三角形的顶点压扁到世界之外的固定位置

这种快速的naïve打洞算法非常适合原型设计，但当然存在很大的局限性。首先，产生的孔洞的视觉质量与我们所寻找的目标不匹配。由于场景网格中不一致的三角形大小和我们选择三角形的方式，这种方法有时会导致创建大而锯齿状的孔。使用Tessellator和Decimator为我们提供了在粉碎墙壁时平衡性能和视觉一致性的解决方案。

打洞方法避免了在调整网格大小时产生的额外工作，但它依然会触发Unity/PhysX再次cook物理网格。cook一个含有大量三角形的凹网格可能需要很长时间。在Unity中，默认的Mesh API使它成为一个停止世界的过程，但它可以在Jobs系统中并行化和异步化。

由于cook过程是Unity中的一个引擎端功能，减少修改时间及能够查询和显示最终网格之间的延迟需要进行预处理，或者减少网格大小。

评估现有解决方案

由于这个功能是我们游戏设计的核心，但在技术方面却存在巨大的未知，所以我们开始对现有的Unity包和网格破坏库进行多次调查。在进行了一定的评估之后，我们最终放弃了它们，原因如下:

• 网格破坏库通常需要凸网格或出于性能原因首选它们，而场景网格提供凹网格。

• 库通常假设网格是填充的卷，而不是空心的卷，而场景网格提供中空的网格。

• 库通常期望分解网格的低细节和三角形计数，并且对于高三角形计数的网格，性能会迅速下降。

• 任何需要网格在Unity编辑器中进行预处理的库都不能使用，因为场景网格在运行时对每个头显都是唯一的。

• 大多数库都是为桌面系统设计，而不是为Quest 3的MR游戏所必需的严格性能要求而设计。即便上述问题可以修复或解决，库中的核心性能问题都会妨碍交付流畅的体验。

定制系统

为了满足需求，我们显然需要一个定制系统。新的DestructibleMesh系统将通过使用Voronoi分区将场景网格三角形分类为子网格块来解决这个问题。子网格块可以在Unity中赋予自己的GameObjects，并在它们破坏时单独禁用。这允许我们能够将处理成本移至游戏开始阶段。

DestructibleMesh系统使用Unity的Jobs系统进行并行化，Burst编译器用于快速本地性能和SIMD矢量指令。为了对三角形进行排序，DestructibleMesh系统执行以下任务:

• 游戏为系统提供了一组点来定义Scene API平面的Voronoi单元格位置。这些点均匀分布，使用simplex noise来增加一定的随机性，同时保持点与点之间相对一致的距离（注意，完全随机分配点可能导致块非常大或非常小）。

• 系统首先通过比较三角形质心与定义Voronoi单元格位置的点阵列之间的平方距离来检查每个三角形属于哪个Voronoi单元格。每个Voronoi单元格位置的索引作为子网格ID，而系统根据分区方案对每个三角形进行标记，并赋予三角形所属的子网格。

• 如果三角形位于应该为Health & Safety预留的区域内，则系统将覆盖计算出的子网格所有者ID。保留区域算法决定删除三角形是否会导致玩家误撞环中，并分配一个特殊的所有者ID来将三角形分类到他们自己的网格中。下面将更详细地描述这个算法。

• 了解在哪里对每个三角形进行排序完成，迭代每个三角形，增加各自子网格的三角形计数，并将每个顶点添加到位图中，以跟踪要复制到最终顶点缓冲区的顶点。因为顶点可能在多个三角形之间共享，而这些三角形可能并不都在目标子网格中，所以我们只需要在必要的地方复制到最终顶点缓冲区。

• 已知每个子网格的三角形数量和顶点数量，我们的目标顶点和索引缓冲区可以为每个子网格保留。此时，我们遍历顶点映射并填充每个子网格的顶点缓冲区。

• 复制并更新每个三角形对应子网格索引缓冲区的索引。

• 在Jobs系统异步等待上述所有job完成。

• 使用相关的Mesh API提交并完成对Unity网格的更改。此时可以使用网格进行渲染。

• 在Jobs系统中cook制作PhysX网格。

• 异步等待cooking完成。从这一点开始，网格可以用于Physics，而不会产生最后一分钟停止世界处理步骤的风险。

注意，在上述步骤中，系统大量使用并行化、SIMD矢量指令、缓存高效的数据访问模式，以及减少或处理器可预测的分支。为了简单起见，具体的实现细节没有进行介绍。

预留一个安全的混合现实游戏空间

为了预留玩家房间的健康与安全区域，我们需要一个经过深思熟虑的方法。我们的目标是一个快速和普遍有效的解决方案，跨越各种房间布局，从而帮助防止场景网格破坏造成意外绊倒和碰撞危险。算法的工作原理非常简单:

• 假设我们房间的边界是一个自上而下的闭环二维多边形。这可以通过地板的OVRScenePlane组件从Scene API中获取。

• 通过将每个线段沿着其向内正交向量推0.3m的调谐距离来缩小多边形。

• 从天花板往下0.3米开始，向下延伸这个多边形，在结果边界内的任何具有质心的三角形都保留为不可破坏。

• 如果任何三角形质心低于0.75m的固定预留高度平面，则始终保留这个三角形，从而提供墙壁和墙壁沿线障碍物继续存在的指示。

未来的研究

《First Encounters》已经发布，而DestructibleMesh系统正在进行改进以支持可扩展的操作，将三角形分类和修改作为预处理和运行时的实时步骤。操作可以由用户排队，多个网格可以排队，以便在Jobs系统进行修改。除了令场景网格修改和健康与安全功能易于实现未来的项目，这同时将允许实验不同的视觉特效和更精确的网格破坏。

跳出思维定势

场景网格和场景锚点提供了彻底改变用户如何看待和与空间交互的诸多可能性。然而，目前存在一定的限制要记住。

在开发《First Encounters》时，我们非常小心地设计了墙体破坏机制，我们知道场景网格并不提供网格的纹理数据。这意味着我们不能通过向内或向外撞击来变形网格，因为我们不能在Passthrough中变形对象。当用户房间的大块碎片破碎时，破碎的墙壁和天花板的视觉效果使用通用纹理，但这被各种视觉特效粒子的组合所隐藏，并保持碎片的短暂存在。

同样值得注意的是，在Unity中，特定查询（如collider . closepoint()）应该避免使用场景网格。在幕后，这个方法特别使用了Physics.ClosestPoint()，这两种函数都不适用于凹网格。当涉及到凹网格碰撞器时，所述函数将失败，返回传入的原始点。对于特定用例，Physics.ComputePenetration()在使用场景网格时提供了一种潜在的替代方法。

最后

在颠覆和扩展人们对MR API在场景理解的期望方面拥有巨大的潜力，比如场景锚点和场景网格，它们提供了以自然方式将虚拟元素紧密集成到现实世界中的新方法。我希望通过分享在《First Encounters》使用新功能所获得的见解可以帮助开发者扩展MR的定义。