TSR, Nanite, Lumen, VSM: UE5 Graphics Features Insights from Japan

TSR, Nanite, Lumen, VSM: UE5 Graphics Features Insights from Japan | Unreal Fest Gold Coast 2024

UE5 日本图形技术实践分享

本次讲座旨在分享 Epic Games Japan 团队在支持日本各类开发者（游戏、动画、漫画等）的过程中，所积累的关于 Unreal Engine 5 的图形技术知识与实践经验。

• 核心目标: 深入解析 UE5 的关键图形特性，并结合日本市场的实际案例，提供独到的见解。

虚幻引擎在日本的应用广度

在深入技术细节之前，讲座首先展示了虚幻引擎在日本娱乐产业中令人惊叹的应用广度与多样性。

• 核心观点: 虚幻引擎的应用已远超传统游戏领域，其强大的灵活性使其在日本的娱乐产业中（游戏、动画、漫画）得到了广泛且多样化的应用，涵盖了从超写实到高度风格化的各种视觉风格。

1. 游戏 (Games)

虚幻引擎能够驾驭截然不同的艺术风格，满足不同类型游戏的需求。

• 写实风格 (Realistic Graphics):

  • 关键案例: Square Enix 的 《最终幻想》 (Final Fantasy) 系列和 《王国之心》 (Kingdom Hearts) 系列。这些项目代表了业界顶级的写实渲染水平。

• 风格化图形 (Stylized Graphics):

  • 关键案例: 《女神异闻录 3》 (Persona 3) 和 《Hi-Fi Rush》。这些游戏展示了 UE 在实现非真实感、卡通化和漫画风格渲染方面的强大能力。

2. 动画 (Animation)

虚幻引擎正越来越多地被用于日本的 2D 动画制作流程中。

• 关键案例: 日本国民级TV动画 《光之美少女》（プリキュア / Precure） 的片尾动画。
• 应用细节:
  • 整个片尾动画，包括所有角色的表演，均在 UE 中完成制作和渲染。
  • Epic 官方博客曾发布过详细的工作流文章，深度解析了该项目如何利用 UE 实现其 独特的风格化图形。

3. 漫画 (Manga/Comics)

虚幻引擎也被创造性地用作漫画创作的辅助工具，以提升效率和视觉效果。

• 应用方式: UE 作为强大的 场景搭建与背景渲染工具。
• 具体流程:
  1. 场景布局与分镜 (Layouts): 漫画家在 UE 中搭建 3D 场景，用于确定画面布局和摄像机角度。
  2. 背景渲染 (Background Rendering): 直接从 UE 中渲染出高质量的背景图像。
  3. 后期修饰 (Retouching): 在渲染出的背景图像基础上，进行手动的二次绘制和风格化处理。

UE5 的发布、核心技术与开发者的期望

1. 日本游戏市场的特点与技术支持背景

这部分内容设定了讲座的讨论背景，解释了为什么性能优化是日本开发者面临的核心议题。

• 核心观点： 日本游戏市场以主机为主，这意味着开发者必须在固定且有限的硬件（PS5, Xbox, Switch）上实现流畅的运行体验，因此严格的性能优化至关重要。
• 技术支持背景： 讲者所在的 Epic Games Japan 团队，作为 开发者关系工程师 (Developer Relations Engineers)，主要通过 定制许可证 (custom licenses) 为付费客户提供深度技术支持，因此他们直接面对并帮助开发者解决 UE5 发布后遇到的各种前沿挑战。

2. UE5 的革命性演示与由此产生的“超高”期望

Epic Games 通过一系列令人惊艳的技术演示，向世界展示了 UE5 的强大能力，但这同时也为开发者设定了极高的、甚至有些理想化的期望。

革命性技术的首次亮相 (Lumen & Nanite Demo)

这是 UE5 的第一个公开演示，引入了两大核心技术，彻底改变了开发者对实时渲染的认知。

• 关键技术：
  • Nanite： 一种虚拟化微多边形几何体系统，其核心承诺是能够实时渲染近乎无限细节的多边形。
  • Lumen： 一套全动态的 实时全局光照 (Global Illumination) 和反射解决方案。
• 工作流的变革：
  • Lumen 使得高质量的动态全局光照成为可能，开发者仅需放置一个 定向光 (Directional Light) 和一个 天空光 (Skylight)，即可获得逼真的间接光照效果，理论上 不再需要预烘焙光照贴图 (Bake Lighting)。

扩展技术的应用展示 (后续演示)

随后的演示进一步展示了 UE5 在构建宏大世界方面的能力。

• The City Sample (城市示例):
  • 引入了 世界分区 (World Partition) 系统，这是一种用于高效管理和流式加载大型开放世界（如巨型城市）的全新解决方案。
• Electric Dreams (电子梦境):
  • 集中展示了利用 程序化生成 (Procedural Generation) 技术来快速构建广袤、细节丰富的自然环境（如森林）的能力。

开发者产生的“理想化”期望

这些强大的演示和免费的高质量资产，让许多开发者对 UE5 的能力产生了近乎“魔法”般的期待。

• 核心观点： 开发者们带着极高的期望开始使用 UE5，普遍认为许多传统的性能优化工作将不再必要。
• 具体表现：
  • 多边形预算似乎已成过去（因为有 Nanite）。
  • 光照烘焙的漫长等待和繁琐工作可以被彻底抛弃（因为有 Lumen）。
  • 可以无限制地、免费地使用 Megascans 这类影视级的高质量资产来构建游戏世界。

小结： 讲者通过回顾 UE5 的发布历程，巧妙地引出了后续将要讨论的核心议题： 当理想化的技术愿景（Nanite、Lumen）与严苛的现实性能限制（尤其是在主机平台上）发生碰撞时，开发者会遇到哪些具体问题，以及 Epic 的技术支持团队是如何帮助他们解决这些挑战的。

这部分内容从 UE5 带来的美好承诺切入，通过剖析早期几个著名的技术演示（Tech Demo），揭示了在光鲜背后，开发者们需要正视的技术局限与工程权衡。讲座的核心目的也在此引出： 澄清对 UE5 的模糊期望，明确当前的技术边界。

一、 UE5 带来的美好承诺

在 UE5 早期宣传中，开发者们看到了一个理想化的未来工作流：

