Unity光照探针自动生成工具：基于NavMesh的智能放置方案

1. 项目概述：为什么我们需要自动放置光照探针？

在Unity中捣鼓过光照烘焙的开发者，十有八九都曾被光照探针（Light Probes）的摆放问题折磨过。这东西有多重要？简单来说，它是你场景中动态物体（比如跑来跑去的角色、会动的载具）能融入静态烘焙光照环境的关键。没有它，你的动态物体要么黑成一团，要么亮得刺眼，跟整个场景的光影氛围格格不入。Unity手册会告诉你，你得手动在场景里摆放一个探针组（Light Probe Group），然后像撒豆子一样，在空间的角落、明暗交界处、物体周围去放置一个个探针点。

听起来不难，对吧？但实际做起来，尤其是面对一个复杂的中大型场景，这事儿就变成了纯粹的体力活兼玄学。你得考虑探针的密度：放少了，光照插值不准确，动态物体身上会出现难看的色块断层；放多了，不仅烘焙时间指数级增长，运行时性能开销也吃不消。你还得考虑位置：墙角、桌下、门廊这些光影复杂的地方必须重点照顾，空旷的平地则可以稀疏一些。更头疼的是，当你修改了场景布局，比如移动了一面墙或者增加了一个大型建筑，之前辛辛苦苦摆好的探针可能全部作废，又得重新来一遍。

这个过程毫无创造性可言，纯粹是重复、繁琐且容易出错的劳动。我见过不少团队，为了赶进度，要么随便摆几个探针敷衍了事，导致游戏内光影质量严重滑坡；要么安排美术或TA花上一整天甚至更久，像绣花一样去手动调整，严重拖慢迭代速度。所以，一个能自动、合理放置光照探针的工具，对于提升开发效率和保证最终品质来说，不是“锦上添花”，而是“雪中送炭”。它把开发者从机械劳动中解放出来，让我们能更专注于光照本身的艺术设计和性能调优。

最近在社区里发现了一个挺不错的开源项目，正好解决了这个痛点。它不是一个复杂的、需要深度集成的系统，而是一个轻量级的编辑器工具脚本。核心目标非常明确：根据你设定的规则，自动在场景的导航网格（NavMesh）或特定区域生成光照探针，并且生成的结果在大多数情况下比手动摆放更科学、更均匀。最关键的是，它完全免费、开源，代码清晰，你可以根据自己的项目需求随意魔改。接下来，我就结合自己实际使用的经验，把这个项目的里里外外拆解清楚，告诉你它怎么用，为什么这么设计，以及如何避开那些我踩过的坑。

2. 核心设计思路：自动化背后的逻辑与权衡

这个开源项目的设计哲学很务实：不做大而全的“AI光照解决方案”，而是聚焦于解决“摆放”这个具体问题。它的核心算法思路可以概括为“基于空间分割的均匀采样与适应性剔除”。

2.1 为何选择导航网格（NavMesh）作为生成基础？

这是项目第一个聪明之处。你可能会问，为什么不是基于场景的包围盒（Bounds）或者直接在整个场景体积内均匀生成？原因在于“有效性”和“性能”。

首先，导航网格定义了角色可行走的区域。光照探针最主要就是为动态物体（角色、车辆等）服务的，而这些物体绝大部分时间都活动在导航网格上。在玩家根本去不了的区域（如墙体内部、地图边界外的虚空、不可攀爬的陡坡）生成探针，是纯粹的浪费。以导航网格为基底，确保了每一个生成的探针都“物尽其用”。

其次，导航网格本身已经是一层空间简化。它是一系列凸多边形（通常是三角形）的集合，覆盖了可行走表面。在这个二维（实际上是2.5D，包含高度信息）的表面上生成点，比在三维空间体积内生成，其计算复杂度和需要处理的点数要低得多。这为后续的均匀采样和适应性调整提供了良好的数据基础。

