一个几乎所有 Unity 项目都会遇到的选型问题

LOD（Level of Detail）是 3D 项目性能优化的第一道防线，但「用什么方式做 LOD」却是一个让无数独立游戏开发者在立项初期反复纠结的问题。Static LOD（美术手做多套网格 + 引擎按距离切换）与 Dynamic LOD（运行时几何简化算法动态生成）是两条根本不同的技术路线，它们的成本结构、视觉表现、适配场景都截然不同。选错路线轻则增加 30% 的无效工作量，重则在项目后期撞上技术债硬墙。

本文不站「必须 Static」或「必须 Dynamic」的任何一边——这两种范式都有其适用边界。我们要做的是：把两种范式的底层机制、成本结构、视觉特征差异讲清楚，并给出一套基于项目体量、团队规模、目标平台的选型决策框架。Xmohe 相信，最好的技术选型不是追新，而是「匹配项目约束的最优解」。

先厘清本质：两种 LOD 范式的底层机制差异

Static LOD：美术主导的预制切换范式

Static LOD 的核心逻辑是「离线阶段做足工作，运行时只做最廉价的距离判断」。具体流程：美术使用 DCC 工具（Blender、Maya、3ds Max）针对同一物体手工制作 N 套不同细节的网格（LOD0 高模、LOD1 中模、LOD2 低模、LOD3 Billboard），烘焙到 Unity 工程后由 LOD Group 组件按相机距离自动切换。运行时的代价几乎为零——引擎只判断距离并切换 Renderer 引用。

优势：视觉可控性极高（每一级 LOD 都是美术可控的「作品」）、运行时无 CPU 成本、跨平台行为一致、调试简单。劣势：美术成本极高（一件复杂装备的 4 级 LOD 可能需要 3–7 天）、内存占用高（多套网格同时驻留）、后期修改成本高（任何源模型改动都需要同步更新所有 LOD 级别）。

Dynamic LOD：算法主导的运行时生成范式

Dynamic LOD 的核心逻辑是「只在运行时计算所需细节」。具体流程：引擎在运行时根据相机距离、屏幕占比、设备性能动态调用网格简化算法（如 quadric error metrics 边折叠算法），按需生成或切换不同细节级别的网格。运行时承担部分计算代价。

优势：美术成本几乎为零（只需要源模型）、后期修改成本低（改一处源模型即可）、内存占用低（不预存多套网格）。劣势：运行时 CPU 开销显著（简化算法可能消耗每帧 0.5–3ms）、视觉不可控（算法生成的简化结果可能丢失关键轮廓）、不同算法质量差异巨大、需要严格测试。

关键洞察：两种范式不是「先进 vs 落后」的关系，而是「成本在不同阶段分配」的权衡——Static 把成本集中在美术阶段（前置），Dynamic 把成本集中在运行时（后置）。对资源极度受限的独立游戏而言，这个权衡的本质是「你能负担前置的人力成本，还是后置的运行时成本」。

选型决策矩阵：四种项目类型的最优解

抛开「哪个更好」的伪命题，针对四类典型项目，给出务实的选型建议。

类型一：3–10 人小团队 / 风格化 3D 项目（卡通、低多边形、像素感）

推荐：Static LOD 主导 + Dynamic 局部补充。理由：风格化 3D 项目的 LOD 级别通常只需要 2–3 级（高模 + 低模 + Billboard），美术成本可控；风格化轮廓对算法简化非常敏感（Dynamic LOD 容易破坏「方正」「锐利」的视觉特征）；独立游戏品质感依赖美术手感而非算法精度。

类型二：10–50 人中型团队 / 写实风开放世界项目

推荐：Static LOD 核心资产 + Dynamic LOD 大批量物体。理由：核心资产（主角、剧情 BOSS、标志性建筑）的视觉品质不可妥协，必须 Static；开放世界的大量植被、岩石、装饰物数量可达数万至数十万件，美术不可能全部手做，Dynamic 是唯一可行路径；两者混合是工业界标准做法（《巫师 3》《刺客信条》《原神》皆如此）。

类型三：1–2 人极小团队 / Roguelike 或小型解谜项目

推荐：几乎纯 Static + Unity 内置 Auto-LOD。理由：极小团队的美术产能极度稀缺，需要把精力集中在 1–2 件标志性资产上；Unity 2020+ 的 LOD Group 内置了简易的自动简化工具，能为「不重要的资产」提供「够用」的简化方案；Dynamic LOD 的运行时成本在小项目里反而占比过高。

类型四：移动端主导 / 设备碎片化严重

推荐：Static LOD 主体 + 运行时动态 LOD Bias 调节。理由：移动端需要严格控制 CPU 与内存预算，Static 的运行时低成本不可替代；但移动端设备性能差异巨大（旗舰机 vs 入门机相差 5 倍以上），需要在 Static LOD 的基础上叠加运行时 lodBias 动态调整，让高端机用更高 LOD、低端机用更低 LOD。

