在现代实时渲染系统中，人们往往会把注意力集中在各种炫目的渲染效果上，例如阴影、环境光遮蔽（SSAO）、屏幕空间反射（SSR）、时域抗锯齿（TAA）、体积光、GPU 剔除等技术。这些功能决定了最终画面的视觉质量，也往往是渲染引擎最容易被关注的部分。然而对于引擎开发者而言，真正复杂的问题往往并不在于这些功能本身。随着渲染功能不断增加，一个更大的挑战逐渐浮现：如何让这些功能以正确的顺序、高效地协同工作？ 这正是 ASTRYN 引入 RenderGraph 渲染图架构的原因。

从某种意义上说，RenderGraph 并不是一个具体的渲染功能，而是整个渲染系统的"中央调度中枢"。它负责 管理资源依赖、组织执行顺序、计算 GPU 同步关系，并将原本复杂的渲染流程组织成一个 可扩展、可维护、可持续演进 的现代渲染架构。

当渲染管线开始变得复杂

在很多项目的早期阶段，渲染流程通常非常简单。开发者按照固定顺序执行各个渲染阶段：Shadow Pass 完成后进入 Geometry Pass，接着是 Lighting Pass，最后是 Post Process。这种方式简单直接，也容易理解。但随着项目的发展，新的功能不断加入——GPU Frustum Culling、Hi-Z Occlusion Culling、Cascaded Shadow Map、SSAO、SSR、Outline、Transparency、TAA、Tone Mapping——原本线性的渲染流程逐渐演变成一个庞大的依赖网络。

此时开发团队会发现，问题已经不再是某个功能如何实现，而是这些功能之间如何协作。例如，SSR 需要读取深度缓冲和 GBuffer；TAA 又需要读取 SSR 输出以及运动矢量；透明物体需要依赖前面阶段生成的颜色结果；Hi-Z 剔除又依赖深度金字塔的构建结果。随着依赖关系越来越复杂，手工维护执行顺序和同步逻辑的成本开始急剧上升。这也是 许多传统渲染框架后期维护困难的重要原因之一。

从"执行顺序"转向"资源依赖"

ASTRYN 在设计 RenderGraph 时，并没有把重点放在 Pass 的执行顺序上，而是选择 从资源依赖关系出发重新组织整个渲染流程。在 RenderGraph 中，每个渲染 Pass 只需要声明两件事情：它读取什么资源，以及它写入什么资源。例如，FrustumCull Pass 写入可见实例列表；Geometry Pass 读取可见实例列表并生成 GBuffer；SSAO Pass 读取深度和法线信息生成环境遮蔽结果；SSR Pass 再读取深度、法线和颜色缓冲生成反射结果。

开发者不再需要关心这个 Pass 应该放在第几个位置执行，因为执行顺序已经能够从资源依赖关系中自动推导出来。这种方式被称为 声明式渲染——开发者描述的是"需要什么"，而不是"如何调度"。渲染系统因此获得了 更高的灵活性和可扩展性。

关于 ASTRYN

ASTRYN 是基于 Orion3D 自研引擎构建的工业级实时三维平台，专注于数字孪生、实时渲染与大规模场景可视化技术研发。