Skip to main content

Chapter 150: Extended Reality and Beyond

扩展现实（Extended Reality，XR）把 VR、AR、MR 和未来空间显示放在同一条工程链路中讨论。它的核心问题是：图像需要跟随人的头部、眼睛、手、真实环境和显示硬件持续变化。读完本章，读者应能追踪一帧 XR 图像从传感器输入、空间定位、渲染管线、平台 runtime、AI 推理到显示输出的闭环，并能判断视觉问题、延迟问题和功耗问题分别落在哪个环节。

本章使用一个贯穿材料：一名工程师戴着头显站在机房设备前。真实世界通过 passthrough 或透明显示进入视野，虚拟热区覆盖在设备外壳上，手势拉出维修面板，远程专家的标注固定在某个阀门旁边，系统还用 AI 模型识别设备铭牌并生成操作提示。这一帧看起来像一个简单的空间 UI，实际经过了摄像头、IMU、眼动、手势、深度、场景理解、渲染、重投影、显示校准和功耗调度。

XR 的难点来自闭环约束。桌面渲染主要把场景变成屏幕图像，XR 还要让图像在用户移动、真实物体遮挡、光照变化和硬件升温时保持稳定。一个虚拟按钮的位置错误几厘米，用户会看到它贴在错误设备上；一帧延迟增长，用户会感觉虚拟面板漂移；亮度、阴影和深度关系错误，虚拟物体会从空间中脱离。

本章的结论是：未来图形学的 XR 路线会从单向渲染管线扩展为“传感器感知 → 状态估计 → 渲染生成 → 显示反馈 → 交互修正”的闭环系统。光栅化、光线追踪、神经渲染、传感器融合和平台 runtime 都会继续存在，工程能力的关键在于把它们放到同一帧预算、同一空间坐标和同一质量证据链中判断。

150.1 XR（扩展现实）视觉渲染的挑战​

XR 视觉渲染的工作对象是一帧与用户身体状态绑定的图像。传统屏幕渲染中的相机通常由程序控制，XR 中的相机来自头部姿态、眼睛注视、手部输入和真实空间理解。工程师在机房设备前转头时，虚拟热区需要仍然贴在设备表面，维修面板需要保持可读，手指遮住按钮时需要产生正确遮挡关系。

空间定位是第一条约束。头显通过 IMU、摄像头、深度传感器或外部 tracking 系统估计头部在空间中的 pose。pose 进入渲染管线后会生成每只眼睛的 view matrix 和 projection matrix。平台 runtime 往往还会给出预测显示时间，让应用用未来某个时刻的 pose 渲染图像。OpenXR 把 runtime、tracking、input 和 frame submit 抽象成跨设备 API；在 OpenXR 1.1 specification 中，xrLocateViews 这类接口围绕预测时间返回 view 数据，说明 XR 渲染从接口层就已经把时间预测纳入相机生成。

遮挡是第二条约束。机房设备的真实外壳、工程师的手和虚拟热区处在同一个视野中，系统需要判断哪些像素属于真实物体，哪些像素属于虚拟物体。光学透视 AR 设备通常无法直接修改真实光线，只能把虚拟图像叠加到眼前；passthrough MR 设备可以把摄像头图像当作背景，再用 depth、segmentation 或 scene mesh 参与合成。Apple 的 ARKit overview 把 Depth API、Scene Geometry 和 People Occlusion 放在真实环境理解中，这类能力支撑的正是虚拟物体与真实物体的前后关系。

光照一致性决定虚拟物体是否能融入真实环境。维修面板可以保持 UI 风格，但贴在设备上的热区、箭头、透明剖面和虚拟螺丝标记需要响应环境亮度、色温、阴影方向和反射。渲染管线通常会使用环境光估计、light probe、reflection probe、camera exposure 和 tone mapping。这里的目标聚焦稳定的空间可信度：用户头部运动和相机曝光变化时，虚拟内容仍然需要保持可解释的亮度、阴影和反射关系。

低延迟是 XR 与普通实时渲染的分界线。XR 的延迟路径从传感器采样开始，经过 pose prediction、应用渲染、GPU 提交、runtime compositor、reprojection、display scanout，最后进入用户视觉反馈。应用帧率达标仍可能出现漂移，因为最后显示的 pose 与渲染使用的 pose 存在差值。late latching、timewarp、spacewarp 和 runtime compositor 的意义在于把最终显示时间附近的姿态修正纳入合成阶段。