注意：如果你的游戏中有大量飞行单位或可攀爬全场景的物体，仅依赖NavMesh可能不够。这时就需要考虑扩展生成区域，比如结合一个手动定义的体积（Volume）盒子。好在项目代码结构清晰，添加这样的扩展入口并不难。

2.2 均匀采样与“抖动”：打破规律性避免人工感

在导航网格的表面进行采样，最直接的想法就是在每个三角形内部规则地撒点，比如按重心坐标均匀分布。但这样做有个问题：生成的探针阵列会带有明显的三角形网格图案，在光照变化平缓的区域，这种规律性可能会被察觉（虽然概率不高，但追求极致就需要避免）。

因此，项目中通常引入了抖动（Jitter）技术。在采样时，会给每个采样点的位置施加一个随机的微小偏移。这个偏移量被限制在不会使点跑到三角形外面或与其他点过于接近的范围内。这样一来，最终探针的分布在大体均匀的基础上，带有自然的随机性，消除了网格图案的痕迹，看起来更“有机”。这类似于在离线渲染中为抗锯齿进行像素采样的抖动技术，思路是相通的。

2.3 适应性密度与剔除：在需要的地方增加，在冗余的地方减少

均匀采样是基础，但还不够智能。场景中不同区域对光照探针的需求密度是不同的。项目通常会实现某种形式的适应性密度控制。

1. 基于几何复杂度的密度调整：算法可以分析采样点周围一定半径内的场景几何体（碰撞体或渲染器）的密度或法线变化。在墙角、门窗洞口、复杂雕塑附近，几何变化剧烈，光照变化也快，这里就需要更密集的探针来捕捉高频光照信息。算法会自动在这些区域增加采样权重，生成更多的候选点。
2. 探针贡献度分析与剔除：在生成大量候选采样点后，一个关键的优化步骤是剔除冗余探针。如何判断一个探针是否冗余？这里需要一个简化的“贡献度”评估。一个常见的启发式方法是：检查一个探针与其相邻探针的“可见性”和“位置关系”。如果两个探针在空间上非常接近，且它们与主要光源（如方向光）之间没有被不同的物体遮挡（即光照情况相似），那么其中一个提供的信息就很大程度上被另一个覆盖了，可以考虑剔除其中一个。项目可能会通过射线检测（Raycast）来近似评估遮挡关系，或者更简单地，直接基于距离进行聚类，在聚类中心保留一个探针。

通过这套“生成-评估-剔除”的流程，工具能够在光影复杂的区域自动保持高密度，在空旷、光照均匀的区域自动稀疏化，从而在保证质量的前提下，用最少的探针数量达到最佳效果。这比手动凭感觉去摆，要科学和高效得多。

3. 工具实操全流程：从安装到生成

理论说得再多，不如实际跑一遍。下面我就以集成这个开源项目到现有Unity工程为例，展示完整的操作流程。假设项目是一个GitHub仓库，我们可以通过Unity的Package Manager从Git URL安装，或者直接下载源码放入项目的Editor文件夹。

3.1 环境准备与项目导入

首先，确保你的项目环境符合要求。这个工具通常对Unity版本要求比较宽松，支持2019.4 LTS及以上的版本，内置渲染管线（Built-in RP）、通用渲染管线（URP）和高清渲染管线（HDRP）都应该兼容，因为它操作的是Unity底层的LightProbeGroup组件，与渲染管线无关。

方法一：通过Git URL安装（推荐，便于更新）

1. 在Unity编辑器中，打开Window > Package Manager。
2. 点击左上角的“+”号，选择“Add package from git URL...”。
3. 输入该开源项目的Git仓库地址（例如：https://github.com/xxx/xxx.git）。
4. 点击“Add”。Unity会自动下载并导入包。导入后，你通常能在菜单栏找到新的工具菜单，例如Tools > Auto Light Probe Placer。

方法二：手动下载源码

