GPU Instancing 植被

先把题目说成人话

山坡上有成千棵同品种树。若中央处理器为每棵树重复发送同一套网格、材质和渲染状态，提交本身就会成为负担；可树的位置、颜色和风摆又不能完全一样。现实要解决的是让许多树共用一套模具，只给每棵附上小标签，同时把看不见的整片树林留在仓库，不送去绘制。

用一条命令绘制许多同类副本叫图形处理器实例化（GPU Instancing），每个副本的位置、颜色和风相位等标签叫实例数据（Instance Data）。决定哪些副本能同组的共享条件叫批次键（Batch Key），共享一叠纹理并按标签选层叫二维纹理数组（Texture2DArray），让绘制数量等参数来自缓冲区叫间接绘制（Indirect Draw）。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

山坡上有许多同品种树。它们的树干网格和叶片材质相同，只是位置、旋转、缩放、叶色和风摆时间不同。理想状态像同一套模具配许多小标签：模具提交一次，GPU 按 Instance ID 读取每棵树的标签。

（右脑）画面：山坡工厂只保留少数几套树干与叶片模具，成百上千棵树不再各造一副模具，而是在小标签上写自己的位置、大小、颜色、风摆阶段和纹理层。装箱前先按模具、材料、绘制步骤和状态把树分组，只有不会改变整条生产线的差异才允许写进标签；镜头外、被山挡住或远到只需剪影的整箱树，则在仓库阶段就不送上绘制台。这样既能减少重复下单，也能减少无用货物，但两件事必须分别核算：共用模具不会自动让看得见的树少画顶点或少涂像素。

（左脑）对表：Instancing 只减少重复提交，不会自动减少可见实例的顶点或像素。核验对象是每条绘制命令的共享状态键、实例数量、实例缓冲字段、bounds、LOD、可见列表和 CPU/GPU 时间。勾选 Enable GPU Instancing 是配置事实，“整片森林因此只有一个 Draw”是假设；不同 Pass、阴影、LOD、容量或状态仍会拆命令，证据必须来自对应 Unity 版本的 Frame Debugger 或 GPU capture。Transform 单位服从世界空间，颜色/随机数通常无量纲，bounds 必须覆盖真实空间范围；材质属性是否声明为 instanced、SRP Batcher 是否接管也要按版本抓帧。模具类比不等于批次已成立。

小明：先形成一个完整猜测

小明为每棵树复制一份 Material，再修改颜色和风速。画面差异完整，却把共享状态变成了许多独立材质；不同关键字、纹理和 Render State 还会继续拆分批次。

他又打开 Enable GPU Instancing，认为“一片森林从此就是一个 Draw”。这个结论仍过头：不同 Mesh、Submesh、Pass、阴影、LOD、材质状态和每批容量都会产生更多命令。

小红：把猜测放回现实检查

小红把差异分成两类。

真正共享的部分保留在 Material：Shader、Variant、纹理数组、Blend/Z/Cull 状态和统一质量档。每棵树不同的部分放进实例缓冲：object-to-world、颜色乘子、风相位、随机种子和纹理层索引。

她逐项恢复差异。颜色与风相位声明为 instanced property 后仍能合批；树种纹理改为 Texture2DArray，以实例索引选择层；一旦某棵树启用不同 Shader Keyword、绑定独立纹理或改变 Pass，批次就按真实状态重新拆开。类比只帮助理解，最终以 Frame Debugger 的批次原因和抓帧命令为证据。

我：用检查结果修正模型

我按规模选择 Unity 路径，并把“提交”与“剔除”分开：