一个被忽视的智慧：大多数 3A 项目用的是「混合策略」

许多独立开发者以为只有「二选一」，但事实上几乎所有商业化成功的 3A 项目都采用混合策略：核心资产用 Static 保证视觉品质（演员、主角、关键建筑），大批量场景资产用 Dynamic 或 Continuous LOD 处理（植被、岩石、家具、装饰物）。这种「分而治之」的策略，本质上是用 Static 的高视觉品质满足「记忆点」，用 Dynamic 的低美术成本满足「世界感」，是工业界经过 20 年沉淀的最佳实践。

对独立游戏团队而言，最务实的做法是：先做 Static 的核心资产（一般不超过 50 件），其余大量场景资产用 Dynamic 或 Unity 内置 Auto-LOD 应付。这种 70/30 的成本分配，能在有限预算下最大化整体视觉品质感。

编辑观点：选型错误的代价远高于选型本身的代价

（以下为 Xmohe 内容团队的明确立场，与上文事实陈述分开标注。）我们观察到大量独立游戏项目在 LOD 选型上犯的最大错误，不是「选错了范式」，而是「选型后没有持续评估」。许多项目在立项时仓促决定「我们全用 Static」或「我们全用 Dynamic」，但项目进行到中后期才发现：核心资产用 Dynamic 出现了视觉品质问题，或大批量资产用 Static 让美术不堪重负。LOD 选型不应是一次性决策，而应是每 3 个月一次的「适配性评审」——评估当前范式是否仍然匹配项目状态，并及时调整。Xmohe 建议：每个独立游戏团队在 LOD 范式选择上保持「持续反思」的习惯，比一次选对更重要。

初级用户路径：3 步决策流程

如果你是刚开始一个 Unity 3D 项目的独立开发者，按这三步走，能在 30 分钟内做出务实的 LOD 选型。

第一步：盘点你的项目体量。先回答三个问题——核心 3D 资产不超过 50 件还是超过 200 件？场景中同屏显示的资产数少于 1000 件还是多于 5000 件？目标平台是 PC/主机还是移动端？前者多则偏 Static，后者多则偏 Dynamic。

第二步：盘点你的美术产能。1–3 人小团队几乎只能用 Static（少量核心资产）+ Auto-LOD（其余）这种保守组合；5 人以上团队可以考虑 Static + Dynamic 混合策略；外包美术充足时 Static 比例可以拉高到 60–70%。

第三步：在前两步结论上做小规模验证。不要一次性为整个项目下决定。先挑 3 类典型资产（一个角色、一件道具、一组植被），分别用两种范式做小样，对比视觉品质、美术耗时、运行时 CPU 占用，再用真实数据做最终决策。

中级用户路径：四维参数化选型框架

对有明确项目方向的策划与主程，以下四个可调维度构成「LOD 范式选型调音台」，帮你为每个资产类型精确定位最优范式。

维度一：视觉重要性（低 ↔ 高）

资产在玩家视野中的关键程度。主角、剧情相关资产为「高」；场景装饰物、远景填充物为「低」。高视觉重要性资产几乎必须 Static；低视觉重要性资产可以 Dynamic。

维度二：数量规模（少 ↔ 多）

场景中同类资产的数量。少于 20 件用 Static 几乎无压力；多于 200 件必须 Dynamic 或混合。门槛经验值：单类资产超过 50 件时，Static 的边际成本开始显著上升。

维度三：修改频率（低 ↔ 高）

资产在开发过程中的迭代频率。修改频率高的资产（关卡迭代、调试中的道具）更适合 Dynamic（改一处源模型即可）；修改频率低、长期稳定的资产（核心主角）适合 Static（一次性投入永久受益）。

维度四：性能要求（宽松 ↔ 严格）

项目对运行时性能的苛刻程度。移动端、VR、网页端等性能预算严格的平台，应当优先 Static（运行时零成本）；PC 高端单机、主机项目则可以更灵活使用 Dynamic。

组合心法：「视觉重要性 × 数量规模」是最关键的二维组合——高重要性 × 少数量必 Static，低重要性 × 大数量必 Dynamic，中间的灰色地带才是真正需要决策的区域。把决策资源集中投在灰色地带资产（占总数约 20–30%），能让 80% 的资产快速获得合理范式。

常见问题

结语：选型是持续反思的过程，不是一次性的决定

Static LOD 与 Dynamic LOD 不是「先进 vs 落后」的范式之争，而是「成本在不同阶段分配」的工程权衡。对独立游戏团队而言，最重要的不是「选哪个」，而是「能不能定期评估当前选型是否仍然匹配项目状态」。Xmohe 建议每个独立游戏团队都建立「LOD 适配性季度评审」机制——每 3 个月评估一次当前 LOD 策略的有效性，及时调整，让 LOD 真正成为支撑项目长期品质的工程基础设施，而非项目后期才发现的隐藏技术债。