1. 从GitHub仓库的Release页面或直接克隆主分支，下载源码的ZIP包。
2. 在你的Unity项目Assets目录下，创建一个名为Editor的文件夹（如果还没有的话）。
3. 将下载的源码中所有.cs脚本文件解压到Assets/Editor/AutoLightProbe这样的子文件夹中。确保脚本放在Editor文件夹内，这样它们只在编辑模式下运行，不会被打进游戏包体。
4. 重新打开Unity，编辑器会自动编译脚本。同样，在菜单栏应出现对应的工具项。

导入成功后，建议先备份当前场景，或者在一个测试场景中进行首次尝试。

3.2 参数配置详解：每一个选项背后的意义

打开工具窗口（例如Window > Auto Light Probe Placer），你会看到一个参数面板。理解每个参数是用好工具的关键。下面我以一个典型实现为例，逐一解释：

• 生成区域 (Generation Area)：

  • Use Scene Bounds：基于整个场景所有渲染器的包围盒来生成。简单粗暴，但会在很多无效区域（如天空、地下）生成探针。
  • Use NavMesh：推荐选项。仅在烘焙好的导航网格表面生成。这是最常用且高效的模式。
  • Custom Bounds：手动指定一个BoxCollider或RectTransform来定义生成区域。适合局部更新或特定区域的重点生成。

• 探针密度 (Probe Density)：

  • Spacing：探针之间的最小间隔距离（单位：米）。这是控制密度的主要参数。值越小，探针越密集。对于室内或细节丰富的场景，可以尝试0.5m - 2m；对于开阔的户外，3m - 5m甚至更大可能就足够了。
  • Jitter Strength：抖动强度。范围通常在0到1之间。0表示无抖动，采样点完全规则；0.5左右能有效打破规律性且不会导致分布不均。不建议超过0.8，否则可能造成局部过密或过疏。

• 适应性设置 (Adaptive Settings)：

  • Enable Adaptive Density：是否开启基于几何复杂度的自适应密度。打开它。
  • Geometry Check Radius：评估几何复杂度的采样半径。例如设为1米，工具会检查每个采样点周围1米内三角面的数量或法线差异。
  • Density Multiplier Range：密度倍增器范围。例如[1.0, 3.0]。在几何简单的区域，倍增器为1，按基础密度生成；在几何复杂的区域，倍增器可能达到3，意味着在该局部区域，探针的生成密度会提高到原来的3倍。

• 优化与剔除 (Optimization & Culling)：

  • Merge Close Probes：合并过于接近的探针。开启后，工具会在生成后对所有探针进行聚类，把距离小于某个阈值（如Spacing * 0.5）的探针合并为一个（通常取它们的位置平均值）。
  • Cull Redundant Probes：剔除冗余探针。这是高级选项，可能会进行一些轻量的射线检测，判断探针之间的光照信息是否高度相似。开启后会进一步减少探针数量，但计算稍慢。

• 输出控制 (Output)：

  • Create New Group：总是创建一个新的LightProbeGroup游戏对象。
  • Update Selected Group：更新当前在场景中选中的LightProbeGroup。这个功能非常实用，允许你在已有探针组的基础上进行增量调整或重新生成，而不会丢失其他手动精心调整过的特殊探针。
  • Probe Group Name：指定生成的游戏对象名称。

配置时的一个核心心法是：先粗后细，迭代调整。不要指望一次参数就能达到完美。第一次可以用较低的密度（较大Spacing）和默认参数快速生成，查看探针的分布是否覆盖了关键区域。然后逐步调小Spacing，观察探针数量的增长曲线。当探针数量增加一倍，但视觉上对动态物体的光照改善微乎其微时，就说明密度接近饱和了，可以停止。

3.3 执行生成与结果验证

参数设置好后，点击“Generate”或“Bake”按钮。工具会开始工作，你可以在Unity编辑器底部的状态栏看到进度。这个过程包括：采样导航网格、应用抖动、适应性密度调整、剔除合并、最后实例化LightProbeGroup并添加所有探针点。