眼动和手势让渲染从“视角跟随头部”扩展到“内容跟随注意力和意图”。眼动数据可以驱动动态 foveated rendering，把最高 shading rate 放在注视区域，把周边区域降采样。手势数据会改变 UI hit test、遮挡、交互反馈和触觉提示。Apple 的 visionOS overview 把 spatial computing、RealityKit、ARKit、passthrough 和 Dynamically Foveated Rendering 放在同一个开发语境中，说明现代 XR 平台已经把显示、感知和渲染联动为一组系统能力。

可读性是 XR UI 的工程底线。维修面板悬浮在真实设备旁边时，字体大小、深度位置、对比度、背景遮罩、视线角度和手部遮挡都会影响读取。近距离 UI 可能造成眼睛聚焦压力，远距离 UI 可能丢失细节，强光背景会降低对比度。检查 XR 视觉问题时，应按空间定位、深度遮挡、光照合成、延迟漂移、注视区域、交互反馈和 UI 可读性排序，因为这些环节从底层坐标到最终感知逐层依赖。

150.2 全息与光场渲染概念​

光场渲染（Light Field Rendering）把显示目标从一张二维图像扩展为一组随位置和方向变化的光线样本。二维屏幕只需要为每个像素输出一个颜色，立体渲染需要为左右眼输出两张图像，光场显示则希望用户在一定范围内移动眼睛或头部时看到连续变化的视差。对渲染管线来说，输出对象从 per-eye render target 变成了多视点图像、视图阵列、方向采样或经过压缩的光线表示。

全息显示（Holographic Display）的目标更接近重建波前。它关心光的相位、干涉和衍射，常见工程对象包括空间光调制器、相位图、振幅调制、校准矩阵和视场范围。全息显示进入实时图形系统后，传统材质、深度和 shading 仍然有价值，但最终输出需要转换成显示硬件能产生的波前控制数据。这会把渲染问题推进到物理光学、显示驱动和计算全息图生成的交界处。

光场和全息渲染共同放大了数据量。机房设备的虚拟热区在普通 AR 中可以作为一个透明 mesh 渲染到两只眼睛的 render target；在光场显示中，同一个热区需要在多个观察方向上保持几何一致；在全息显示中，还需要把它转成硬件能调制的光场或波前近似。视点数、角分辨率、空间分辨率、刷新率和色彩深度相乘后，带宽与存储需求会迅速增长。

多视点采样带来的核心问题是采样密度。采样太稀，用户移动时会看到视图跳变、重影或视差不连续；采样太密，渲染成本和传输成本会压垮移动 SoC 或显示链路。工程上通常需要组合 view synthesis、depth-aware reprojection、neural interpolation、tile streaming 和 perceptual compression。这里的判断依据是可观察图像：边缘是否漂移，遮挡边界是否破裂，透明物体是否出现鬼影，快速头动时是否出现视图切换痕迹。

显示硬件会反向约束渲染表达。VR 头显通常要求低延迟、高刷新率和双眼一致性；透明 AR 眼镜强调亮度、对比度、光学效率和轻量化；passthrough MR 头显依赖摄像头质量、深度估计和 compositor；光场显示强调视区范围和角分辨率；全息显示强调波前控制、衍射效率和校准稳定性。渲染管线要先知道目标显示器的可表达内容，再决定场景如何分层、采样、压缩和提交。

把全息与光场放回贯穿材料，可以得到一个清晰边界：维修系统的虚拟热区在今天的 MR 头显中主要是空间 mesh 加透明材质；在光场显示中，它需要支持用户头部小范围移动产生的连续视差；在全息显示中，它还需要转成显示器能重建的光分布。算法名称会变化，但最终仍要回答三个工程问题：空间关系是否稳定，显示数据是否在预算内，用户观察时是否获得连续可信的深度线索。

150.3 Engineering Practice：未来显示与渲染协作模型​

未来 XR 系统的稳定形态是协作模型。传感器负责观察世界，平台 runtime 负责统一设备能力和时序，渲染管线负责生成虚拟内容，AI 模型负责补全识别、预测、重建和压缩，显示器负责把结果转成用户可感知的光。任何一环独立优化都可能带来局部收益，系统体验取决于它们在同一帧内的协作。

