传统 LOD 体系的 CPU 瓶颈与 GPU 闲置

理解 Unity 6 新特性的价值，需要先理解传统 LOD 体系的根本性瓶颈：CPU 与 GPU 之间的负载不均衡。

在传统渲染流程中，CPU 端每帧需要完成以下工作：

• 遍历场景中所有对象，确定哪些需要渲染。
• 对每个对象进行视锥体剔除和 LOD 选择。
• 准备渲染数据（变换矩阵、材质参数、Shader Uniform）。
• 调用图形 API 发起 Draw Call。

对于一个包含 5 万个对象的中等规模场景，CPU 端每帧的遍历与决策可能需要 5-15 毫秒（具体数值取决于对象类型、剔除算法、CPU 性能）。相比之下，GPU 端的实际渲染时间可能只有 8-12 毫秒。CPU 与 GPU 的负载严重不均衡——CPU 端满载时 GPU 端有大量闲置。

这种不均衡的根本原因是传统的"CPU 主导"架构：CPU 决定渲染什么、何时渲染、用什么状态渲染，GPU 只是被动执行命令。这种架构在过去 30 年是合理的，因为早期 GPU 远弱于 CPU，需要 CPU 端做大量准备。但 2015 年以后，GPU 性能增长远超 CPU（特别是并行计算能力），CPU 主导的架构越来越成为瓶颈。

GPU 驱动渲染（GPU Driven Rendering）的核心思想是：让 GPU 自主决定渲染什么、何时渲染，CPU 端只负责最顶层的指令（"场景中有 5 万个对象，下面 100 米的范围内，请 GPU 自主决定渲染哪些"），把具体的剔除、LOD 选择、Draw Call 调度全部下放到 GPU 端。

这一架构转变对 LOD 体系的具体影响是：传统的"LOD Group 组件 + 阈值切换"模型开始被部分取代——GPU 端可以在更细粒度上做 LOD 决策（如基于 GPU 计算的精确屏幕占比），而不必依赖 CPU 端预先配置的阈值。

GPU Resident Drawer：迈向 GPU 驱动的第一步

Unity 6 引入的 GPU Resident Drawer 是这一范式迁移的第一步。它的设计目标是：让大量同质对象（数千到数万个）的渲染调度从 CPU 迁移到 GPU。

GPU Resident Drawer 的工作机制：

• 一次性上传：所有同质对象的几何数据（Mesh、Material）一次性上传到 GPU 显存，CPU 端不再需要为每个对象准备数据。
• GPU 端剔除与 LOD 选择：CPU 端只设置一个"世界空间范围"参数，GPU 端自主完成视锥体剔除和 LOD 选择。
• 动态 Draw Call 合并：GPU 端根据实际渲染的对象数量动态合并 Draw Call，CPU 端不参与具体合并决策。

对 LOD 体系的具体影响：

• CPU 不再为每个对象做 LOD 选择，LOD 决策在 GPU 端完成，节省 CPU 端 30-50% 的渲染准备时间。
• 可以基于 GPU 计算的精确屏幕占比做 LOD，比 CPU 端基于距离的估算更准确。
• 支持更大规模对象：传统 LOD Group 在数万对象时 CPU 端开销明显，GPU Resident Drawer 可以处理数十万对象而不显著增加 CPU 开销。

限制与适用场景：

• 仅支持同质对象：所有对象必须使用同一 Mesh、同一 Material，与 GPU Instancing 的限制类似。
• 不支持动态生成的几何体：对象的几何数据必须在编译时确定，不支持运行时动态生成。
• Shader 兼容性：需要 Shader 兼容 SRP Batcher 与 Instancing。

对独立游戏项目的实际价值：中小型项目（数千对象）暂时不需要 GPU Resident Drawer，传统的 LOD Group + SRP Batcher 组合已经足够。只有当项目规模达到"数万到数十万同质对象"的程度（如开放世界的大规模植被、城市模拟游戏的海量建筑），GPU Resident Drawer 才开始显示不可替代的价值。

BatchRendererGroup 架构深度解析

BatchRendererGroup (BRG) 是 Unity 6 引入的更底层的渲染控制 API。它的目标不是直接服务于普通项目，而是为愿意投入的高级开发者提供"细粒度控制 GPU 渲染"的能力。

BRG 的核心架构组件：

组件一：InstanceDataBuffer

BRG 引入了一个新的缓冲区结构 InstanceDataBuffer，开发者可以定义每个实例的"自定义数据结构"。例如：