生成完成后，场景中会出现一个包含成百上千个探针点的LightProbeGroup。这时你需要进行验证：

1. 视觉分布检查：在Scene视图中，将显示模式切换到Shaded Wireframe并开启Light Probes的显示（Gizmos > Light Probes）。观察探针点是否均匀覆盖了玩家可活动区域，在墙角、楼梯、家具周围是否更密集，在空旷大厅或平原是否较稀疏。
2. 性能数据检查：在Window > Analysis > Rendering Debugger（或Frame Debugger）中，查看渲染统计信息。关注Light Probes Used的数量。这个数字应该小于或等于你场景中动态渲染器的数量，并且是一个合理的值（例如，对于中小型场景，几百到一千多个是正常的）。
3. 动态物体测试：这是最重要的验证步骤。在场景中放入一个简单的动态物体（如一个Sphere或Cube），为其添加一个标准材质球。拖动这个物体在场景中四处移动，观察其表面的光照（尤其是颜色和亮度）是否平滑地随着位置变化而过渡，有没有出现突兀的跳变或明显的色块。特别要在探针密度变化的区域（如从走廊进入房间）进行测试。

如果测试结果不理想，比如在门口有光照突变，你可以回到工具窗口，尝试以下调整：

• 局部密度不足：适当减小Spacing，或增大Density Multiplier Range的上限。
• 探针位置不佳：可以尝试微调Jitter Strength，或者更直接地，在工具生成的基础上进行手动微调。这正是“自动为主，手动为辅”的工作流。你可以直接在该LightProbeGroup上添加或移动少数几个探针，来解决自动算法未能完美处理的个别死角。

4. 高级技巧与深度集成方案

掌握了基本使用，我们可以看看如何把这个工具用得更好，甚至集成到项目管线中。

4.1 与光照烘焙流程的结合

光照探针的放置应该成为你光照烘焙管线中的一个标准环节，并且有固定的顺序。一个合理的工作流如下：

1. 场景几何定型：首先确定场景的布局、建筑、主要静态物体。大的改动会导致导航网格和光照UV需要重新计算。
2. 烘焙导航网格：使用Unity的Navigation窗口，为场景烘焙导航网格。这是自动放置探针的基础。
3. 运行自动探针放置工具：使用当前讨论的工具，基于上一步的NavMesh生成初始的光照探针组。采用一个中等偏保守的密度设置。
4. 手动微调探针：美术或技术美术（TA）检查自动生成的探针，在少数光影特别复杂的区域（例如，枝形吊灯下方、彩色玻璃窗旁）手动补充或调整几个探针。这个阶段耗时应该很短。
5. 烘焙静态光照：进行完整的GI（全局光照）烘焙，这包括光照贴图（Lightmaps）和光照探针数据的计算。此时，探针的位置已经固定，Unity会计算每个探针点捕获到的间接光照、反射光等信息。
6. 验证与迭代：放入动态物体测试。如果发现动态物体光照有问题，回到第3或第4步调整探针，然后重新烘焙光照（通常只需要重新烘焙光照探针，而不必重新烘焙昂贵的光照贴图）。

将这个流程脚本化，可以创建一个编辑器脚本，依次调用NavMeshBuilder.BuildNavMeshAsync和自动探针生成工具的函数，实现一键“准备光照烘焙数据”。

4.2 针对特殊场景的定制策略