• 高精度模型普及：可以不再依赖法线贴图（Normal Maps），直接使用影视级的高精度资产。
• 海量免费高质量资产：通过 Megascans 这样的资源库，可以免费获取大量优质素材。
• 自动化世界构建：借助 PCG (Procedural Content Generation) 和 World Partition 等工具，开发者无需再手动“堆砌”场景。

然而，经验丰富的开发者们，尤其是日本的开发者，从官方发布的技术演示中嗅到了一些“妥协”的味道。

二、 技术演示中的“蹊跷”之处：理想与现实的差距

通过对几个标志性 Demo 的观察，可以发现为了实现惊艳的实时效果，Epic 不得不做出了一些关键性的规避和权衡。

• 《Lumen in the Land of Nanite》（最初的 Demo）

  • 核心观察：场景中没有草地，几乎完全由无机材质（如岩石、金属）构成。
  • 背后揭示的问题：这暗示了当时 Nanite 和 Lumen 对于处理大量带有 Alpha 透明/遮罩的复杂几何体（如草、树叶等植被）存在性能或技术上的挑战。

• 《黑客帝国：觉醒》 (The City Sample)

  • 核心观察 1：所有的树都没有叶子。官方解释是为了配合“秋季”的设定，但这更像是一个为了规避技术难题而做的美术决策。
  • 核心观察 2：角色的反射是纯黑的。这表明在复杂的动态开放世界中，高质量的实时反射（尤其是对动态物体的反射）仍然是一个巨大的性能开销。
  • 核心观察 3：玩家无法进入任何建筑物内部。这极大地简化了光照和场景管理，避免了处理室内外无缝切换（Interior/Exterior Transition）这一渲染难题。

• 《Electric Dreams》 Demo

  • 核心观察：这个 Demo 终于包含了草地和树叶。
  • 但代价是：其所需的 PC 配置要求极高 （really really high），远超主流游戏硬件的承受范围，表明这套方案的性能开销巨大，离商业化游戏的普及应用还有距离。

三、 本次讲座的核心与焦点

基于以上观察，讲座的目的并非唱衰 UE5，而是进行一次“期望管理”，帮助开发者建立正确的认知。

• 核心概念：明确技术边界 (Clarifying the Boundaries)

  • 讲座的目标是分享从支持大量日本开发者的经验中总结出的 UE5 当前的技术边界。这能帮助团队在项目立项和技术选型时，做出更符合实际的判断，避免陷入不切实际的幻想。

• 技术焦点

  • 本次讨论将主要集中在 实时渲染 (Real-time Rendering) 领域。
  • 尤其关注在 性能受限的硬件（如游戏主机） 上的表现和挑战。
  • 尽管如此，这些内容对于从事 VFX 或虚拟制片（VP）的开发者同样具有很高的参考价值。

• 重要声明 (Disclaimer)

  • 讲座中会提及大量“UE5 不支持这个”或“这个实现起来非常困难”的观点。
  • 但这 绝不意味着 UE5 是无用的，而是为了客观、深入地剖析其在当前阶段的优势与局限。

多帧处理技术 (Multi-Frame Processing)

讲座的核心技术部分从 多帧处理 (Multi-Frame Processing) 开始。这并非单一技术，而是一类技术的总称。

• 核心思想: 这类技术旨在通过两种主要方式来优化渲染：
  1. 利用多个历史帧的信息来增强当前帧的渲染质量（例如时间性抗锯齿）。
  2. 将单个重量级任务的计算量分散到多个帧上执行，以平滑性能开销。

高分辨率渲染的性能挑战

在深入具体技术之前，讲座首先阐述了为什么多帧处理技术在现代渲染中至关重要，其根本原因在于原生高分辨率渲染的巨大性能压力。

• 核心观点: 尽管 GPU 性能 在不断增长，但市场和玩家对分辨率的要求也在同步提高（例如 2K、4K），这使得以原生分辨率进行实时渲染至今仍是一个巨大的性能挑战。

• 性能瓶颈示例 (Performance Bottleneck Example):

  • 场景 (Scene): 以一个特定的城市场景（City Sample）为例。
  • 渲染目标 (Target): 4K 原生分辨率 (Native 4K)。
  • 性能结果 (Performance Result): 在某款特定的 GPU 上，渲染一帧需要 57 毫秒 (57ms)。
  • 帧率换算 (FPS Conversion): 这意味着帧率低于 20 FPS，对于绝大多数游戏或实时应用来说，这都远达不到流畅运行的标准。

这个例子明确指出了问题的关键：即使在强大的硬件上，面对复杂的场景和高分辨率的要求，单纯依赖蛮力进行 原生渲染 (Native Rendering) 往往是不可行的。这为后续引入时间性超采样（Temporal Super Resolution）、时间性抗锯齿（TAA）等多帧技术提供了充分的理由和背景。

时间超分辨率 (TSR) - 以小博大的渲染智慧

1. 高分辨率渲染的性能挑战

• 核心观点: 在现代游戏引擎中，即便有 Nanite 这样的高效几何体渲染技术，以原生 4K 分辨率 渲染复杂场景的开销依然极其巨大。
• 关键数据: 讲座中展示的案例表明，原生 4K 渲染一帧需要 57 毫秒，换算下来帧率低于 20 FPS，远达不到流畅运行的标准。
• 根本原因: 随着场景复杂度和渲染技术的提升（如 Nanite 和 Lumen），在高分辨率下需要处理的像素和数据量呈指数级增长，导致 GPU 负载极高。

2. TSR: Unreal Engine 的时间超分辨率方案

• 核心定义: TSR (Temporal Super Resolution) 是 Unreal Engine 内置的一种时间超分辨率（Upscaling）技术。它通过渲染一个较低的 内部分辨率 (Internal Resolution) 画面，然后利用算法将其放大到最终的目标分辨率。

• 惊人的效果:

  • 视觉质量: 从 1080p 内部渲染分辨率通过 TSR 放大到 4K，其最终画面质量与原生 4K 渲染的画面几乎没有肉眼可见的差异。
  • 性能提升: 在同样场景下，使用 TSR (1080p → 4K) 的渲染耗时从原生 4K 的 57ms 骤降至 26ms。这是一个决定性的性能优化。

• 对 Nanite 和 Lumen 的协同增益:

  • 关键术语: 内部渲染分辨率 (Internal Resolution)
  • 核心观点: 由于 Nanite 和 Lumen 这类核心系统是在内部渲染分辨率上运行的，TSR 的使用意味着它们需要处理的数据量也大幅减少，从而 显著降低了 Nanite 和 Lumen 本身的 GPU 负载。这是一种系统级的性能提升。

