空间计算公开标准演进：多应用支持与渲染架构
（中国AI网 2024年12月18日）之前很多XR操作系统和Runtime都依赖于自渲染应用模型。PICO认为，统一渲染应用模型在性能、隐私和质量方面具有显著优势，特别是在多应用场景中。日前，PICO Foundation工程负责人张健以《空间计算公开标准演进：多应用支持与渲染架构》为题进行了分享：
概要
将 XR 从专注全沉浸体验的娱乐设备进化为通用的空间计算平台，需要实现多个应用程序在混合现实环境中同时运行。尽管之前很多 XR 操作系统和 Runtime 依赖于自渲染应用模型（Self-Rendering Application Model），但统一渲染应用模型（Unified Rendering Application Model）在性能、隐私和质量方面具有显著优势，特别是在多应用场景中。因此，这是一个很有潜力的技术方向，值得XR行业进一步的推进。同时，我们呼吁在该领域建立开放标准，以防止生态系统的碎片化。
背景
多年以来，XR 应用程序大多是占据用户整个视野的完全沉浸式体验，如游戏。然而，混合现实（MR）和增强现实（AR）技术的进步使得 XR 应用能够运行在我们周围的现实空间里。这一演变为 XR 从全沉浸娱乐体验扩展到通用的空间计算任务打开了大门。
为了实现这一转变，XR 需要支持多个应用程序在同一时间运行，它们拥有二维或者三维的形态，可以共同存在于一个统一的三维虚拟环境中，并与使用者周围的现实世界无缝融合。然而，实现这一目标面临显著的技术挑战，而探索并解决这些挑战将会最终塑造空间计算的未来。
将 XR 从完全沉浸式体验提升到同时支持多应用体验的概念展示。左侧图像是一个全沉浸式游戏，右侧的图像展示了三个XR应用程序：桌上的计算机、墙上的时钟和地板上的全息人形。
XR 支持多应用的挑战
尽管XR应用模型支持完全沉浸式应用已经比较成熟，但将其扩展到支持多应用并没有想象的那么简单。要理解这些挑战，我们需要先了解当前XR应用的渲染方式。
典型的全沉浸XR应用渲染流程：从3D场景的立体渲染，到XR运行时的处理与合成，再到将图像呈现在XR头显屏幕上供用户观看
沉浸式XR体验背后渲染的秘密在于立体渲染。 简单来说，应用程序通过模拟摆放在人类左右眼位置的虚拟摄像机，将三维场景渲染成针对双眼的两张图像。然后这些图像会被提交给XR 运行时（XR Runtime），由操作系统显示在头显（HMD）的屏幕上，人类的大脑能够自动融合这两张图像，感知一个具有沉浸感的虚拟世界。因为每个应用程序负责自己的所有渲染任务，我们可以称之为自渲染应用模型（Self-Rendering Application Model)
如果我们只是简单沿着当前的技术路线前进，我们就会以如下图所示的方法来实现XR多应用的支持：
在当前技术路径上扩展多应用渲染的方法
每个应用程序向XR 运行时提交自己的一对图像，操作系统/合成器将这些图像合成并输出结果到头戴显示器屏幕。这种方法在当今的XR系统中常被用于层叠应用程序（Layered Applications)。例如，PICO的安全边界系统提交包含安全区域信息的图像，操作系统将其覆盖在应用程序之上以保护用户免受障碍物的影响。这套系统可以被调整用以支持多个共存的 3D 容积应用程序，我们称之为自渲染多应用。
然而，这种方法存在几个显著的挑战：
共享空间3D合成
在混合现实场景下，多个 XR 应用程序显示在共享的3D空间中，这个共享的空间对应我们周围的真实世界。每个应用程序可以作为一个 3D 体应用运行，这些体应用可能会重叠甚至相交。操作系统往往需要原生3D 模型的信息，才能实现高效，高自由度的应用间合成，仅仅靠应用提交的2D图像是不够的。举例：如下图所示，系统如何在应用程序之间实现准确的逐像素遮挡?
两个XR应用程序相交时的情况示意图。要实现逐像素遮挡（Per-Pixel Occlusion），需要的不仅仅是两张彩色图像。
分辨率管理
与占据整个视野的完全沉浸式应用不同，多应用通常只占视野的一部分， 从不同的远近和角度来观测应用， 应用覆盖视野的大小和位置都会发生改变。如果应用的渲染分辨率是固定的，那么维持该应用的清晰度一致性会是一个很大的挑战。
你或许已经在想用视口缩放（Viewport Scaling）等技术动态调整渲染分辨率来解决问题。然而深入后，你就会发现每种方法都面临各自的挑战。比如，如果我们想估计需要的分辨率，我们就需要动态计算应用在屏幕上的投影面积，这和应用渲染的内容有关，各种例子特效和GPU动画会让这个计算过程变的尤其头疼。
这一问题在包含大量文本的二维应用中尤为突出。在这些情况下，保持一致的清晰度对于确保可读性和用户体验至关重要。
多个 3D 体应用和 2D 应用投影的屏幕覆盖范围示意图
可扩展性
混合现实提供了无限的空间，可以同时运行大量空间应用。但想要实现这一点，每个应用需要在内存和性能方面尽可能轻量化。
在自渲染应用模型（Self-Rendering Application Model）中，每个应用都有自己的渲染缓冲区。这些缓冲区必须足够大，因为摄像机可能随时靠近，应用内容将填满整个屏幕。例如，如果使用4K×4K缓冲区（每只眼睛）将意味着单应用总内存成本高达384MB [4K×4K×2 (eyes) ×3（triple buffer swapchain）×4（pixel byte depth]）。
此外，还有XR运行时的合成成本，即使应用渲染很简单，每个应用都会有固定的合成开销。随着活跃的应用数量的增加，这些开销也会线性增长。
多个 XR 应用围绕在我们周围的概念场景
隐私性
现代 XR 硬件配备了各种传感器，如眼动跟踪和面部跟踪等，这些传感器往往会收集敏感用户数据。因此，隐私保护比以往任何时候都更加重要，必须成为系统设计的核心考量。在自渲染应用模型中，为了实现特定的功能和用户体验，敏感数据往往不得不暴漏给应用程序，例如注视点渲染需要眼球移动数据。然而，却很难从系统层面完全防止恶意应用程序收集和滥用这些数据。
统一渲染应用模型（Unified Rendering Application Model）
幸运的是，有一种方法可以更好的解决这些挑战: 统一渲染应用模型(Unified Rendering Model)。不同于独立渲染应用，统一渲染应用本身并不直接进行渲染，而是把要渲染的内容提交给一个集中式渲染服务。该服务收集所有需要渲染的内容，在一个统一分享的渲染场景中进行渲染， 因此被称为统一渲染（Unified Rendering)。
集中式渲染服务器可以将来自不同XR应用程序的3D内容收集到一起，并在共享的3D场景中进行渲染。
与自渲染模型相比，统一渲染模型为许多上述挑战提供了更优雅的解决方案。
高自由度的共享空间合成能力：由于渲染服务可以获得来自不同应用程序的所有三维对象的完整信息，因此操作系统在统一合成方面具有很高的自由度。
自动的3D场景分辨率管理：对于统一渲染来说，每个应用相当于一个统一3D场景的一部分， 就如同我们在自渲染中不需要关心每个3D物体的分辨率一样，每个3D应用的分辨率是自动被支持的。
低单应用开销，高可扩展性：假设我们的周围有有100个XR应用，每个应用都渲染一个简单的球体。 对于自渲染应用来说， 如前所述，由于每个应用都要独立进行渲染和合成过程，最终可能需要100份儿渲染缓冲和100次系统合成的开销。而对于统一渲染来说，这仅仅是一个有100个球体的简单3D场景，系统开销是可以共享的。
隐私优先的系统设计：渲染服务是一个系统进程，可以和应用进程安全的隔离。类似注视点渲染之类的特性可以直接实现在渲染服务里，无需向应用暴漏，防止恶意应用收集和滥用隐私数据。
事实上，统一渲染模型不仅限于渲染，还可以扩展到输入、物理、网络共享等集中式模型具有优势的领域。
当然，这种方法也有不足。由于开发人员依赖系统提供的API进行渲染， 这可能在一定程度上降低了应用创建高度定制内容的自由度。此外，与已经建立了成熟开发工具生态系统的自渲染模型不同，统一渲染需要对许多工具进行更新，甚至重新设计，才能实现完备的支持。
为了更清晰地比较这两种模型的优缺点，我们在下表中进行了总结。
比较：统一渲染 vs 自渲染
比较统一渲染自渲染隐私性很多隐私数据有机会保留在系统内，不需要暴露给应用程序。比如：注视点渲染需要的眼动追踪数据，或者基于真人扫描的高真实感数字化身（Avatar）需要与应用程序共享敏感数据，以确保功能的正常运行。 恶意应用程序可能会存储甚至上传这些数据，而检测和阻止此类行为极为困难。应用程序开销与可扩展性所有应用共享渲染缓冲区，开销较低。每个应用需要专用渲染缓冲区和渲染过程。共享空间三维合成应用程序在同一空间渲染，场景合成自然且一致。每个应用程序只能提供2D图像，系统的合成能力受限一致的清晰度自动实现面临很多问题共享空间功能更容易实现共享的光照、物理等功能。难以实现。开发者工具需要全新的或升级现有的工具。已经有建立好的工具包。开发者自由度开发者依赖系统提供的应用程序接口，灵活度较低。开发人员拥有完全的自定义渲染自由。开发者主导的优化更加依赖操作系统的性能管理和资源分配。应用开发者可以通过投入更多精力，针对性的将其应用优化到极致，尤其是在游戏等沉浸式应用中。未来步骤与总结
我们探讨了面向未来空间应用的两种根本不同的渲染架构，以及它们对XR多应用支持的影响。如果我们继续沿着当前路径发展，自渲染应用模型可能很自然的成为行业首选。但我们认为统一渲染模型具有显著的优势，对于构建未来XR多应用生态至关重要。
当然，这也不意味着自渲染模型应被抛弃，它仍然具有很多好处，包括成熟的工具链和更大的开发者灵活性。更有可能得是，未来两种模型将在未来共存，在生产力和多应用场景中利用统一渲染的效率，同时在类似全沉浸式游戏等高度定制和高性能的体验中保留自渲染模型的创造力。
不同于基于 OpenXR™ 框架的自渲染应用模型，统一渲染模型尚无公开的标准。若每家XR公司都开发自己的 统一渲染API，可能导致生态碎片化。因此，提前规划和倡导共享开放标准对行业来讲有很重要的意义。
作为行业的一部分，PICO 希望与社区合作，构建一个有助于创新和发展的XR统一渲染标准。我们欢迎对该主题感兴趣的任何人加入我们的讨论！对于当前尚未加入OpenXR工作组的人员，我们邀请您加入我们的聊天群组，共同协作和交流想法：
PICO Developer Community Discord - #multi-app 频道；
OpenXR 内部讨论（仅限Khronos工作组成员访问）: OpenXR Multi-App