• 超大开放世界：对于无缝大世界，不能一次性生成所有探针。需要按区块（Chunk）来处理。你可以写一个脚本，遍历每个场景区块，激活该区块及其相邻区块的静态物体和导航网格，然后针对这个局部区域运行探针生成工具，生成只属于该区块的LightProbeGroup。最后在运行时，根据玩家位置动态加载和卸载相应的探针组数据。这需要与你的场景管理系统深度配合。
• 室内与室外混合场景：室内往往需要更高的探针密度来捕捉封闭空间内的多次反弹光。一个策略是使用两个生成区域：先用一个较大的Spacing为整个室外区域生成基础探针；然后，用一个自定义的BoxCollider框选室内区域，使用更小的Spacing再次生成，并选择Update Selected Group模式，将室内密集探针合并到同一个组里。工具需要能支持这种分区域、不同参数的多次生成。
• 移动平台性能考量：移动设备上，过多光照探针的插值计算是负担。除了尽量优化探针数量，还可以利用Unity的Light Probe Proxy Volume (LPPV)。对于非常大的动态物体（如公交车、大型怪物），使用LPPV比依赖单个探针插值效果更好。自动生成工具可以扩展，在识别到带有特定标签（如“UseLPPV”）的大型动态物体时，在其包围盒上自动生成一个LPPV组件，并配置好相应的分辨率。

4.3 源码浅析与扩展点

由于是开源项目，我们可以通过阅读其核心源码来理解其工作原理，并针对自身项目进行定制。核心代码通常位于一个名为LightProbeAutoPlacer.cs的Editor脚本中。

关键函数和扩展点可能包括：

• GenerateProbes()：主入口函数。它协调了整个流程：获取生成区域、采样、抖动、自适应调整、剔除、最终创建LightProbeGroup。
• SamplePointsOnNavMesh()：负责从NavMesh上采样的核心算法。这里可能使用了NavMeshTriangulation来获取网格数据，然后在每个三角形上进行泊松圆盘采样（Poisson Disk Sampling）或均匀网格采样。如果你想改变采样算法（例如换成更高效的蓝噪声采样），就在这里修改。
• CalculateAdaptiveDensity()：计算每个采样点的密度权重。这里通常通过Physics.OverlapSphere或Vector3.Distance来评估周围几何复杂度。如果你想引入更复杂的评估标准，比如根据附近光源的强度或类型来调整密度，就在这里添加逻辑。
• CullRedundantProbes()：剔除冗余点。这里可能实现了简单的距离聚类（K-Means或层次聚类）。如果你想实现更智能的、基于光照相似性的剔除（需要预计算光照信息），这里将是改造的重点，但计算量会大增。

扩展示例：假设我们想增加一个“根据灯光距离调整密度”的功能。我们可以在CalculateAdaptiveDensity函数中，新增一个循环，遍历场景中的所有Light组件，计算每个采样点到灯光的距离。对于距离关键灯光（如主光源、点光源）较近的采样点，给予一个更高的密度权重。这样就能在灯光周围自动生成更密集的探针，更好地捕捉光影衰减。

5. 常见问题、排查与性能调优

在实际使用中，你肯定会遇到各种问题。下面是我总结的一些典型情况及其解决方法。

5.1 生成过程卡死或无响应

• 问题描述：点击生成按钮后，Unity编辑器卡住，进度条不动，甚至崩溃。
• 排查与解决：
  1. 场景规模过大：这是最常见原因。如果你的导航网格覆盖了整个开放世界，一次性采样会导致计算量爆炸。解决方案：分块处理。使用Custom Bounds，每次只生成一个街区或一个房间的探针。
  2. 参数设置过于激进：Spacing设置得太小（如0.1米），同时Adaptive Density又开得很高，会导致候选采样点数量巨大（数十万甚至百万级），后续的剔除计算无法承受。解决方案：先从较大的Spacing（如3米）开始，逐步调小。关闭自适应功能，先看看基础分布。
  3. 导航网格未烘焙或异常：工具在尝试获取NavMesh.CalculateTriangulation()时失败或得到异常数据。解决方案：确保当前场景已正确烘焙导航网格。在Window > AI > Navigation中查看并重新烘焙。
  4. 内存不足：在生成过程中，如果存储了大量临时数据（如所有采样点列表、邻接关系矩阵），可能导致内存峰值过高。解决方案：检查工具代码，看是否有内存泄漏或可以流式处理/分帧处理的地方。对于大型场景，考虑将生成过程改为协程（Coroutine），分帧执行，并在编辑器状态栏显示进度。