3. TSR 的核心工作原理与依赖

• 核心机制: TSR 实现高质量放大的秘诀在于 累积和复用过去多帧的样本 (Samples)。它不仅仅是放大当前帧，而是利用时间维度上的历史信息来重建出高分辨率图像的细节。

• 内部渲染分辨率与历史帧的依赖关系:

  • 原生分辨率: 如果内部渲染分辨率与目标分辨率相同，TSR 无需工作。

  • 低内部渲染分辨率: 当内部渲染分辨率降低时，为了达到目标分辨率所需的像素细节，TSR 必须回溯参考过去的历史帧，从中采集足够的样本来填充细节。

  • 更低的内部渲染分辨率: 内部渲染分辨率越低，当前帧提供的信息就越少，TSR 就需要回溯到更久远的历史帧才能收集到足够数量的样本。

  核心结论: 内部渲染分辨率越低，TSR 需要依赖的历史帧数量就越多、时间跨度就越长。

• 关键影响：帧率 (FPS) 的作用

  • 核心观点: TSR 为了达到理想画质，所需要参考的 历史总帧数 (或总样本数) 是相对固定的。然而，这些历史帧在真实时间上的跨度则完全取决于当前的帧率。
  • 举例说明:
    • 在 60 FPS 下，参考过去的 4 帧，时间跨度约为 66ms。
    • 在 30 FPS 下，同样参考过去的 4 帧，时间跨度则长达 133ms。
  • 重要引申: 低帧率意味着 TSR 用于重建画面的历史信息来源更“陈旧”。这可能会在物体快速移动时，导致更明显的鬼影（Ghosting）或其他时间性瑕疵（Temporal Artifacts），因为历史信息与当前帧的差异过大。

Temporal Super Resolution (TSR) 的挑战与依赖

本节深入探讨了 TSR 在实际应用中面临的核心挑战，特别是其对渲染管线稳定性的高度依赖，以及由此产生的常见视觉瑕疵。

1. TSR 对帧历史的依赖与收敛速度

• 核心观点: TSR 的质量并非凭空而来，它依赖于累积和融合过去多帧的信息来重建一帧高分辨率的图像。为了达到理想的清晰度（即收敛），需要稳定数量的历史帧样本。

• 关键机制:

  • 当渲染分辨率降低或 帧率（FPS）下降 时，TSR 为了凑够达到收敛所需的样本数量，就必须回溯到时间上更久远的帧。
  • 这意味着，低分辨率或低帧率会迫使算法依赖那些与当前画面差异可能已经很大的历史数据。

2. 核心问题：鬼影 (Ghosting) 的产生

• 关键术语: 鬼影 (Ghosting)

  • 这是 TSR 最常见的视觉瑕疵。当算法被迫使用过旧的历史帧时，这些旧帧的残留信息就会像“鬼影”一样叠加在当前运动的物体上。

• 产生场景:

  • 极端情况: 在讲座的示例中，当内部渲染分辨率降至 25% 且摄像机快速移动时，整个屏幕出现严重的模糊和拖影，这就是典型的鬼影现象。
  • TSR 的优势: 相对地，当摄像机静止时，即使在低分辨率下，TSR 也能利用稳定的历史帧信息，逐渐收敛成一张非常清晰锐利的高分辨率图像。这凸显了 TSR 在静态场景下的强大威力。

3. 鬼影的根源：不只是 GPU，CPU 瓶颈是关键

• 核心观点: 导致鬼影的帧率下降，其根源并 不总是 GPU 性能不足。CPU 瓶颈同样是罪魁祸首，而且更难通过传统方式规避。

• 关键分析:

  • CPU 瓶颈来源: 游戏中的 动画系统、资源加载、物理或复杂的游戏逻辑 都可能导致 CPU 负载过高，从而引发帧率骤降。
  • 动态分辨率的局限性: 动态分辨率 (Dynamic Resolution) 是一种常见的 GPU 优化手段，它通过降低渲染分辨率来减轻 GPU 负担。但是，这种方法 完全无法缓解因 CPU 瓶颈导致的帧率下降。
  • 根本要求: 要想保证 TSR 的高质量输出（即避免鬼影），必须同时优化 CPU 和 GPU 的性能，确保整个系统的帧率稳定。

4. 另一大关键依赖：速度矢量 (Velocity Vector) 的准确性

• 核心观点: TSR 并非简单地混合历史图像，它依赖速度矢量来“预测”上一帧的像素在当前帧应该出现的位置。

• 关键机制:

  • 速度矢量 (Velocity Vector): 通常在 G-Buffer 中生成，它记录了屏幕上每个像素的运动方向和速度。TSR 使用这个数据来对历史帧进行 重投影 (Reprojection)。
  • 失败场景: 如果某个区域的 速度矢量计算不正确、不精确或完全缺失 （例如，某些半透明材质、程序化动画或非刚体变换），TSR 将无法正确追踪物体的运动。
  • 结果: 错误的重投影会导致严重的视觉错误，如物边缘的撕裂、抖动或错误的像素堆积，其效果可能比鬼影更糟糕。

5. 实践与调试建议

• 重要参考: 讲座中提到了官方文档，这是深入理解和调试 TSR 的宝贵资源。
• 文档内容: 包含 TSR 的收敛过程详解、如何调试相关问题，以及需要参考多少历史帧等关键参数的指导。
• 行动建议: 对于任何在项目中启用 TSR 的开发者来说，强烈建议详细阅读相关文档，以便更好地诊断和解决遇到的视觉问题。

时域超分辨率（TSR）的挑战与 Lumen 的多帧架构

一、TSR 的关键：精确的运动向量 (Velocity Vector)

在时域算法中，运动向量的准确性直接决定了最终图像的质量，尤其是在处理动态物体时。

• 核心观点：不正确的运动向量是导致 TSR 产生拖影（Ghosting） 的主要原因。如果物体的实际像素运动与提供给 TSR 的运动向量不匹配，重建算法就会从错误的上一帧位置采样，从而产生明显的视觉瑕疵。

• 问题案例分析：

  • 讲座中以一个旋转物体的 Debug 视图为例，展示了当物体旋转但其运动向量没有随之正确更新时，产生的严重拖影问题。
  • 从 Debug 视角看，即使物体在旋转，其运动向量场却可能是静止或错误的，这表明渲染管线中生成运动向量的环节出了问题。

