屏幕空间渲染工程 2026：GTAO、SSR 与时域重建
屏幕空间效果是把渲染方程的可见性项压进一张深度缓冲求解的工程折中：2026 年它在 Lumen 等混合光照管线中反而升格为第一优先快路径，上限由深度预滤波、时域重投影与方差裁剪这套重建底座决定。本文考据 HBAO、Alchemy、GTAO 的算法谱系与常见讹误，拆解 UE、Unity、Godot 三家引擎的落地实现，并厘清与 DLSS/FSR/XeSS 的边界。
约 52 分钟阅读15,373 字2 次阅读博主
屏幕空间效果是把渲染方程的可见性项压进一张深度缓冲求解的工程折中：2026 年它在 Lumen 等混合光照管线中反而升格为第一优先快路径，上限由深度预滤波、时域重投影与方差裁剪这套重建底座决定。本文考据 HBAO、Alchemy、GTAO 的算法谱系与常见讹误，拆解 UE、Unity、Godot 三家引擎的落地实现，并厘清与 DLSS/FSR/XeSS 的边界。
导语：屏幕空间效果是把渲染方程的可见性项压进一张深度缓冲里求解的工程折中——2026 年它没有被硬件光追取代，反而成了 Lumen 这类混合全局光照系统的第一优先快路径，而决定其上限的不再是采样公式本身，而是深度预滤波、时域重投影与方差裁剪这套重建底座。
一个常见判断是：硬件光追已经普及，屏幕空间效果属于过渡技术。但从今年各家引擎的实际行动看，这个判断并不成立。
先看硬件。据 NVIDIA 官方产品页（2026-10 查证），消费级旗舰 RTX 5090 配备 Blackwell 架构的 21760 个 CUDA 核心，第四代 RT Core 的光线追踪算力标称 318 TFLOPS，显存带宽 1792 GB/s [21]；AMD 侧的 RX 9070 XT 则有 64 组计算单元与 64 个 Ray Accelerator，FP32 峰值 48.7 TFLOPs [22]。硬件光追的算力确实到达了上世代不可想象的水平。但引擎的取舍逻辑不是"能不能"，而是"每一毫秒买多少质量"。
据 Epic 官方文档，Unreal Engine 5.8（2026 年 6 月 23 日发布）的 Post Process 体系里，传统的 Ray Tracing Reflections 与 Ray Tracing Global Illumination 均被标注为"已废弃、未来版本可能移除" [12][13]；Lumen 的技术细节文档则把 Screen Tracing（屏幕空间追踪）列为光线的第一站，只有当屏幕空间命中失败时才 fallback 到更昂贵的距离场与探针方案 [13]。更值得注意的是，5.8 还把一个纯屏幕空间的新效果 FSSS（Fog Screen Space Scattering）列为实验特性 [10]。Unity 这边，URP 直到 17.6 版本（2026-06-26 发布说明）才把 SSR 作为 Renderer Feature 公开 [17]；Godot 4.7 的 SSR 只在 Forward+ 渲染法下可用，Mobile 与 Compatibility 都不支持 [20]。屏幕空间没有退场，反而在向更多管线层级渗透。
这背后的工程逻辑值得说透。屏幕空间效果的本质约束是：渲染器只拥有当前帧视锥内的一张深度缓冲、一张法线缓冲（或从深度重建）和运动矢量，任何光传输近似都必须在这个输入集上完成。它便宜，是因为输入已经在显存里；它错，是因为视锥外的几何体完全不可见。而现代混合渲染管线的做法，恰恰是把屏幕空间作为"免费的第一次猜测"，让昂贵路径只处理屏幕空间猜错的部分。所以屏幕空间质量的上限，直接决定了昂贵路径的工作量下限——这就是它至今仍是引擎渲染组核心工程的原因。
本文把屏幕空间效果拆成三块工程问题来讨论：遮挡项怎么算（GTAO 一族）、反射光线怎么走（SSR 一族）、噪声怎么收（时域重建底座）。三块各自有近二十年的谱系，也各自有一堆以讹传讹的说法，一并考据。
环境光遮蔽的原始形态是离线烘焙：对每个点向半球发射线，统计可见性。2005 年 NVIDIA 的 GPU Gems 2 第 14 章给出了第一份有影响力的实时方案——Michael Bunnell 用点云近似场景几何，在 GPU 上对点做层次聚合来算 AO [27]。Crytek 则在 2007 年 SIGGRAPH 的 CryEngine 2 技术报告里把 AO 直接搬进了屏幕空间：不需要任何预处理资产，仅凭深度缓冲就地采样（这段谱系在 Stephen Hill 的 publications 页有明确叙述，Crytek 的 SSAO 方案即 Mittring 2007 报告 [29]）。"屏幕空间 AO"自此成为实时渲染的标配组件。
早期的屏幕空间 AO 属于 obscurance 一族：对邻域深度做点采样，按距离衰减函数累加遮挡权重。这类方法能出效果，但衰减函数、采样半径全是经验参数，光照变化下表现不稳定。
2008 年，NVIDIA 的 Louis Bavoil、Miguel Sainz 与 Rouslan Dimitrov 发表了 Image-space Horizon-Based Ambient Occlusion（ACM SIGGRAPH 2008 Talks，DOI 10.1145/1401032.1401061）[1]，思路源头是 1986 年的 horizon mapping：把深度缓冲当作一张 2.5D 高度场，在切平面内做地平线搜索。
其数学核心非常简洁。在某个切平面方向上，AO 等于地平线角与切线角的正弦差：
AO(θ) = sin h(θ) − sin t(θ)
h = atan(H.z / |H.xy|) // 地平线角：沿步进方向找到的最大仰角
t = atan(T.z / |T.xy|) // 切线角：当前像素法线决定的仰角
对多个 2D 方向 θ 重复这个 1D 积分再取平均，就是完整的角向积分。几个工程细节在当时就已定型，且一直延续到今天的实现里：
当时在 GTX 280 上的实测数字很有参考价值：1600×1200 分辨率、半分辨率 AO、6 方向 × 6 步进、15×15 模糊，几何 pass 1.0 ms、AO 3.5 ms、模糊 2.5 ms，合计 7.0 ms；若用全分辨率 AO 则膨胀到 30 ms [2]。半分辨率计算 + 空间重建从那时起就是这类效果的标准姿势。
一年后的 HPG 2011，Alchemy AO 论文的 Figure 11 给出了与 HBAO 的正面对比，结论原文值得引用：HBAO gives smoother results，而 Alchemy captures more fine details and more consistent intensity as the view changes，同时 HBAO 在角落处倾向出现 intense dark shadows [3]。这两族方法的取舍——平滑 vs 细节保真——直到今天仍然在各大引擎的 AO 实现里留有痕迹。
Alchemy AO（Morgan McGuire、Brian Osman、Michael Bukowski、Padraic Hennessy，HPG 2011，pp. 25–32）走了另一条路：不从经验出发，而是从渲染方程的可见性积分推导，选一个能让昂贵项相消的衰减函数——他们借鉴了 StarCraft II 相关工作（Filion 与 McNaughton，2008）的 falloff 选型 g(t) = u·t·max(u,t)^(−2)，最终得到一个只有四个直观参数的封闭公式：世界空间半径 r、bias β、强度 σ、对比度 k [3]。论文自述明确：它比现象学方法更接近辐射度推导，但 not physically correct。性能上约 4.5 ms（Xbox 360）或 3 ms（GeForce 580），720p。次年同一团队的 Scalable Ambient Obscurance（HPG 2012）把可扩展性问题补齐 [4]。
真正把精度上限抬起来的是 Activision 的 GTAO。Jorge Jimenez、Xian-Chun Wu、Angelo Pesce 与 Adrian Jarabo 的 Practical Realtime Strategies for Accurate Indirect Occlusion 是一份技术备忘录（编号 ATVI-TR-16-01），并在 SIGGRAPH 2016 的 Physically Based Shading in Theory and Practice 课程上宣讲 [5][6]。
GTAO 相对 HBAO 有三个关键改动，每个都值得展开：
其一，积分轴换成视线方向。 HBAO 沿法线半球积分，GTAO 沿视线向量 ωo 积分（这一选择沿用 Timonen 的早期工作 [5]），于是地平线在整个球面范围内搜索，与 BRDF 的 cosine 项天然对齐。可见性函数被刻意做成二值函数——某方向被遮挡即计 0，否则计 1——彻底丢掉了 HBAO/Alchemy 那种带距离衰减的 obscurance 权重，消掉一整族 ad-hoc 参数。
其二，内层积分解析化。 cosine 加权形式下，方位角 θ 方向的内层积分有解析解（备忘录 Eq. 7），只有方位角 φ 一层需要蒙特卡洛数值积分。这里必须纠正一个流传极广的说法：GTAO 不是对 cosine 加权半球做重要性采样——备忘录原文明确只有外层积分用随机方向数值计算，内层是解析的，cosine 权重被吸收进了解析式 [5]。均匀权重版本的内积分更简洁：â = 2 − cos θ1 − cos θ2，归一化系数相应从 1/π 变为 1/(2π)。
其三，厚度启发式。 屏幕空间搜索看不到几何体的厚度，GTAO 假设物体厚度近似等于其屏幕空间尺寸，在地平线搜索中用指数滑动平均做角度混合，避免了薄片（墙面、栏杆）在近距离下的遮挡爆炸 [5]。
GTAO 还交付了两件超出 AO 本身的东西：bent normal（遮挡加权的平均可见方向，可直接用于改进 IBL 与阴影采样）和基于可见锥与高光锥立体角交叠的 GTSO（specular occlusion）；以及一个三次多项式的 multi-bounce 补偿 G(A,ρ) = a(ρ)A³ − b(ρ)A² + c(ρ)A，系数由 7 组 albedo 乘 7 个场景、最多 3 次反弹的拟合得到 [5]。方法论上，Jimenez 在课程里反复强调的一点今天仍是图形算法开发的黄金标准：每一步都与蒙特卡洛 ground truth 对照验证，确保方向正确再谈优化 [6]。Intel 后来开源 XeGTAO 时沿用了同一套方法论——在引擎内部造了一个小型光线追踪器渲染 AO ground truth，再用自动调参在所有参数排列里搜索对 ground truth 的最小均方误差 [7]。
一段必要的考据。 围绕这一族算法的错误引用在中文技术社区里非常常见，以下几条都有一手出处可查：HBAO 的作者是 Bavoil/Sainz/Dimitrov（2008），不是 McGuire；McGuire 在 HPG 2011 发表的是 Alchemy，两篇是不同的工作；GTAO 是技术备忘录加课程讲题，不是 SIGGRAPH 论文，也不在 Advances in Real-Time Rendering 课程（那年 Advances 课程上 Jimenez 讲的是 Filmic SMAA）；标题拼写以备忘录封面 Realtime（一个词）为准。
算法只占这类工程的一半，另一半是调度、分辨率与噪声管理。拿三个引擎的实现做样本。
Unreal Engine。 UE 同时保留两条屏幕空间 AO 路径，由控制台变量 r.AmbientOcclusion.Method 选择：0 为 SSAO（默认），1 为 GTAO；官方 Console Variables Reference 有独立的 GTAO 章节，收录 r.GTAO.* 系列 cvar [11]。在公开可获取的 UE 5.3 源码镜像里，PostProcessAmbientOcclusion.usf 能看到完整实现骨架：GTAO_THICKNESS_HEURISTIC 与 GTAO_VARIANCE_CLIPPING 两个编译期开关对应备忘录的厚度启发式与时域方差裁剪，pass 链为 GTAOCombined、GTAOInnerIntegrate、GTAOTemporalFilter、GTAOSpatialFilter、GTAOUpsample [14]。参数默认值同样有据可查：FilterWidth 默认 5（即 5×5 邻域）、NumAngles 默认 2、Upsample 默认 1（DepthAware）、ThicknessBlend 默认 0.5 [14]。另外，Post Process Volume 里 AO 的 Temporal Blend Weight 属性，官方文档描述其作用于"使用 Ground Truth Ambient Occlusion 的时域累积"——GTAO 这个名字在 Epic 文档里的正式形态是 Ground Truth Ambient Occlusion [12]。
Unity。 这是最新的一个样本：Unity 6000.7 的 URP 17.7 文档宣布 URP 同时提供 GTAO 与 SSAO 两种算法，GTAO 是新建 Volume Override 的默认项，官方措辞是 GTAO 质量更高、SSAO 更快但更噪 [15]。挂载方式也变了——从 post-processing 分类改到 Lighting 分类添加 Screen Space Ambient Occlusion Volume Override。管线相关的细节很能说明工程取舍：在 Deferred 与 Deferred+ 路径下两种算法都直接使用 G-buffer 里的法线，Depth Source 设置无效；在 Forward/Forward+ 下 GTAO 恒定使用法线贴图纹理（需要 depth-normals prepass），SSAO 则允许选择从深度重建法线 [15]。Unity 的 compute 实现 GTAOPass.cs 里，深度预滤波相关常量的注释直接写着取自 Intel XeGTAO [19]——一个引擎抄另一个引擎的开源实现，在图形行业是完全公开的正常操作。
Intel XeGTAO 本体。 这个 MIT 协议的开源实现结构最清晰，值得任何自研引擎参考：三个 compute pass——PrefilterDepths（把深度构建成带预滤波的 mip 金字塔）、MainPass（地平线搜索）、Denoise（空间滤波）[7]。深度金字塔的意义与 Hi-Z 遮挡查询共享同一套基础设施：搜索步进时可以大步跨过空旷区域，把采样次数从半径线性降为对数。性能参考数字：High 质量全分辨率下，3840×2160 约 1.4 ms（RTX 3070），1920×1080 约 0.56 ms（RTX 2060）[7]。GTAO 备忘录当年的目标则是 0.5 ms @ 1080p PS4（基础 0.35 ms + 降噪 0.15 ms）[6]。十几年来，"一帧预算里给 AO 一毫秒以内"这个约束几乎没变。
还有一个所有实现共享的时空复用技巧，出自 GTAO 备忘录原文：半分辨率下每像素只采一个方向，用 4×4 双边滤波重建；同时每帧在 6 组旋转之间交替，配合指数累积缓冲做重投影——4 × 4 × 6 = 96 个有效采样方向每像素 [5]。这就是典型的屏幕空间工程哲学：单帧信息极少，靠时间维度把信息借回来。
屏幕空间反射的朴素实现是在屏幕空间沿反射方向做固定步长的线性 march。它有两个结构性缺陷：步长小了浪费采样（空旷区域大量无效步进），步大了会跳过细几何（命中不确定性）。McGuire 与 Mara 在 Journal of Computer Graphics Techniques 2014 年第 3 卷第 4 期的论文 Efficient GPU Screen-Space Ray Tracing 给出了业界沿用到今天的答案：把透视正确的 DDA 线段光栅化算法反向使用——不遍历像素画线，而是沿光线遍历它穿过的像素列 [8]。DDA 保证每个被光线穿过的像素恰好被采样一次：既不重采样（oversampling 浪费），也不漏采样（相邻像素不连续导致的穿透）。这篇论文的价值还在于它是第一个把该方法完整实现细节（含多层深度缓冲的扩展）公开的文献，作者明确说明该技术已在多个大型游戏产品中验证 [8]。
DDA 只解决"步进"，生产级 SSR 还要一堆补丁，逐个拆解：
UE 的 SSRT 框架。 UE 5.3 源码里 SSR 已迁入 ScreenSpaceRayTracing 框架：SSRTReflections 与 SSRTDiffuseIndirect 共用同一套屏幕空间光线步进与 ScreenSpaceDenoise 降噪基础设施 [14]。这体现了 UE 的架构判断：SSR 与 SSGI 本质是同一个屏幕空间光线追踪问题，只是采样目标不同。控制台变量层面，官方文档收录 r.SSR.Quality（0 到 4 档）、r.SSR.Temporal、r.SSR.HalfResSceneColor 等；美术侧的 Post Process Volume 暴露的是 Intensity、Quality（0–100，默认 50）与 Max Roughness [11][12]。SSGI 的 r.SSGI.* 家族里 LeakFreeReprojection、RejectUncertainRays 这些命名很有信息量——泄漏抑制与不确定光线拒绝，正是屏幕空间光传输的两大顽疾 [11]。
Unity HDRP。 HDRP 17.7 的 SSR override 参数暴露得最彻底，几乎是一份生产配置手册：Tracing 三档（Ray Marching / Ray Tracing / Mixed）解决"屏幕空间优先还是硬件光追优先"；Algorithm 两档（Approximation / PBR Accumulation）解决"近似重用还是逐像素积分"；再往下 Minimum Smoothness、Object Thickness、Screen Edge Fade Distance、Max Ray Steps、Max Ray Length，降噪侧的 Denoise、Denoiser Radius、Anti-flickering Strength [18]。对照上节组件清单，几乎所有补丁都有对应参数——这是一份可以直接用来反向理解 SSR 工程结构的文档。
Unity URP 与 Godot。 URP 在 17.6 才公开 SSR（Renderer Feature 加 volume override）[17]，属于轻量实现。Godot 4.7 的 SSR 参数极简：ssr_max_steps 默认 64、ssr_depth_tolerance 0.5、ssr_fade_in/ssr_fade_out 0.15/2.0，且仅 Forward+ 可用 [20]。参数数量与引擎定位一致：轻量引擎给默认好的最少旋钮，重型引擎给全部控制权。
前两节的所有算法都有一个共同软肋：单帧信息不足，必须靠随机采样，而随机采样就有噪声。时域重建因此不是某个效果的附属模块，而是整个屏幕空间体系的公共底座。
随机采样的噪声形状由随机数序列决定。白噪声 jitter 产生的能量均匀分布，视觉上最刺眼；交错梯度噪声（Interleaved Gradient Noise）是性价比极高的替代；蓝噪声把能量推向高频，经 TAA 的低通特性过滤后视觉质量最好。Unity URP 的 SSAO 文档把这一点做成了官方选项：Method 属性可在 Interleaved Gradient Noise（静态）与 Blue Noise 之间选择，官方说明后者在相机运动时表现更细腻 [15][16]。选择噪声形状的本质是预判下游重建滤波器的频响——这是屏幕空间工程里最容易被忽略的耦合。
时域累积的标准流程：当前帧结果按运动矢量重投影到上一帧坐标，与历史帧加权混合。难点全部在例外情况：相机切换（历史无效）、遮挡脱露（当前帧看得见、历史帧看不见）、运动物体边缘（历史像素属于别的表面）。处理不当就是 ghosting。
GTAO 的做法前面已经提过：6 组旋转交替加指数累积 [5]。UE 的实现里有 GTAO_VARIANCE_CLIPPING 开关 [14]。把这个思想推到系统性高度的是 SVGF：Christoph Schied、Anton Kaplanyan、Chris Wyman、Chaitanya、Burgess、Dachsbacher 与 Lefohn 在 HPG 2017（7 月 28–30 日，洛杉矶）发表的 Spatiotemporal Variance-Guided Filtering: Real-Time Reconstruction for Path Traced Global Illumination [9]，核心是用一阶矩与二阶矩在线估计局部方差，方差大的区域加大空间滤波半径、时域上则用方差引导的裁剪容忍更多历史帧。SVGF 的 a-trous 小波滤波与方差引导裁剪后来成了几乎所有实时降噪器的骨架。
值得强调的工程判断是：屏幕空间效果的降噪和 TAA 的边界正在模糊。XeGTAO 的 README 写得很直白：实现依赖内置的空间降噪，并在 TAA 可用时把时域累积直接交给 TAA（通过开启时域噪声来配合）[7]。换句话说，现代管线里屏幕空间效果只需要产出"带正确统计特性的噪声"，时域收敛交给管线里已有的 TAA/升级器——重复做两遍时域滤波既浪费带宽又会引入双重 ghosting。
时域重建的质量上限由运动矢量的质量决定。这是很多团队踩过的坑：SSR/GTAO 在静态场景完美，一开角色动画就糊或闪——根因往往是蒙皮网格的运动矢量没有正确输出，或半透明粒子写入了错误的深度与运动信息。HDRP 的 SSAO 参数表里 Ghosting Reduction、Occluder/Receiver Motion Rejection 这类旋钮的存在 [18]，本身就在提醒：重投影错误的处理是参数级工程，不是自动的。引擎渲染组在接入任何屏幕空间效果前，第一个该审的不是效果参数，而是全场景运动矢量与深度的完整性审计清单。
另一个需要精确划界的常见误解：有了神经升级器，屏幕空间效果可以随便降质量。先核实官方 feature 清单（2026-10 查证）：NVIDIA DLSS 的官方特性集为 Multi Frame Generation、Dynamic Multi Frame Generation、Frame Generation、Ray Reconstruction、Super Resolution、DLAA 与 Reflex [21]；AMD FSR Redstone 一代为 FSR Upscaling、Frame Generation、Ray Regeneration 与 Radiance Caching（官方将 Radiance Caching 描述为实时全局光照）[22]；Intel XeSS 3 为 XeSS-SR、XeSS-FG 与 XeLL [23]。三个家族的官方特性集里都没有 ambient occlusion 或 screen-space reflection 输出。
但要精确措辞：Ray Reconstruction 与 Ray Regeneration 是对已采样光线信号的重建去噪，Radiance Caching 是 GI 缓存——它们都不计算 AO 或 SSR，不产生新的光传输信息。引擎仍需自己算好这些效果，升级器只是把带噪声的结果做时域上采样。二者的真实耦合关系反而是：屏幕空间效果的噪声越大，升级器的重建负担越重、伪影风险越高；所以接入 DLSS/FSR 的项目里，屏幕空间效果的输出噪声统计特性（噪声颜色、方差均匀性）需要与升级器联调，而不是各自为政。
屏幕空间效果在移动端 tile-based 架构上有结构性代价。Apple 官方文档明确其 GPU 采用 tile-based deferred rendering：几何全部处理完后才对每个 tile 做着色，中间结果保存在高速 tile memory（imageblock），其带宽远高于设备内存、访问延迟低得多 [24]；Arm Mali 同样按 16×16 tile 片上保存帧缓冲数据 [25]。Vulkan 官方指南则给出跨厂商实践：善用 loadOp/storeOp、transient attachment 让中间缓冲不落显存 [26]。
问题在于：AO 与 SSR 都需要跨 pass 随机读取全屏深度与法线，这恰恰打破了"中间结果只在 tile memory 里流转"的模型——深度必须写回设备内存再随机读回，带宽翻倍且破坏片上合并。Godot 文档直接把限制写明：SSAO 仅 Forward+ 与 Compatibility 支持（Mobile 不支持），SSR 与 SSIL 仅 Forward+ 支持 [20]。Unity URP 的 Screen Space Shadows 文档同样注明需要 depth prepass、可能影响移动端 tile-based 渲染性能、透明物体不参与 [15]。移动端团队的常见做法是：AO 用更低频的替代（烘焙 AO 贴图、顶点 AO），SSR 直接砍掉换反射探针。
桌面端的性能预算可以汇总成一张表（均为官方或实现方公开数字，平台与分辨率见注）：
| 效果 | 平台与分辨率 | 耗时 | 出处 |
|---|---|---|---|
| HBAO（半分辨率，6 方向×6 步） | GTX 280，1600×1200 | 全链路 7.0 ms | [2] |
| Alchemy AO | Xbox 360，720p | 约 4.5 ms | [3] |
| GTAO（含时空降噪） | PS4，1080p | 约 0.5 ms | [6] |
| XeGTAO（High，全分辨率） | RTX 3070，4K | 约 1.4 ms | [7] |
| XeGTAO（High，全分辨率） | RTX 2060，1080p | 约 0.56 ms | [7] |
趋势很清晰：硬件翻了几个数量级，AO 的预算份额始终锚定在 1 毫秒以内——省出来的算力被 GI、阴影与升级器分走了。这也是给自研引擎的定价参考：屏幕空间效果的目标不是"更快"，而是在给定毫秒内把重建质量推到极限。
回看这二十年的谱系，屏幕空间效果的演化主线不是算法炫技，而是对"信息不足"这一根本约束的持续工程化对抗：HBAO 把深度缓冲升维成高度场，Alchemy 把参数倒推回渲染方程，GTAO 把内积分解析化、把采样预算搬到时间维度，SSR 把光栅化算法反向利用，SVGF 把噪声收敛变成方差估计问题。2026 年的状态是：算法层趋于稳定，工程竞争转移到了底座——深度金字塔的质量、运动矢量的完整性、方差估计的鲁棒性、与 TAA/升级器的分工边界。
对引擎开发者，本文的实践结论可以压缩成三条。第一，屏幕空间 AO 选型直接上 GTAO 形态（解析内积分 + 厚度启发式 + 时域旋转交替），HBAO/Alchemy 形态只在做极低预算的移动端时考虑；第二，SSR 的工程重心放在步进器（DDA 类）与降噪器之外的部分——厚度测试、边缘衰减、粗糙度锥参数决定了美术能不能用，而这些恰恰是文档最少写的部分；第三，任何屏幕空间效果接入前先审计运动矢量与深度输出的完整性，时域重建的 ghosting 问题九成根因在输入而不在滤波器。
一句话摘要：屏幕空间效果是把渲染方程的可见性项压进一张深度缓冲求解的工程折中——2026 年它在 Lumen 等混合光照管线中反而升格为第一优先快路径，其上限由深度预滤波、时域重投影与方差裁剪这套重建底座决定，而非采样公式本身。
Conversation
0 条