贯穿材料中的维修帧可以拆成一条闭环路径。摄像头和深度传感器获取机房环境，IMU 提供高速姿态变化，眼动传感器给出注视区域，手势跟踪给出交互意图。传感器融合层把这些数据变成统一空间中的头部 pose、hand pose、scene mesh、plane、anchor 和 gaze point。渲染层用这些状态决定虚拟热区、维修面板、远程标注和 AI 提示的位置、分辨率与 shading 成本。runtime compositor 在显示前执行畸变校正、重投影、透明合成和最终提交。

这张图的关键路径是闭环，单向输出只覆盖其中一段。用户转头会改变传感器输入，传感器融合会更新 pose，scene anchor 会重新对齐，渲染计划会调整画质预算，runtime 会按最新姿态合成图像，显示结果又进入用户的下一次动作。工程排查时需要保留这条闭环，否则会把一个延迟问题误判成 shader 问题，或把一个 anchor 漂移误判成 UI layout 问题。

平台 runtime 的价值在于统一时序和能力边界。OpenXR、ARKit、RealityKit、WebXR、设备厂商 SDK 和引擎 XR 层都在处理相似对象：session、view、swapchain、pose、input、anchor、compositor 和 frame lifecycle。应用层应把 runtime 看作“设备状态与显示提交的契约”，并把普通库函数集合与这种时序契约区分开。它决定应用何时查询预测 pose，何时渲染，何时提交，哪些功能由平台 compositor 接管。

AI 模型在协作模型中承担三类任务。第一类是识别，例如铭牌识别、物体分类、手势意图和语义分割。第二类是重建，例如深度补全、场景 mesh 修复、材质估计和光照估计。第三类是生成与压缩，例如 view synthesis、super resolution、neural denoising 和交互预测。这些任务都需要进入 frame budget。一个识别模型准确率高，但推理时间超过交互预算，它会把稳定 anchor 变成抖动提示。

渲染计划负责把质量目标转成资源分配。机房维修帧中，注视区域内的维修面板需要高分辨率字体和稳定边缘；周边背景可以使用较低 shading rate；透明热区需要正确深度测试和 alpha 合成；远程标注需要优先保证空间稳定；AI 提示可以在低频更新后缓存。渲染计划要把这些对象拆成 pass、buffer、texture、pipeline state 和调度顺序，并给出降级路径。

协作模型的最小工程接口可以抽象为四类状态：空间状态、视觉状态、交互状态和预算状态。空间状态包括 pose、anchor、scene mesh 和 depth；视觉状态包括光照、曝光、显示色域和 foveated region；交互状态包括 hand pose、gaze、controller action 和 UI focus；预算状态包括 frame time、thermal level、battery、bandwidth 和 inference queue。每一帧的渲染决策都应显式读取这些状态，并把状态读取集中到稳定接口中。

150.4 性能与能耗约束与优化方向​

XR 性能约束来自持续帧率、低延迟和移动功耗的叠加。桌面游戏可以在短时 GPU 峰值下追求更高画质，独立头显还要控制热预算、电池续航、传感器功耗、显示功耗和用户舒适度。机房维修应用运行五分钟后如果 SoC 降频，虚拟热区会从稳定贴合变成间歇漂移，用户看到的是空间信任下降，帧率数字只解释了其中一部分症状。

移动 SoC 的预算需要按子系统拆开。CPU 负责应用逻辑、scene update、AI 调度和 draw submission；GPU 负责 raster pass、post-process、compute pass、reprojection 输入和部分 AI 推理；NPU 或专用 AI 单元负责模型推理；ISP 和传感器链路负责摄像头输入；display engine 负责扫描、合成和亮度控制。任何子系统持续高负载都会抬高热量，并通过频率调度影响后续帧。

帧时间应先分配到用户可感知路径。维修面板的文字、热区边缘和手势反馈属于高优先级对象；环境背景、非注视区域反射、远处装饰几何和低频 AI 提示属于可降级对象。优化顺序可以按“保证 pose 与 anchor 稳定 → 保证 UI 可读 → 保证交互反馈 → 提升材质与后处理”的方式推进。这个顺序把舒适度和任务完成率放在画面装饰之前。

foveated rendering 是 XR 中最直接的像素成本控制手段。固定 foveated rendering 使用固定中心区域，眼动驱动的动态 foveated rendering 使用 gaze point 更新高质量区域。它可以降低 fragment shading、纹理采样、后处理和部分带宽成本，但它依赖眼动数据质量、预测延迟、rate map 平滑和内容敏感度。文字、细线、透明 UI、快速扫视和高对比边缘更容易暴露周边降采样痕迹。