• 解决方案与挑战：

  • 关键在于正确生成运动向量。一旦为旋转物体生成了与其运动相匹配的正确向量，TSR 的拖影问题便会立即消失。
  • 然而，为所有情况生成正确的运动向量是一个复杂的问题。针对不同类型的运动（如 骨骼动画、顶点着色器动画、刚体运动 等），运动向量的生成方法各不相同，需要特殊处理才能保证精度。

二、Lumen 的核心设计：多帧计算与渐进式收敛

Lumen 作为 UE5 的核心实时全局光照（GI）功能，其设计哲学是在保证高质量的同时，将巨大的计算开销控制在实时渲染的预算内。

• 核心观点：为了在性能预算内实现实时计算，Lumen 的核心设计理念是 将复杂的 GI 算法拆分，分布到多个连续的帧上执行，而不是强求在一帧内完成所有计算。

• 架构特性：渐进式收敛 (Gradually and Incrementally Converging)

  • 这种多帧分布的策略导致了所谓的 “渐进式收敛”。这意味着 GI 的结果不是在一帧内瞬间完成的，而是随着时间推移，在几帧内逐渐逼近最终的正确光照效果。
  • 这是一种典型的 时间换空间/性能 的策略，通过利用时域上的连续性，平摊每一帧的计算压力。

• 视觉表现与案例：

  • 具体表现：当场景光照发生剧烈变化时（例如开关灯、遮挡光源），GI 的响应并不是瞬时的，而是会有一个平滑的过渡过程。
  • 讲座案例：当一个天花板瞬间封闭，完全遮挡天光（Skylight）时，整个场景并不会立即变黑。相反，GI 会在几帧的时间里逐渐消失，光照效果平滑地过渡到最终的黑暗状态。

• 开发者须知：

  • 这种“渐进式”的视觉表现是 Lumen 架构的固有特性，而非 Bug。
  • 理解这一点对于调试和美术制作至关重要，这是在实时性能和最终质量之间取得平衡的必然结果，也是开发者和用户经常会遇到的疑问。

Lumen 的时序累积：性能与延迟的权衡

1. 问题的根源：时序处理的副作用

为了在实时渲染中实现高质量的全局光照（GI），Lumen 和 UE5 的许多现代渲染技术都严重依赖于时间累积（Temporal Accumulation）的方法。

• 核心机制: 这种技术的本质是利用历史帧的信息，并将复杂的计算（如GI）分摊到多个连续帧中去执行，从而避免在单帧内产生巨大的性能开销。
• 不可避免的副作用: 这种“分摊”处理带来了两个典型的副作用：
  • 延迟 (Delay): 当场景光照发生剧烈变化时（例如，光源瞬间熄灭），GI效果不会立即更新，而是会有一个逐渐变化的过程。这就是讲座中提到的“GI gradually disappear”现象。
  • 鬼影 (Ghosting): 快速运动的物体可能会因为历史帧信息的残留而产生拖影。

2. 最具挑战的场景：自发光材质与摄像机切换

Lumen的延迟问题在某些特定场景下会变得尤为突出和明显。

• 核心观点: 自发光（Emissive） 材质作为主要光源的场景是延迟问题的“重灾区”。
• 关键原因: 当摄像机发生 瞬间切换（Camera Cut） 时，渲染系统无法复用前一视角的任何历史数据。Lumen必须从零开始重新计算新视角下的全局光照，这导致了一个非常明显的、从无到有的“渐亮”过程。
• 现状: 这也是为什么目前版本中， 完全基于自发光的光照仍被标记为“实验性（Experimental）”功能。开发者在使用时需要充分意识到这一限制。《黑客帝国：觉醒》中的霓虹灯场景只是一个技术范例，并非代表该技术已完全成熟。

3. 解决方案与当前局限

Epic 已经意识并着手解决这个问题，但目前的方案尚不完美。

• 部分解决方案: UE5 已经为 实时过场动画（Real-time Cutscenes） 实现了特定的预计算功能，可以在一定程度上缓解摄像机切换时的GI延迟。
• 当前局限:
  • 额外GPU开销: 该方案需要消耗更多的GPU资源。
  • 不支持随机切换: 它仅适用于路径和视点预先确定的过场动画序列，无法解决玩家在游戏中 自由、随机地切换摄像机 时产生的延迟问题。

虚拟化与流式传输技术

Nanite：虚拟化微多边形几何体

• 核心目标: Nanite 是一套用于实时渲染 极高多边形密度（Very High-Density Polygon） 模型的虚拟化几何体系统。
• 关键技术: 它代表了引擎在 虚拟化（Virtualization） 和 流式传输（Streaming） 方向上的重要进展，使得在屏幕上呈现电影级别的模型细节成为可能，而无需担心传统的多边形数量预算。接下来的内容将深入探讨其工作原理。

1. Nanite 简介：像素级别的几何渲染

讲座首先展示了 Nanite 的核心能力： 实时渲染极高密度的多边形网格 (Polygon Mesh)。

• 核心特征: Nanite 能够处理海量的三角形，其渲染细节可以精确到像素级别。这意味着在最终画面中，许多三角形的尺寸可能只有一个像素那么大，这在传统渲染管线中是难以想象的。
• 最终效果: 即使场景中包含大量的高精度模型，Nanite 也能流畅地实时渲染，从宏观到微观都展现出惊人的细节。

2. 核心技术：虚拟化几何 (Virtualized Geometry)

Nanite 所依赖的底层技术被称为 虚拟化几何 (Virtualized Geometry)。这是一种通用的技术思想，并非 Nanite 独有。

• 核心观点: 通过对几何数据进行虚拟化管理和 流式加载 (Streaming)，可以极大地降低显存占用和 GPU 的渲染开销。
• 类比技术: 这种“虚拟化”思想在图形学中并不新鲜，一个广为人知且更容易理解的例子就是 虚拟纹理 (Virtual Texture)。

3. 用虚拟纹理 (Virtual Texture) 来理解虚拟化几何

为了更好地理解 Nanite 的工作原理，我们可以先回顾一下虚拟纹理技术。

• 传统纹理加载:

  • 在不使用虚拟纹理时，渲染一个物体需要将其完整的纹理资源一次性全部加载到显存中，无论摄像机当前能看到纹理的哪个部分，或者需要多高的精度。