• 基础数据：变换矩阵（4x4 矩阵，64 字节）。
• 自定义属性：颜色、动画时间、自定义 LOD 参数等。

这些数据一次性上传到 GPU，渲染时由 GPU 端直接读取。CPU 端不再为每个对象准备 Constant Buffer。

组件二：BatchID 与 Batch 调度

BRG 引入 BatchID 概念：每个 Batch 是"共享相同 Mesh + Material + 配置"的一组实例。开发者通过 BatchID 引用 Batch，Unity 内部维护 Batch 的 GPU 资源生命周期。

关键设计：

• 动态 Batch 切换：开发者可以在运行时动态改变一个对象属于哪个 Batch（例如基于 LOD 切换、基于可见性变化）。
• 细粒度控制：开发者可以选择"哪些对象应该被渲染"、"用什么 LOD"、"用什么 Batch"。

组件三：OnPerformCulling 回调

BRG 允许开发者实现 OnPerformCulling 回调，自定义剔除与 LOD 决策逻辑：

• 基于自定义相机参数：例如对第一人称玩家与第三人称相机使用不同的 LOD 策略。
• 基于游戏状态：例如战斗场景使用更激进的 LOD 策略，平时保留更多高 LOD。
• 基于 AI 预测：例如根据 AI 角色即将前往的方向预加载该方向的 LOD 资源。

对 LOD 体系的影响

BRG 的出现让"LOD 策略"从 Unity 内置的固定模式（按距离阈值）转变为开发者可完全自定义的灵活系统。这对一些特殊场景有重要价值：

• 赛车游戏：基于速度的动态 LOD（高速时切换更激进）。
• 模拟经营游戏：基于玩家关注度的 LOD（玩家注视区域保留高 LOD）。
• VR 游戏：基于视野中心权重的 LOD（视野中心保留高 LOD，边缘激进切换）。

学习曲线与门槛：

• BRG API 复杂度高，需要深入理解 GPU 渲染管线。
• 官方文档相对简洁，主要参考 Unity 官方 Sample。
• 调试工具较少，问题排查比传统 LOD Group 困难。
• 对小型项目可能"杀鸡用牛刀"。

GPU 端 Occlusion Culling 替代 CPU LOD 决策

Unity 6 引入的另一项重要特性是 GPU 端 Occlusion Culling（遮挡剔除）。它与传统 CPU 端 Occlusion Culling（基于 Umbra）形成对比。

传统 CPU 端 Occlusion Culling 的工作机制：

• 离线阶段：Unity 用 Umbra 工具预计算场景的 PVS（Potentially Visible Set，可能可见集合）。
• 运行时：CPU 端查询 PVS，根据玩家位置快速确定哪些对象"肯定不可见"，跳过这些对象的渲染准备。
• 局限：PVS 是预计算的，无法处理动态对象（移动的敌人、可破坏物体）。

GPU 端 Occlusion Culling 的工作机制：

• Hi-Z Buffer 方式：GPU 端先用低分辨率渲染场景的"深度金字塔"（Hierarchical Z-Buffer）。
• 查询阶段：对每个待渲染对象，GPU 查询其包围盒在 Hi-Z Buffer 中的可见性。
• 完全 GPU 端：CPU 端不参与剔除决策，整个流程在 GPU 端并行完成。

对 LOD 体系的影响：

• 动态对象支持：可以处理移动的敌人、可破坏物体等动态对象的剔除。
• 精度更高：Hi-Z 剔除是"像素级"的判断，比 CPU 端基于包围盒的判断更精确。
• 与 LOD 的关系：GPU 端 Occlusion Culling 可以在"对象被遮挡"时直接跳过渲染，无需触发 LOD 切换。这意味着"看不见的对象"根本不进入 LOD 决策流程。

实际效果：在大规模场景中（数千个对象、复杂遮挡关系），GPU 端 Occlusion Culling + LOD 组合可以减少 50-80% 的无效渲染。

DOTS/ECS 体系下的 LOD Component 设计哲学

Unity 的 DOTS（Data-Oriented Tech Stack，Data-Oriented Technology Stack）体系代表了 Unity 的长期技术愿景。在 DOTS 体系下，所有游戏对象都被表示为 ECS（Entity Component System）架构：Entity 是 ID，Component 是数据，System 是逻辑。

在 ECS 体系下，LOD 表达方式发生了根本变化：