动态分辨率需要与 runtime compositor 协同。应用可以根据 GPU frame time 调整 render scale，runtime 可能还会执行重投影、畸变校正和最终合成。分辨率降低后，UI 字体、alpha 边缘和深度边界会先暴露问题。稳定策略通常是把 UI 与关键标注放在独立层或更高分辨率 pass 中，把大面积背景和周边区域纳入可变分辨率范围。

传感器融合也有功耗成本。高频 IMU、摄像头、深度、手势和眼动同时工作会增加带宽、ISP、CPU、AI 和内存压力。工程上可以按任务状态调整采样策略：用户正在精确操作时提升手势与深度更新频率；用户静止阅读时降低部分空间重建频率；场景 anchor 稳定后把 mesh 更新降到低频；AI 识别结果进入缓存后只对变化区域重新推理。这样的策略需要质量监控支撑，单纯依赖静态配置会在长时间运行中失去稳定性。

AI 推理优化要同时看延迟、内存和稳定性。模型量化、裁剪、蒸馏、tile 推理、异步队列、结果缓存和低频更新都能降低成本，但它们会改变识别边界、时序和空间一致性。维修应用的铭牌识别可以低频更新，手势意图需要高频低延迟，深度补全需要和遮挡边界同步。不同模型进入不同队列，才能让推理成本服务体验目标。

热预算调度应成为渲染架构的一部分。系统进入高温状态时，优先降低远景几何、反射更新、阴影分辨率、周边 shading rate、AI 低优先级任务和背景重建频率；保留 pose prediction、anchor 稳定、UI readable layer、手势反馈和必要遮挡。降级策略需要提前设计，并在调试 overlay 中显示当前质量档位、frame time、reprojection rate、AI queue latency 和 thermal level。

性能排查的可复用顺序是：先看 runtime frame timing 和 dropped frame，再看 motion-to-photon 或 reprojection 指标，再看 GPU pass time 与带宽，再看 CPU submit 与同步等待，再看 AI inference latency，最后看传感器与显示功耗。这个顺序能把“图像漂移”“UI 模糊”“手势延迟”“电量下降”和“机身升温”放到同一个系统证据链中。

150.5 AI Sensor Rendering Convergence as Future Graphics Path​

AI、传感器和渲染的融合会成为未来图形系统的主路径。这个判断来自 XR 的系统需求：图像需要理解真实环境，跟随用户动作，在受限功耗内生成高质量输出，并把缺失传感器数据补成可渲染状态。传统渲染负责可控性和确定性，AI 负责估计、补全和压缩，传感器负责把真实世界带入管线。

未来图形工程会把“场景数据”从美术资产扩展为持续更新的世界状态。机房维修应用中的设备模型、真实深度、语义标签、温度数据、用户手势、远程标注和维修记录都可能成为渲染输入。场景图会在 mesh、material 和 light 之外继续加入 anchor confidence、tracking quality、semantic class、sensor timestamp、AI confidence 和隐私权限。

AI 进入渲染管线后，质量判断会从单帧图像扩展到时序稳定性。一个超分模型可以让维修面板看起来更锐利，但如果相邻帧文字边缘闪烁，用户会更难阅读。一个深度补全模型可以改善遮挡边界，但如果手指边缘在真实设备前跳动，用户会失去空间信任。未来的图形工具需要同时显示图像质量、时序差异、模型置信度和 frame budget。

传感器融合会改变调试证据。传统渲染错误通常可以从 draw call、shader、texture、depth buffer 和 pipeline state 定位；XR 错误还要看 pose history、camera exposure、tracking confidence、anchor drift、depth map、hand joint stability、eye tracking validity 和 runtime compositor 输出。工程师需要把 frame capture 与 sensor log 对齐到同一时间轴，才能判断问题发生在渲染前、渲染中、合成时，还是显示后被用户动作放大。

平台 API 会继续向能力查询和协作提交演进。OpenXR 的跨设备目标、visionOS 的空间计算框架、ARKit 的环境理解能力，以及各类厂商 runtime 的 compositor 都说明一个方向：应用需要声明自己要什么空间能力、显示能力和交互能力，runtime 再把能力映射到底层硬件。为了保持可移植性，应用架构应把核心渲染、平台能力、AI 模型和设备特性分层，并为缺失能力准备质量档位。