• 虚拟纹理的工作方式:

  • 按需加载: 只加载摄像机当前视野内实际可见的纹理部分到显存中。
  • 动态流式处理: 当视角移动，新的部分进入视野时，系统会 流式加载 (Streaming in) 所需的纹理数据；而不再可见的部分则会被 流式卸载 (Streaming out)。
  • Mipmap 优化: 虚拟纹理与 Mipmap 结合得非常好。系统可以根据物体距离摄像机的远近， 按需加载不同精度的 Mipmap 等级。
    • 示例: 在一个巨大的开放世界场景中，离摄像机近的地面会加载高分辨率的 Mipmap，而远处的地面则只加载低分辨率的 Mipmap，从而极大地节省了显存。

• 虚拟纹理的优势:

  • 显著降低显存占用: 无需为整个场景的最高精度纹理预留空间。
  • 支持超大分辨率纹理: 使得使用远超显存容量的纹理资源成为可能。

4. 总结：Nanite 是几何体版本的“虚拟纹理”

理解了虚拟纹理后，Nanite 的概念就变得非常清晰了。

• 核心观点: Nanite 本质上就是将虚拟纹理的思想应用到了多边形网格 (Polygon Mesh) 上。
• 工作模式类比:
  • 虚拟纹理管理和流式加载的是 纹素 (Texel)。
  • Nanite 管理和流式加载的则是 多边形 (Polygon) 或更高效的几何数据簇。

通过这种方式，Nanite 实现了对海量几何数据的虚拟化管理，只将渲染当前帧所必需的、符合当前细节要求的多边形数据提交给 GPU，从而实现了前所未有的几何渲染能力。

流式加载机制、局限性与解决方案

一、 Nanite 的核心机制：多边形的虚拟纹理化

核心观点：Nanite 的本质可以理解为“多边形版本的虚拟纹理 (Polygon version of Virtual Texturing)”。 它将处理几何体的方式从传统的 LOD (Level of Detail) 切换为一种更精细、更动态的流式加载系统。

• 工作原理：

  • 预集群 (Pre-clustering): 几何体资源在导入时会被预处理，分解成许多微小的三角形簇（Clusters）。
  • 层级数据结构 (Hierarchical Data Structure): 这些簇被组织成一个金字塔式的层级结构。底层是原始的高精度簇，越往上层，簇被不断合并，形成更低精度的版本。这在概念上与虚拟纹理的 Mipmap 非常相似。

• 可视化理解： 讲座中通过强制偏移显示了低多边形簇，以便于理解。在正常渲染中，这些低精度版本只会在摄像机距离非常远时才会被渲染和加载，用户在近处观察时是无感知的。整个建筑的宏观结构不变，但构成其表面的微观簇会根据视点动态切换。

二、 流式加载的固有局限性

核心观点：与虚拟纹理一样，Nanite 也是一个基于“按需流式加载”的系统，这导致了在视点突变时不可避免的延迟。

• 决策前置： 在开始流式加载（Streaming）之前，系统必须首先判断：

  1. 哪些物体在视锥内是可见的？
  2. 这些物体的哪些部分是可见的？
  3. 根据距离和屏幕占比，需要加载哪个层级的细节（需要多精细的簇）？

• 问题触发场景： 当摄像机发生瞬时、大幅度的移动时，例如 传送 (Teleport) 或 快速切镜 (Switch Cameras)。

• 视觉表现： 在新视点所需的高精度数据流式加载完成前，系统会先显示当前内存中可用的最低精度 Cluster。这会导致模型或纹理（对于虚拟纹理）在短暂的瞬间看起来非常 粗糙 (Rough) 或模糊，直到高清数据加载完毕。

三、 针对性解决方案：过场动画的预流送

核心观点：针对过场动画等摄像机路径预知的场景，UE 提供了预流送（Pre-streaming）机制来解决加载延迟问题。

• 关键功能与工具：

  • Cinematic Pre-streaming: 这是一个专门用于解决此问题的核心功能。
  • Movie Render Cues Pre-streaming Recorder: 这是一个具体的工具，用于记录在过场动画序列中，每一帧需要哪些 Nanite 数据和虚拟纹理数据。

• 工作流程：

  1. 记录 (Record): 开发者使用记录器来“演练”一遍整个过场动画，工具会分析并生成一份详细的“资源需求清单”，精确记录每个镜头需要加载的数据。
  2. 预加载 (Pre-load): 在过场动画正式播放前，引擎根据这份清单，将所有需要的数据一次性或分阶段地提前加载到内存中。

• 最终目标： 通过提前加载， 消除 (Eliminate) 切换镜头时因数据流送而产生的延迟，保证过场动画从始至终的视觉质量。

• 关键限制与游戏内应用：

  • 该预流送方案仅适用于路径预先确定的过场动画 (Cutscenes)**。
  • 对于玩家可以自由传送或进行不可预测的快速移动的 实时游戏过程 (Game Play)，该方案无效。因为引擎无法预知玩家的下一步行为，所以流送延迟的问题在这些场景下依然可能发生。

虚拟化与流式传输总结

本节首先对之前讨论的虚拟化技术（虚拟纹理和 Nanite）进行了总结，并指出了其核心挑战与现有解决方案。

核心思想与机制

• 核心技术: 数据虚拟化 (Data Virtualization)。为了在有限且恒定的内存预算下管理海量数据（高精度模型和纹理），Nanite 和虚拟纹理（Virtual Textures）都采用了虚拟化技术，将资源切分为小块（Pages/Clusters）。
• 加载机制: 流式传输 (Streaming)。系统仅在需要时，根据摄像机视角动态地将所需的数据块从硬盘加载到内存/显存中。

主要挑战：流式传输延迟

• 问题: 当摄像机移动过快时，流式传输系统可能无法及时加载所需的高精度数据。
• 表现: 玩家会短暂地看到低分辨率的资源，例如模糊的纹理（低级 Mipmap）或低细节度的模型。

解决方案与局限性

• 针对运镜（Cutscenes）: 虚幻引擎提供了 过场预流式传输 (Cut Pre-streaming) 功能。它允许开发者预先指定镜头路径，引擎则会提前将路径上即将出现的资源加载进来，从而保证过场动画的视觉质量。
• 针对突变（Teleportation）:
  • 局限性: 对于无法预测的、瞬时的摄像机切换（如玩家传送、随机切换安防摄像头视角），引擎无法预知需要加载的资源，因此该场景目前尚不被原生支持。
  • 变通方案: 开发者需要自行实现一些视觉效果来掩盖加载延迟，最常用的方法是使用 淡入淡出 (Fade in/out) 效果，在黑屏或白屏的瞬间完成资源加载。