5.2 生成的探针分布不理想

• 问题描述：探针在某些区域过于稀疏（如复杂的楼梯间），在某些区域又过于密集（如空旷的平地）。
• 排查与解决：
  1. 自适应密度失效：检查Geometry Check Radius是否设置合理。半径太小，无法感知到周围的墙角；半径太大，可能会把远处的几何也算进来，造成误判。通常设置为略大于Spacing的1.5-2倍进行尝试。
  2. 导航网格分辨率过低：如果导航网格本身烘焙得很粗糙，三角形面片很大，那么在其上采样得到的点自然就稀疏。解决方案：提高导航网格的烘焙精度（在Navigation窗口的Bake面板中，减小Cell Size和Cell Height），但这会增加导航网格的数据量，需要权衡。
  3. 抖动强度过高：过高的Jitter Strength可能导致采样点在某些地方意外地聚集或分散。尝试将其降低到0.3以下。
  4. 手动干预：没有任何自动工具是完美的。对于算法难以处理的特殊区域，接受手动补充几个探针是最快最有效的解决方案。使用工具的Update Selected Group模式，在自动生成的基础上进行手动微调。

5.3 动态物体光照出现接缝或闪烁

• 问题描述：动态物体在移动时，表面光照颜色或亮度发生不连续的跳变，或者在两个探针之间来回闪烁。
• 排查与解决：
  1. 探针密度不足：这是最根本的原因。光照信息的插值需要在足够密集的采样点上进行。在出现问题的区域，手动增加几个探针，或者整体减小Spacing参数重新生成。
  2. Anchor Override设置问题：对于由多个子网格（Mesh）组成的复杂动态物体（如一个人形角色），如果每个子网格渲染器（SkinnedMeshRenderer）的Anchor Override指向不同的变换（Transform），而这两个变换在空间上距离较远，就会导致不同身体部位从不同的探针组插值光照，从而产生接缝。解决方案：确保复杂动态物体所有渲染器的Anchor Override都设置为同一个变换节点（通常是角色的根骨或主变换）。
  3. 光照探针代理体积（LPPV）使用不当：对于非常大的动态物体，如果还在使用普通的探针插值，由于物体跨越了多个探针包围盒，不同部位的光照计算可能不协调。考虑为该物体启用Light Probe Proxy Volume，并在其包围盒内设置更精细的3D探针网格。

5.4 性能开销分析

过多的光照探针会增加运行时性能开销，主要体现在两个方面：

1. 内存开销：每个探针存储了9个浮点数（3个球谐系数，每个系数是RGB三个浮点数）的照明信息。1000个探针大约占用1000 * 9 * 4 bytes ≈ 35 KB。这部分通常不是瓶颈。
2. CPU开销：动态物体在每个渲染帧，需要为其每个渲染器查找最近的光照探针（通常是4个或8个）并进行插值计算。这是主要的开销所在。探针数量越多，查找和计算的开销就越大。

调优建议：

• 设定预算：根据目标平台和场景复杂度，为动态物体数量设定一个探针数量预算。例如，移动端场景，争取将探针总数控制在500个以下；PC端大型场景，可以放宽到2000-3000个。
• 使用遮挡剔除（Occlusion Culling）：合理设置场景的遮挡剔除，可以避免不可见的动态物体进行探针插值计算。
• 分层次细节（LOD）：对于远处的动态物体，使用低模LOD的同时，也可以考虑降低其光照计算的精度，例如使用更少的探针进行插值（虽然Unity本身不直接支持，但可以通过Shader变体或自定义渲染逻辑近似实现）。

这个开源工具的价值，就在于它通过算法帮你逼近这个“性能与质量”平衡点，让你无需从零开始手动摆放，就能得到一个在大多数情况下都相当可用的基线配置。剩下的，就是针对项目特殊需求的微调和优化了。