未来显示也会反向推动算法选择。高分辨率广视场头显需要 foveated rendering、动态分辨率和神经超分；透明 AR 眼镜需要高亮度、低功耗和强对比 UI；passthrough MR 需要 camera reprojection、depth occlusion 和低延迟合成；光场显示需要多视点生成和压缩；全息显示需要波前计算与硬件校准。每种显示路线都会选择不同的渲染表达，但共同目标仍然是把用户动作、空间状态和图像输出同步起来。

这条融合路径还有明确边界。AI 输出带有置信度和失败模式，传感器数据带有噪声和权限限制，runtime 能力受设备约束，显示效果受光学系统限制。XR 工程需要把生成结果与真实空间状态区分开，也需要把单设备体验限定在对应平台边界内。可靠系统需要在 UI 中表达不确定性，在架构中保留 fallback，在工具中记录证据，在渲染中优先保护用户可读性和空间稳定性。

因此，本章对“Beyond”的理解聚焦一套判断框架：未来图形系统会在传感器、AI、渲染、runtime 和显示之间形成更紧密的闭环。判断一个新 XR 技术是否可落地，应先看它改变了哪类输入数据、哪段 frame budget、哪种显示约束、哪类交互反馈，以及它能提供哪些可观察证据。

最小自检任务​

你正在调试一个机房维修 XR demo。用户转头时虚拟热区会轻微滞后，手指经过热区时遮挡边界破裂，维修面板在强光设备表面前可读性下降，设备运行五分钟后帧率从稳定变成周期性波动。请按本章的闭环模型，把这四个症状分别定位到管线阶段，并给出排查顺序。

答案要点​

虚拟热区滞后优先定位到 pose prediction、runtime compositor、frame timing 和 anchor 更新链路。先查看 predicted display time、reprojection rate、dropped frame 和 anchor confidence，再进入 shader 或材质检查。手指遮挡破裂优先定位到 depth、segmentation、hand tracking、scene mesh 和合成顺序，重点观察深度边界是否与手部关节和真实相机帧对齐。维修面板可读性差优先定位到 UI layer、对比度、曝光、显示亮度、字体尺寸和空间距离，处理顺序应保护文字与关键标注的分辨率和稳定边缘。五分钟后帧率周期性波动优先定位到 thermal level、GPU pass time、AI inference queue、传感器采样和动态质量档位，先降低低优先级背景、周边 shading、反射、低频 AI 任务和重建频率，保留 pose、anchor、UI 与手势反馈。

本章知识点总结​

  • XR 闭环：XR 渲染把传感器输入、空间定位、渲染生成、runtime 合成、显示输出和用户反馈连接成一条持续循环。
  • 空间定位：头部 pose、eye view、anchor 和预测显示时间共同决定虚拟内容是否能稳定贴合真实空间。
  • 遮挡关系：真实深度、scene mesh、hand tracking 和合成顺序共同决定虚拟物体与真实物体的前后关系。
  • 光照一致：环境亮度、曝光、阴影、反射和 tone mapping 决定虚拟内容是否能融入真实场景。
  • 延迟路径：motion-to-photon 由传感器、预测、渲染、提交、重投影、显示扫描和用户反馈共同构成。
  • 光场渲染：光场显示把输出从二维颜色图扩展为随位置和方向变化的多视点光线样本。
  • 全息显示：全息渲染需要把场景结果转换成显示硬件可调制的波前或光场近似。
  • 协作模型：未来 XR 系统需要让传感器、AI、渲染管线、平台 runtime 和显示器在同一帧预算内协同。
  • 质量预算：渲染计划应优先保护 pose 稳定、anchor 可信、UI 可读和交互反馈，再提升材质、反射和装饰性后处理。
  • 能耗约束：移动 SoC 的 CPU、GPU、NPU、ISP、内存和显示链路共同决定持续帧率、热预算和电池续航。
  • AI 边界：AI 可以承担识别、重建、预测和压缩，但它的延迟、置信度和时序稳定性必须进入图形质量评估。
  • 证据链路：XR 排查需要把 frame capture、sensor log、runtime timing、AI queue 和 thermal telemetry 对齐到同一时间轴。
  • 未来路径：图形学后续发展会表现为硬件、算法、工具、AI、传感器和交互系统的共同演进。