• LOD 不再是组件，而是 Component 数据。每个 Entity 可以挂载 LODComponent，其中包含 LOD0、LOD1、LOD2 的 Mesh 引用、阈值参数、当前激活层级等数据。
• LOD 决策是 System 逻辑。LODSystem 每帧遍历所有 Entity，根据 Entity 的位置、相机位置、阈值参数等计算当前 LOD 层级，更新 LODComponent 的 CurrentLOD 字段。
• 渲染通过 Entities Graphics 包完成。Entities Graphics 包深度集成 ECS 与 BRG，可以将数十万 Entity 高效渲染。

这种设计的优势：

• 数据导向：所有 LOD 数据连续存储，缓存友好，遍历性能极高。
• 灵活决策：LODSystem 可以实现任意复杂度的 LOD 策略，开发者可以编写自定义 System。
• 极致规模：ECS + BRG + Entities Graphics 可以处理数十万到数百万个 Entity 的渲染。

现实挑战：

• 学习曲线陡峭：ECS 思维与传统 GameObject 思维差异大，开发者需要重新建立心智模型。
• 生态不成熟：Entities Graphics 仍在演进，许多第三方工具尚未适配 ECS。
• 工具链支持有限：Editor 中对 ECS 的支持仍不如传统 GameObject 完善。

对独立游戏开发者的实际建议：现阶段（2025 年）不建议中小型项目转向 ECS，除非项目规模（数十万 Entity）或团队能力（已有 ECS 经验）有明确需求。可以作为"未来 3-5 年的技术储备"提前学习。

Mesh Shader 与虚拟几何体路线

展望未来 3-5 年，Unity 的虚拟几何体技术路线图值得关注。Unity 官方在 2024-2025 年公开承认"虚拟几何体是未来方向"，但具体实现路径仍在探索中。

技术路线的核心方向：

• Mesh Shader 支持：Mesh Shader 是 DirectX 12 Ultimate 与 Vulkan 1.3 引入的新 Shader 阶段，可以替代传统的顶点/几何着色器流水线，让 GPU 端更灵活地处理几何生成。Unity 6 已经开始支持 Mesh Shader 的部分功能。
• Cluster Rendering 架构：参考 Nanite 的思路，将网格预切分为 Cluster 集合，GPU 端根据每个 Cluster 的屏幕空间大小决定渲染哪些 Cluster。这是 Unity 内部正在研发的方向。
• Visibility Buffer 渲染路径：用"可见性 + 材质 ID"的两阶段渲染替代传统的 G-Buffer 渲染，简化材质评估流程。

时间表预估：

• 2025-2026 年：Mesh Shader 支持完善，BRG 性能持续优化。
• 2026-2027 年：Unity 虚拟几何体的实验性 Preview 可能在 Unity 6.x 后续版本或 Unity 7 中出现。
• 2027-2028 年：虚拟几何体进入生产可用阶段，但仅在高端 PC/主机平台，移动端支持仍需 1-2 年。

对独立游戏开发者的实际建议：不要在 2025 年的项目中赌虚拟几何体，但要为 2027 年后的项目做技术储备。理解 Mesh Shader、Cluster Rendering 的基础概念，跟踪 Unity 官方路线图更新。

渐进式迁移策略：传统 LOD 与新路径并存

面对"传统 LOD Group + 新 GPU 驱动路径"的并存局面，独立游戏项目应该采用渐进式迁移策略：

1. 现在（2025 年）：继续使用 LOD Group + SRP Batcher + Instancing，覆盖 95% 场景。新项目用 Unity 6 起步，享受 SRP Batcher 红利。GPU Resident Drawer 在大规模同质对象场景中启用。
2. 2026-2027 年：尝试 BRG 处理特殊 LOD 需求（赛车速度感知、VR 视野权重等）。跟踪 Unity 官方虚拟几何体 Preview 进展。
3. 2027-2028 年：新项目可以基于 BRG + 虚拟几何体构建核心系统，老项目逐步迁移高负担模块。

关键判断：技术迁移的时机取决于项目周期与平台目标。

• PC 平台为主的项目：可以更早拥抱新路径，新硬件支持是红利。
• 移动端为主的项目：传统 LOD Group 仍是长期主力，新路径在移动端支持有限。
• 跨平台项目：建立"传统 LOD + 平台特性"的双层架构，传统 LOD 覆盖所有平台，新路径作为高端平台优化。

未来 3-5 年技术演进路线图预判

基于 Unity 官方公开信息、Epic Nanite 实现、DirectX 12 Ultimate 与 Vulkan 1.3 硬件支持现状，对未来 3-5 年的 LOD 技术演进做以下预判：

2025-2026 年：优化期