现有资产的利用 (Utilization of Existing Assets)

本章开启了一个新的主题：如何利用现有的高质量资产库，结合 UE5 的新功能，来变革内容创作的工作流。

Quixel Megascans 与 Bridge：加速场景搭建

• Quixel Megascans: 这是一个庞大的、基于真实世界扫描（摄影测量法）创建的超高精度 3D 资产库。
  • 关键特性: 对虚幻引擎用户完全免费。
• Quixel Bridge: 这是内嵌于虚幻引擎的一项功能，它提供了一个无缝的接口，允许开发者直接将 Megascans 库中的资产通过 拖拽 (drag-and-drop) 的方式放入自己的场景中。

新一代实时创作工作流

• 核心组合: Megascans (超高精度资产) + Nanite (无限细节) + Lumen (动态全局光照)。
• 关键优势: 这一技术组合彻底改变了传统的制作流程，实现了真正的 所见即所得 (WYSIWYG) 的实时场景构建。
  • 告别预览渲染: 创作者无需再像过去一样，先在低质量的预览模式下搭建场景，再花费漫长时间等待离线渲染器生成最终图像。
  • 实时最终画质: 艺术家可以直接在最终画质的光照和几何体环境下进行创作和调整，极大地提升了迭代效率和艺术表现力。

实践中的挑战

• 引出问题: 讲座提到，尽管这个工作流非常强大，许多日本客户在使用 Megascans 和 Marketplace (商城) 的资产时，还是遇到了各种各样的问题。这暗示了接下来的内容将会深入探讨这些高质量资产在实际项目中所面临的挑战和解决方案。

Lumen GI 实践 - 模块化资产与 Lumen Card 的冲突

1. 问题背景：为何 Marketplace 和扫描资产在 Lumen 中表现不佳？

在使用虚幻引擎进行开发时，我们经常会利用 Marketplace 或 Megascans 等渠道获取的现成资产来加速开发流程。然而，许多开发者发现，这些资产在启用 Lumen 全局光照（GI）后，往往会出现渲染效果错误或 GPU 开销异常高昂的问题。

这背后的一个核心原因，可以归结为 “模块化资产与 Lumen Card 的冲突” （Modular Assets versus Lumen Card Problem）。

2. 核心概念解析

要理解这个冲突，首先需要明确两个关键概念：模块化资产和 Lumen Card。

2.1 模块化资产 (Modular Assets)

• 核心观点： 模块化资产是一种建模和场景构建方法，它将大型、复杂的对象（如一栋建筑）拆解成一系列独立的、可重复使用的小部件（如墙壁、窗户、地板、天花板等）。
• 工作方式： 开发者在引擎中像搭积木一样，通过组合这些标准化的模块来构建最终的复杂场景，而不是直接使用一个包含所有细节的、巨大的、一体化的模型（Monolithic Mesh）。

2.2 Lumen Card

• 核心观点： Lumen Card 是 Lumen 系统为了 极大加速全局光照（GI）计算 而采用的一种简化几何代理。
• 工作原理：
  • 为了避免在原始的高精度模型上进行昂贵的光线追踪，Lumen 会为场景中的每个静态网格（Static Mesh） 预计算（precompute） 并生成一组简单的平面（Planes）。
  • 这些平面被称为 Lumen Card，它们会大致包裹并代表原始物体的形状、位置和表面属性（如颜色、自发光等）。
  • Lumen 的 GI 计算主要是在这个由 Lumen Card 构成的简化场景中进行的。
• 关键特性： Lumen Card 的 核心是“简化”。即使是几何形状非常复杂的物体（例如树木、汽车），其对应的 Lumen Card 也是由非常有限的几个简单平面构成的。

3. 根本性冲突：当“一体化”资产遇到 Lumen Card

现在，我们可以清楚地看到问题所在。

• 核心观点： Lumen Card 的生成算法是基于物体形状相对简单的假设设计的。当它遇到一个巨大且内部结构极其复杂的“一体化”网格时，这个假设就被打破了。

• 问题剖析：

  • 假设你有一个完整的房屋模型，它是一个 单一的 Static Mesh，包含了所有的内部房间、隔墙、楼梯和天花板。
  • Lumen 试图为这个复杂的单体模型生成 Lumen Card。但由于卡片是简单的平面，它们无法精确地贴合模型复杂的内外结构。
  • 结果是，生成的 Lumen Card 可能会穿透墙壁，或者完全无法覆盖某些内部空间，导致代表场景几何的代理体是完全错误的。

• 导致的后果：

  • 渲染错误： 当 Lumen 在这个错误的、简化的场景（Card 场景）中计算光照时，就会发生错误。光线会“穿过”不存在于 Card 场景中的墙壁，导致漏光、错误的阴影和完全不正确的间接光照。
  • 可视化调试： 在讲座的示例中，Lumen 无法正确计算着色的区域被标记为粉色，这些区域正是因为 Lumen Card 未能正确匹配原始几何形状而导致的 GI 计算失败。

4. 结论与实践准则

• 基本原则： 要想让 Lumen 正确、高效地工作，必须采用模块化的方式来构建场景资产。
• 最佳实践：
  • 拆分模型： 将复杂的结构（尤其是建筑内部）拆分为独立的墙壁、地板、天花板等模块化部件。
  • 确保简化性： 保证每个独立的 Static Mesh 在几何上都相对简单。这样，Lumen 就能为每一个小模块生成准确的 Lumen Card。
  • 正确组合： 在场景中将这些模块拼接起来后，它们各自正确的 Lumen Card 就能共同构成一个精确的、用于 GI 计算的简化场景，从而得到高质量且性能可控的全局光照效果。

Lumen 性能优化 - 处理复杂几何体 (如建筑)

本节内容聚焦于 Lumen 在处理由大量模块化资产构成的复杂物体（如城市建筑）时所面临的性能挑战，以及 Unreal Engine 提供的解决方案及其带来的新问题。

一、 核心挑战：模块化资产与 Lumen Card 数量爆炸

• Lumen 的基本使用原则: 官方建议使用简单的几何体（如模块化资产）来组合成复杂的形状。这是因为 Lumen Card 本身是对几何体的简化表示，更适合处理简单形状。

