箱庭关卡的烘焙：sublevel 怎么切，同时决定了光照和可见性

年后的关卡依旧卡顿掉帧。

会上主动请缨，配合新关卡的负责策划，直接介入客户端程序这一侧。

想要的产出不是一个关卡。是一套流程 —— 让策划自己就能验证场景搭得对不对，而不是每次都等程序去 profile。

先扒一个成品

关卡的结构其实一开始就想清楚了：

1. 直接扒出一个 Apex 的局部关卡结构；
2. 以此为基础构建资源和箱庭修改。

拿一个公认做得好的成品当尺子，比从零讨论”关卡应该多大、房间应该多密”快得多。这一步省下来的不是工时，是反复推翻的次数。

开工前列的六个问题

在动手之前，我把要摸清楚的东西列成了六条：

1. 如何 bake 出正确的、高效的、动静结合的光照环境；
2. 如何处理美术 mesh，以得到合理的 drawcall 及裁剪；
3. 如何处理关卡的各种 nav、precomputed visibility；
4. 对于小型箱庭关卡，如何梳理 persistent level 和 sublevel 的关系；
5. 对于小型箱庭嵌入大型关卡，如何梳理其关系以及使用方式；
6. 大型关卡使用纯 dynamic level 时，如何与箱庭关卡的 level instance 混合。

列清单本身没什么了不起。有价值的是列完之后发现，其中两条其实是同一条。

第 3 条和第 4 条是同一个决定

用老关卡熟悉多 sublevel 的 bake 和 lightmass 细节时，我把一件之前一直含糊的事弄明白了：

precomputed visibility 和 lightmass 不是两件独立的事。

PVS 的数据是跟着 lighting build 一起产出的，它的 cell 由 Precomputed Visibility Volume 决定；而这些 volume、以及和光照相关的分区，都挂在 persistent level 的组织方式上。

所以你在决定 sublevel 怎么切的时候，同时就决定了三件事：光照能不能按区域重建、可见性剔除的粒度有多细、以及美术改一处要重烘多大范围。

这个顺序反过来做会非常痛苦。先按美术方便切 sublevel，等到烘焙和 PVS 出问题再回头调，多半要返工。

定下来的实施顺序

跟策划和外包美术确定的步骤是这几步：

1. 整体光照 bake 方案
2. 细节打光
3. drawcall 缩减，可以用 draw instance
4. 新材质的引入
5. 真机性能调优
6. 配合调整动态交互物件的性能

顺序不能乱。整体 bake 方案定不下来，细节打光就是白做 —— 方案一改，前面调的光全部作废。drawcall 没降下来之前，真机调优拿到的数据也不可信，你分不清瓶颈是在提交还是在填充。

这篇写在什么时候

写在流程刚跑通、新关卡刚开始做的时候。所以有几件事必须说清楚：

• 整体 bake 方案是照着老关卡验证出来的，新关卡上的真机数据一个都还没有；
• 第 5、6 条 —— 箱庭嵌入大型关卡、level instance 和纯 dynamic level 混合 —— 目前只有方案，没有实做；
• 上面关于”卡顿掉帧”的因果，我只做到了”先把可控的部分做对”，还没有做过前后对照。

真机数据出来之前，这套流程只能算是一个合理的假设。