• GPU Resident Drawer 性能持续优化，覆盖更大规模场景。
• BRG API 完善，文档与 Sample 增多。
• Mesh Shader 在 Unity 中的支持完善。

2026-2027 年：实验期

• Unity 虚拟几何体 Preview 版发布，可能作为 Unity 6.x 后续版本或 Unity 7 的一部分。
• Cluster Rendering 架构在 Unity HDRP 中实验性集成。
• ECS + BRG + Entities Graphics 体系进入生产可用阶段。

2027-2028 年：落地期

• 虚拟几何体功能在 Unity 中生产可用，覆盖 PC 与高端主机。
• 移动端虚拟几何体支持开始出现，但需新一代移动 GPU（如 Adreno 8 系列、Apple A19）才能流畅运行。
• 传统 LOD Group 仍然存在，作为低成本项目、跨平台项目、移动端项目的标准方案。

2028 年后：长期共存期

• 两套范式（传统离散 LOD + GPU 驱动虚拟几何体）长期共存。
• Unity 引擎选型从"选哪个管线"扩展为"选哪套渲染范式"。
• 独立游戏开发者需要根据项目类型、目标平台、团队能力做技术选型。

初级用户路径：先观察再投入

如果你是刚开始学习 Unity 的新手，建议：

1. 扎实掌握传统 LOD Group 组件（专题 03）。
2. 理解 SRP Batcher 与 Instancing 的差异（专题 06）。
3. 关注 Unity 6 的新特性，但不要在早期项目中贸然使用 GPU Resident Drawer 等新路径。
4. 等社区出现成熟案例后再尝试。跟踪 Unity 官方博客、Unity China 社区的实践分享。

新技术的学习曲线与风险都比较高，新手应该先把基础打牢。

中级用户路径：建立技术储备计划

对于已有 Unity 经验的中级开发者，建议建立系统的技术储备计划：

1. 半年内：在现有项目中尝试 GPU Resident Drawer，评估性能改善幅度。
2. 一年内：学习 BRG API，用 Demo 项目验证 BRG 在自定义 LOD 策略上的可行性。
3. 两年内：关注 Unity 官方虚拟几何体进展，参与 Preview 计划（如有）。
4. 持续关注：跟踪 Unity 官方路线图更新、Unreal Engine 5.x 的虚拟几何体演进、DirectX 12 Ultimate 的硬件普及速度。

技术储备的关键是"学在用前"——在生产项目需要新技术的 1-2 年前就开始学习，避免"临时抱佛脚"的高风险。

争议焦点：Unity 的虚拟几何体是否会迟到

社区中持续讨论的一个争议是：Unity 的虚拟几何体功能是否会比 Epic Nanite 迟到太多？

支持"Unity 会迟到"派的观点：

• Epic Nanite 自 2020 年首次公开，至今已迭代 4 年，Unity 在 2024 年才承认"虚拟几何体是未来方向"。
• Unity 2023 年的收费调整风波导致人员流失，技术推进速度可能受影响。
• Unity 的架构债务（Built-in / URP / HDRP 三套管线）使新功能的集成比 Unreal 困难。

支持"Unity 不会太迟到"派的观点：

• Unity 选择了"渐进式"路径而非"激进式"路径，避开了 Nanite 早期的问题（如仅支持静态几何体、内存占用高）。
• Unity 在 ECS、BRG、Entities Graphics 上的持续投入为虚拟几何体提供了架构基础。
• Unity 6 GPU Resident Drawer 是迈向虚拟几何体的关键步骤，技术债务问题正在被解决。

Xmohe 判断：Unity 的虚拟几何体功能确实会比 Nanite 迟到 2-3 年，但不会"完全错过这场技术革命"。对独立游戏开发者，合理的预期是：2027-2028 年可以开始基于 Unity 虚拟几何体构建新项目，届时技术成熟度类似 Nanite 在 2022-2023 年的水平。短期项目（2025-2026 年发布）应该继续基于传统 LOD Group 规划，不应等待虚拟几何体。

Xmohe 编辑观点：技术演进的"迟到"是相对的——3-5 年的时间跨度在游戏开发领域是常见的。从这个角度，Unity 虚拟几何体的"迟到"对长周期项目（5-10 年生命周期）影响有限，对短周期项目（2-3 年发布）影响也不大——因为后者本就不应该押注尚未成熟的技术。真正受影响的是"中周期项目"（3-5 年生命周期）——这类项目需要决定"是否等待虚拟几何体"。Xmohe 建议：除非项目对 Nanite 级别能力有强烈需求，否则不应等待。