• 引发的问题: 当遵循这一原则时，一个由大量模块化资产（例如墙壁、窗户、地板模块）组成的复杂物体（如一栋建筑），会导致每个模块都生成自己的 Lumen Card。

  • 后果: 单个建筑会产生 海量的 Lumen Card。
  • 性能瓶颈: 如此庞大的 Lumen Card 数量会急剧增加 GPU 处理负载 (Processing Load) 和 内存消耗 (Memory Consumption)，导致实时渲染变得不切实际。

二、 解决方案：通过 Ray Tracing Group ID 合并 Lumen Card

为了解决上述性能瓶颈，Unreal Engine 提供了一种高效的合并机制。

• 核心机制: 引擎能够将属于同一组的物体的 Lumen Card 合并 (Merge) 成一个。

  • 关键术语: Ray Tracing Group ID。这是一个分配给静态网格体组件的标识符。
  • 合并规则: 拥有 相同 Ray Tracing Group ID 的多个物体的 Lumen Card 会被引擎自动合并成一个单一、更大的 Lumen Card。
  • 适用性: 这一机制无论在 软件光线追踪 (Software Ray Tracing) 还是 硬件光线追踪 (Hardware Ray Tracing) 模式下都同样有效。

• City Sample 中的实践:

  • 在《黑客帝国》城市示例中，构成同一栋建筑的所有模块化资产都被赋予了 相同的 Ray Tracing Group ID。
  • 结果: 整栋建筑，无论由多少个模块构成，最终在 Lumen 场景中只被表示为 一个合并后的 Lumen Card。
  • 优势: 这种方法 极大地减少了 Lumen Card 的总数，显著降低了 GPU 负载，使得大规模城市场景的动态全局光照成为可能。

三、 新的权衡：合并带来的几何简化问题

这个高效的解决方案也带来了一个新的挑战，形成了一种性能与质量的权衡。

• 问题的根源: Lumen Card 的本质是几何体的简化表示。它擅长表示简单凸面体，但对于复杂、带有凹陷或内部结构的形状则力不从心。

• 合并后的新问题:

  • 虽然每个模块化资产本身是简单形状，但将它们合并成一个单一的 Lumen Card 后，这个合并体的整体轮廓可能变得非常复杂（例如，带有内凹庭院或复杂内部结构的“L”形建筑）。
  • 光照计算失效: 对于这种合并后的复杂形状，单一的、简化的 Lumen Card 可能无法准确捕捉其几何细节。这会导致在某些区域（特别是凹陷处或被遮挡的内部）出现 光照计算不准确或产生瑕疵 (Artifacts) 的问题。

• 设计启示: 这或许解释了为什么在 City Sample 中的建筑设计上会遵循某些规律。为了让合并后的 Lumen Card 依然能被有效处理，开发者可能需要在资产创建阶段就有意避免过于复杂的建筑轮廓，以在性能和视觉质量之间取得平衡。

• 实践建议:

  • 分离建模: 将建筑的外部结构和内部空间创建为独立的模型资产。
  • 逻辑控制可见性: 在游戏逻辑层面，根据玩家位置动态切换内外模型的可见性（例如，当玩家在室外时，关闭室内模型的渲染）。

Nanite 对植被（蒙版材质）的挑战

这部分深入探讨了 Nanite 在渲染植被（如树叶、草地）等使用 蒙版材质（Masked Material） 的物体时面临的性能问题。

蒙版材质的性能瓶颈

• 技术背景: 从 UE 5.3 开始，Nanite 原生支持了蒙版材质，这对于渲染大量复杂的植被表面（例如通过 Alpha Masking 抠出的树叶形状）是巨大的进步。

• 核心挑战:

  • 极高的 GPU 负载: 渲染经过 Nanite 处理的蒙版材质，其计算成本非常高昂。
  • 主机性能堪忧: 在游戏主机等性能受限的平台上，想要以高帧率（如 60 FPS）稳定运行这类场景仍然非常困难。
  • 结论: 出于性能考虑，将所有使用蒙版材质的树叶和草都作为 Nanite 对象可能并不可行。

混合 Nanite 方案及其潜在问题

为了解决上述性能问题，一个直观的优化思路是采用混合方案。

• 混合方案提议:

  • Nanite 对象: 将几何结构相对简单、不透明的物体，如 树干、岩石，转换为 Nanite。
  • 非 Nanite 对象: 将使用蒙版材质的树叶等保留为传统的非 Nanite 对象。

• 潜在问题：该方案并非银弹

  • 核心观点: 现代渲染管线，特别是 Lumen (全局光照) 和 VSM (虚拟阴影贴图)，是 为 Nanite 深度优化的。它们处理 Nanite 对象的速度远快于传统对象。
  • 非 Nanite 对象的 GI 处理方式:
    • 讲座以一个 非 Nanite 椅子 为例，解释了 Lumen 如何处理它。
    • 该椅子被表示为 6 张粗糙的代理卡片（Lumen Cards），类似于一个包围盒，用于计算间接光照。
    • 通过 RenderDoc 抓帧分析可以看到，这 6 张卡片是通过传统 硬件光栅化器（Hardware Rasterizer） 逐一绘制的。
  • 关键影响: 这种逐卡片绘制的传统路径，相比于 Lumen 和 VSM 对 Nanite 高度并行的集群化处理方式，效率要低得多。因此，将树叶等关键视觉元素作为非 Nanite 对象， 可能使其在 GI 和阴影计算中成为新的性能瓶颈，从而抵消了混合方案带来的部分优势。

Nanite、Lumen 与 VSM 的性能协同及资产优化策略

1. Nanite 对 Lumen 和 VSM 的加速原理

• 核心观点：Nanite 的软件光栅化器能够将多组件对象合并为单个渲染任务进行处理，从而为 Lumen 和 VSM 这类需要场景深度信息的系统带来巨大的性能提升。

• 传统渲染方式（非 Nanite）:

  • 对于一个由多个独立部分（例如，由六块板子组成的椅子）构成的对象，GPU 的硬件光栅化器需要为每个部分执行一次独立的绘制调用（Draw Call）。
  • 如果这个椅子有 6 个部分，那么在为 Lumen 生成 Lumen Cards 或为 VSM 生成阴影图时，就需要 6 次绘制调用。

• Nanite 的优化方式:

  • Nanite 集成了一个高效的 软件光栅化器 (Software Rasterizer)。
  • 当 Lumen 或 VSM 需要渲染这个 Nanite 化的椅子时，Nanite 的软件光栅化器可以一次性处理所有 6 个部分，将它们合并成一个任务。
  • 这极大地减少了绘制调用的数量，显著降低了 CPU 和 GPU 的开销。

