云边笔记

先给结论#

Renderer 收到 FScene 和一组 View 后，不能把所有 Primitive 都直接变成 Draw Call。UE5 会在不同粒度连续回答“这部分是否值得画”：

1. Primitive 粒度：包围体是否在视锥内、距离是否合适、是否被隐藏、是否通过遮挡测试、是否与当前 View / Pass 相关。
2. Instance 粒度：同一 Primitive 内的大量实例中，哪些实例对当前 View 与 Pass 可见。
3. Cluster 粒度：对 Nanite 几何继续选择必要 Cluster，并在 GPU 上做更细的视锥、遮挡和尺度判断。
4. Pixel / Sample 粒度：Early Z、Depth Test、Stencil 等继续拒绝不可见片元。

传统网格通过 FMeshBatch → FMeshPassProcessor → FMeshDrawCommand 进入各个 Mesh Pass；Nanite 则拥有 GPU 驱动的 Cluster 可见性和光栅路径，不会把每个 Cluster 都变成一条传统 Mesh Draw Command。

可见性是一组筛网#

这张图只表达过滤层次。真实实现会把工作任务化、批量化或移到 GPU，不同测试也可能交换或合并。优化时应问“对象在哪一级被淘汰”，而不是笼统地说“它被 Culling 了”。

InitViews 是阶段名，不只是一个循环#

在 Desktop Renderer 中，InitViews 常被用作一组 View 初始化与可见性工作的总称。它可能涵盖或触发：

• View 参数、View State 与历史状态准备；
• Scene / GPU Scene 更新与上传；
• Primitive Frustum、Distance、Occlusion 等可见性计算；
• FPrimitiveViewRelevance 计算；
• Static Mesh 可见命令筛选；
• Dynamic Mesh Element 收集；
• Instance Culling 与各 Mesh Pass 的 Setup 工作；
• 为后续 Base Pass、Depth、Shadow、Velocity 等建立可消费的数据。

UE5 的新版本持续把这部分拆成并行任务。因此在 Insights 中看到 InitViews 时间下降，不一定代表某项工作消失，也可能是它移动到异步 Task 或 GPU Pass。判断时同时检查：

• Render Thread 主事件；
• Worker Thread 上的 Visibility / Mesh Draw Command 任务；
• GPU 上的 Instance / Nanite Culling Dispatch；
• 主 Pass 是否因准备未完成而出现 Wait。

1
FSceneRenderer::InitViews
2
  → PreVisibilityFrameSetup...
3
  → ComputeViewVisibility...
4
      → Primitive Visibility / Relevance
5
      → Occlusion
6
      → Gather Dynamic Mesh Elements
7
  → PostVisibilityFrameSetup...
8
  → Mesh Pass Setup / Instance Culling

第一层：Primitive Bounds 与 View Relevance#

1
这个 Primitive 对当前 View 可见吗？
2
如果可见，它与哪些 Mesh Pass 相关？
3
它的 Mesh Element 从 Static Cache 还是 Dynamic Gather 获得？

第二层：Occlusion 与 HZB#

视锥内的对象仍可能被墙体挡住。UE 会按平台和路径使用 Hardware Occlusion Query、Hierarchical Z Buffer（HZB）或 GPU 驱动方案。

第三层：GPU Scene 与 Instance Culling#

一个 Primitive 可能代表成千上万个实例。如果只做 Primitive Bounds 测试，那么森林的一角可见时，整片森林都可能进入后续工作。

GPU Scene 把 Shader 需要的 Primitive / Instance 数据组织到 GPU 可访问的场景缓冲中。Instance Culling 可以针对当前 View 与 Pass：

• 读取 Instance Transform、Bounds 和 Flags；
• 做 Frustum、Distance、Occlusion 等测试；
• 压紧可见 Instance ID；
• 生成或修正 Indirect Draw 参数；
• 让相同几何命令只消费真正可见的实例。

常见源码搜索点：

• FGPUScene
• FInstanceCullingManager
• FInstanceCullingContext
• FInstanceCullingDrawParams
• InstanceCulling 目录或 Shader

不同 Vertex Factory、Pass 与平台对 GPU Scene 的支持不完全相同，不能看到 ISM/HISM 就默认所有剔除都发生在 GPU。

第四层：Nanite Cluster Culling#

Nanite 对受支持几何使用 Cluster 层级。粗粒度 Primitive / Instance 判断之后，Nanite 继续在 GPU 上选择满足当前 View 的 Cluster：

• View Frustum 与 Clip Plane；
• Bounds / Cone 等 Cluster 测试；
• 屏幕误差与细节层级选择；
• HZB Occlusion；
• Streaming 中哪些 Page 已驻留；
• Main View、Shadow View 与 VSM Page 对应的可见性需求。

关键区别：