• MeshRenderer + Enable GPU Instancing：Unity 收集兼容 Renderer，适合保留 GameObject 工作流；在本页锚定的 Unity 2022.3 URP/HDRP 传统 MeshRenderer 路径中，SRP Batcher 兼容的 Renderer 会优先走 SRP Batcher，不会因为勾选开关就必然成为 GPU Instancing。两者降低的是不同 CPU 成本，必须用 Frame Debugger/Profiler 确认实际路径；Unity 6 的 GPU Resident Drawer 等新路径要另按对应版本判断。
• Graphics.RenderMeshInstanced：CPU 每帧提供实例数组。Unity 以整组 bounds 做剔除和排序，不会自动逐实例剔除；单次容量受实例结构和平台常量缓冲限制。
• Graphics.RenderMeshIndirect：绘制参数来自 GraphicsBuffer，可由 CPU 或 GPU 生成。Unity仍以 RenderParams.worldBounds 把该命令视作一个整体；若要逐实例 GPU 剔除，必须另写 Compute 筛选、压紧可见索引并更新 indirect args。
• BatchRendererGroup 或定制渲染系统：适合需要自定义批次、Job 化剔除和大规模数据管理的项目，但工程复杂度更高。

最后把树林按空间 Tile 管理；近处选择合适 LOD，中远处换低模与 impostor，完全不可见的 Tile 不提交。Instancing 让“提交许多树”变便宜，LOD/Culling/Impostor 才让“真正处理的顶点和像素”变少。不同树种或质量档若需要不同 Mesh/Material，就接受有意义的批次边界，不为了一个 Draw 造万能 Shader。

（右脑）画面修正：小明为每棵树复制材质，颜色和风摆都有了，模具却被拆成许多份；勾上实例化开关后，他又把整片森林误认成一次 Draw。小红把颜色、风相位、随机数和纹理数组层逐项放回实例标签，并用抓帧看到不同 Mesh、Pass、Keyword、纹理、LOD、容量和阴影状态仍会合理拆组。于是只让不改变渲染状态的差异进入实例数据，共享状态不同就另开模具；森林规模交给 Tile、可见列表、LOD 与 impostor，不能靠继续膨胀万能 Shader 来解决。

（左脑）严格对表：数据组织先以 (Mesh, Submesh, Material, Variant, Pass, RenderState, LOD) 分组；每组的实例缓冲只保存 object-to-world、颜色、风相位、随机种子和 Texture2DArray 层等已声明实例字段；随后按 Tile/视锥/遮挡生成可见索引，更新对应直接或 indirect 命令与合法 bounds。验收用 Frame Debugger/GPU capture 核对实际实例命令和拆分原因，用 Profiler 比较 Render Thread、顶点和片元成本，并验证材质差异、风摆、LOD 与剔除仍正确；Draw 减少但可见实例未降，不能宣称几何成本也已优化。

老师解惑

• 共享条件：同 Mesh/Submesh、Material、Shader Variant、Pass 与 Render State 才有机会进入同一实例批。
• 实例数据：Transform、颜色、风相位、随机数和 Texture2DArray 索引可随实例变化，但 Shader 必须以实例属性或结构化缓冲读取。
• MaterialPropertyBlock：在支持的 Renderer 路径中可传实例属性；属性必须声明为 instanced 才能保持对应实例批。在 Unity 2022.3 的 SRP Batcher 路径中，给 Renderer 使用 MaterialPropertyBlock 会使它失去 SRP Batcher 兼容性，因此要明确选择 SRP Batcher、GPU Instancing，或改用共享结构化 Buffer，并在目标管线抓帧验证。
• Indirect 不等于自动剔除：Indirect 只说明命令参数来自 Buffer；谁生成可见列表、怎样做 LOD 和 occlusion 仍需实现。
• 一批不等于全场一次提交：容量、阴影 Pass、LOD、材质与平台都会继续拆命令，必须用 Frame Debugger 或 GPU Capture 核对。

工具分工

• Unity Frame Debugger：检查哪些 Renderer 合批、因什么状态拆批。
• Unity Profiler（CPU/GPU Usage）：区分 Render Thread 提交、顶点和片元瓶颈。
• RenderDoc / 平台 GPU Capture：确认实例命令、实例数量、Pass 和缓冲内容。
• Storm 类场景管理方案：可作为 Tile、Culling、LOD、Impostor、Streaming 与 Indirect 协同的产品案例；其宣传数据不能代替本项目实测。

记忆钩子

Mesh 与状态共用，差异写进实例；Instancing 省提交，Culling、LOD 和 Impostor 才省真正画出去的东西。