• 关键结论:

  • 这就是为什么官方强烈建议 “即使是低多边形模型，只要你使用了 Lumen 和 VSM，也应该尽可能地将其转换为 Nanite 格式”。
  • 性能优势主要来源于绘制调用批处理和高效的软件光栅化流程，而不仅仅是 Nanite 的多边形剔除和 LOD 功能。

2. Masked 材质（透明蒙版）带来的性能瓶颈

• 核心观点：大量使用 Masked 材质的非 Nanite 物体（如传统植被）会给 Lumen 和 VSM 带来沉重的 GPU 负担，甚至可能导致开发者放弃这些现代渲染特性。

• 问题场景:

  • 游戏场景中通常包含大量的植被，如树木、草地，它们传统上使用带有透明通道贴图的平面（Cards）来模拟复杂的叶片形状，即 Masked 材质。
  • 当场景中存在海量此类物体时，即使它们本身不是非常复杂的模型，其渲染成本也会变得极高。

• 性能影响:

  • 对 Lumen 和 VSM 而言，渲染每一个使用 Masked 材质的“卡片”都涉及到复杂的计算和高昂的 overdraw 成本。
  • GPU 负载会因此急剧飙升，成为项目性能的主要瓶颈。

• 业界现状:

  • 由于优化这些传统植被资产需要大量时间和精力，一些开发者不得不做出妥协， 放弃使用 Lumen 和 VSM，转而退回使用旧的、成本更低的静态光照方案（如 Lightmass GI）。

3. 资产优化策略：从“卡片”到“多边形”

核心观点：解决 Masked 材质性能问题的最佳实践是将叶片等结构从透明贴图平面转变为实际的多边形几何体，并使用不透明材质。

• 解决方案:

  • 放弃使用传统的“卡片 + Alpha Test”方式来制作树叶。
  • 转而使用真实的多边形来精确地勾勒出叶片的轮廓。

• 优势:

  • 材质可以设置为完全 不透明 (Opaque)，这是 GPU 处理起来最快、最高效的材质类型。
  • Opaque 材质对于深度预计算（Depth Pre-Pass）、阴影生成（VSM）和全局光照（Lumen）都极为友好，能最大化利用现代渲染管线的优化。

• 成功案例与当前挑战:

  • Fortnite (堡垒之夜) 中的所有树木都采用了这种 多边形叶片 + 不透明材质 的方案，从而在保证视觉效果的同时，实现了与 Lumen 和 Nanite 的高效协同。
  • 当前挑战: 许多现成的资产库，例如 Quixel Megascans，其提供的植被资产大多仍是基于传统的“卡片”方法制作的，无法直接在启用 Lumen 和 VSM 的项目中“开箱即用”，需要开发者进行手动修改和优化。

总结

引擎提供了包括 Megascans 在内的大量高质量资产，但这些资产并非总是能直接无缝地应用于所有现代渲染特性。在使用前，必须仔细评估资产的构建方式（如材质类型、几何体结构）与你计划使用的渲染功能（如 Lumen、VSM）之间的兼容性。直接使用不兼容的资产不仅可能导致渲染效果不正确，更有可能引发严重的 GPU 性能问题，这是开发者在项目初期就需要重点关注的技术选型和资产规范问题。

总结与实践指南——UE5 特性的现实考量

本部分是整个系列讲座的总结，重点阐述了在实际项目中使用 Unreal Engine 5 高级特性时应持有的核心心态和最佳实践。讲者以日本游戏开发者的反馈为例，强调了理论与实践之间的差距，并给出了如何成功落地这些强大技术的指导原则。

一、 来自开发者的实践反馈 (Practical Feedback from Developers)

讲座总结了日本游戏开发者在使用 UE5 时遇到的普遍性问题和挑战。虽然具体的技术难点在前文已经阐述，但这里的核心观点是，即便是经验丰富的团队，在应用 Lumen、Nanite 等尖端功能时也需要一个学习和适应的过程。

• 核心观点: 从演示到产品落地存在鸿沟。引擎提供的强大功能在实际游戏开发复杂的生产环境中，会暴露出各种预想不到的问题和挑战。

二、 UE5 特性并非“银弹” (UE5 Features Are Not a "Silver Bullet")

这是本次总结最核心的思想。尽管 Epic Games 每年都会发布令人惊艳的技术演示（Demo），证明其功能的强大与可行性，但这并不意味着这些功能可以无脑地应用于任何项目中，解决所有问题。

• 核心观点: 所有强大的技术都有其局限性。无论是 Lumen 的性能开销、Nanite 对特定材质和工作流的支持限制，还是其他高级功能，都并非没有成本的“万能灵药”。开发者必须清醒地认识到这一点。
• 关键术语: 并非万能灵药 (Not a Panacea), 银弹 (Silver Bullet), 权衡与限制 (Trade-offs and Limitations)。

三、 成功的关键：拥抱限制进行设计 (The Key to Success: Designing Within Constraints)

针对上述挑战，讲者给出了最终的、也是最具建设性的建议：成功的关键不在于试图“绕过”或“对抗”这些限制，而在于从一开始就“拥抱”它们。

• 核心观点: 将技术的限制视为美术和设计决策的边界。通过深入理解一项技术的优势与短板，并在内容创作的早期阶段就遵循其规则，才能在保证最终画面效果的同时，实现稳定、可控的性能表现。

• 推荐工作流程:

  1. 深入理解 (Understand)：彻底学习并掌握你所使用的 UE5 功能的当前限制（Current Limitation）。
  2. 遵循约束进行设计 (Design Following the Restriction)：在场景构建、资产制作、光照设计等环节，主动规避该功能的弱点，最大化其优势。
  3. 实现目标 (Achieve)：最终获得 卓越的图形效果 (Excellent Graphics) 与 稳定的帧率 (Stable Frame Rates)。

最终结论：设定清晰且合理的期望

本次讲座的最终目的，是帮助开发者对 UE5 的各项功能建立一个 清晰且符合现实的期望 (Clarify Your Expectation)。UE5 无疑是当今最强大的游戏引擎之一，但它更像是一套专家级的工具集，而非一键式的解决方案。只有真正理解其内在原理和边界，并以此为基础进行创作，才能真正驾驭其力量，打造出次世代的视觉体验。