1
传统路径：CPU / GPU 准备有限数量的 Mesh Draw Command
2
Nanite：GPU 遍历层级并产生 Cluster 工作，再通过 Nanite Raster / Material 路径输出表面

所以“Nanite 场景的 Draw Call 很少”不代表没有几何成本。需要同时看 Cluster 数、Instances、Raster Bin、Streaming、Overdraw 和材质阶段。

从 Proxy 到 FMeshBatch#

传统网格把一次可绘制描述组织成 FMeshBatch。它通常包含：

• Vertex Factory：顶点数据如何提供给 Shader；
• Material Render Proxy / Material Resource：使用哪个材质与 Shader Permutation；
• FMeshBatchElement：Index Buffer、First Index、Primitive 数、Instance 等元素数据；
• Raster / Culling / Wireframe 等状态提示；
• 与当前 Pass 相关的标志。

FMeshBatch 不是 Draw Call 的同义词：

• 一个 Batch 可包含多个 Element；
• 同一个 Batch 可被多个 Mesh Pass 处理；
• 某些 Batch 会被拒绝或拆分；
• 多条兼容命令可能在提交时实例化合并；
• Nanite Cluster 不走逐 Cluster FMeshBatch 路径。

Mesh Pass Processor：同一 Mesh 怎样进入不同 Pass#

Depth、Base Pass、Shadow Depth、Velocity、Custom Depth 等需要不同 Shader 和状态。每种 Mesh Pass 通过对应 FMeshPassProcessor 处理 FMeshBatch：

1
FMeshBatch
2
  → Pass 的 FMeshPassProcessor::AddMeshBatch
3
      → 检查 Material / Vertex Factory / Pass 条件
4
      → 选择 Shader Permutation
5
      → 组合 Pipeline State
6
      → 建立 Shader Bindings
7
      → BuildMeshDrawCommands
8
          → FMeshDrawCommand

FMeshDrawCommand 是接近 RHI 提交的、可排序和缓存的绘制描述，通常记录：

• Shader 与 Pipeline State；
• Vertex Streams；
• Shader Resource Bindings；
• Index / Primitive / Instance 参数；
• Stencil 等 Pass 状态；
• 用于排序、合并和提交的信息。

它仍不是 D3D12 / Vulkan Command Buffer 本身；RHI 提交阶段才把它落实为平台调用。

Cached Command、Dynamic Command 与排序合并#

并行准备与提交#

Mesh Draw Command 的优势之一，是把高层场景遍历与低层提交解耦，让多个 Task 并行完成：

1. 过滤当前 Pass 的可见 Primitive / Mesh；
2. 建立或复用 Draw Command；
3. 生成 Sort Key 并排序；
4. 执行 Dynamic Instancing 与 Instance Culling Setup；
5. 生成 Visible Mesh Draw Command 列表；
6. 向 RHI Command List 提交。

常见入口包括 FParallelMeshDrawCommandPass、DispatchPassSetup、BuildRenderingCommands、SubmitMeshDrawCommands 等。新版可能把 Setup 与 Instance Culling 进一步任务化；以 Insights 的 Task 依赖和本分支调用栈为准。

源码断点路线#

断点时同时记录 View、EMeshPass::Type、Primitive ID、Material、Vertex Factory 和 Draw Command 数。只记录函数命中，无法解释为什么 Draw Call 增减。

六个可证伪实验#

性能观测表#

可用于实验的命令和变量包括 FreezeRendering、r.VisualizeOccludedPrimitives、r.HZBOcclusion、r.AllowOcclusionQueries、r.MeshDrawCommands.DynamicInstancing 与 Dynamic Instancing 统计命令。它们可能只在 Editor / Development 生效或随版本改名，使用前必须在 UE 5.8 当前分支的 Console Variables Reference / DumpConsoleCommands 中确认。

常见误区#

本篇建立的心智模型#

1
FScene + View
2
  → Primitive Visibility / Relevance
3
      → Static Mesh Batch Cache
4
      → Dynamic Mesh Element Gather
5
          → 每个 Mesh Pass 的 Processor
6
              → Cached / Dynamic FMeshDrawCommand
7
                  → Sort / Dynamic Instancing
8
                  → GPU Scene Instance Culling
9
                  → RHI Submit
10

11
Nanite Primitive / Instance
12
  → Nanite GPU Cluster Culling
13
      → Nanite Raster / Material Path

下一篇进入 RDG：上面准备好的 Draw / Dispatch 为什么以 AddPass 形式组织，资源依赖怎样产生 Barrier，Transient Resource 为什么能别名复用，Async Compute 又何时只是看起来异步。

官方资料#

• Visibility and Occlusion Culling
• Visibility and Occlusion Culling Reference
• Mesh Drawing Pipeline
• Nanite Virtualized Geometry
• Console Variables Reference
• EpicGames/UnrealEngine（需要 Epic 与 GitHub 账号授权）