大场景怎么优化 —— 体素世界、大地图不卡顿的秘诀
精华05/0351 浏览开发心得
你做了一个体素世界，或者一张大地图，在电脑上跑得还行，发到手机上直接卡成幻灯片。
这不是引擎的问题，是你没做「场景优化」。
大场景的核心矛盾很简单：东西太多，屏幕装不下，但引擎还是老老实实把每个东西都算了一遍。
优化的本质就一句话：「看不见的东西别算，看得见的东西少算。」
这篇帖子结合 TapTap 制造里的真实案例（Minecraft 体素世界），教你从零理解大场景优化的每一个核心技巧。
难度：需要有基础的游戏开发经验
————————————————
第一章：先搞懂性能瓶颈在哪里
在优化之前，先搞清楚你的游戏到底卡在哪里。大场景常见的三大瓶颈：
【瓶颈一：Draw Call 太多】
每个 3D 物体渲染一次就是一个 Draw Call。
场景里有 5000 个独立方块节点，就是 5000 个 Draw Call。
手机 GPU 一般扛得住几百个 Draw Call，超过就开始掉帧。
判断方法：场景里节点数量很多，每个节点都有自己的模型组件。
【瓶颈二：顶点/面数太多】
每个面都需要 GPU 计算光照、投影。
一个精细模型 20000 面，放 100 个就是 200 万面。
手机 GPU 处理几十万面就开始吃力了。
判断方法：单个模型很精细，或者高精度模型数量很多。
【瓶颈三：Lua 逻辑太重】
每帧都在做大量计算——遍历所有方块、检测所有碰撞、更新所有粒子。
Lua 本身比 C++ 慢几十倍，逻辑太重帧率直接崩。
判断方法：就算场景里物体不多，帧率也很低。
三种瓶颈的优化策略完全不同，接下来逐个讲。
————————————————
第二章：区块化 —— 大场景的基础架构
这是所有大场景游戏共通的第一招，Minecraft、开放世界、大地图 RPG 全都用这个。
【什么是区块化】
把整个世界切成一块一块的小区域，每块叫一个「区块」（Chunk）。
比如体素世界：
整个世界是 192×80×192 格方块。
切成 16×80×16 的区块，一共 12×12 = 144 个区块。
每个区块独立管理自己的数据、独立生成网格、独立决定是否显示。
【为什么要区块化】
不区块化：每挖一个方块，整个世界的网格都要重建。世界有几十万个方块，重建一次就卡一帧。
区块化之后：挖一个方块，只需要重建那个方块所在的 16×80×16 区块的网格。计算量瞬间缩小几百倍。
提示词：
帮我设计一个区块化的世界管理系统。世界由 16x16 的区块组成，每个区块独立存储方块数据。修改方块时只需要标记对应区块为"脏"，然后在下一帧重建那个区块的网格就行。
【区块大小怎么选】
太小（比如 4×4）：区块数量太多，管理开销大，Draw Call 也多。
太大（比如 64×64）：一个区块改了一格就要重建整个大区块，浪费计算。
推荐值：
体素世界 → 16×16（Minecraft 标准值，久经考验）
2D 瓦片地图 → 16×16 或 32×32
3D 开放世界 → 32×32 到 64×64（取决于物体密度）
【每帧限制重建数量】
即使区块化了，如果玩家一次性挖了 10 个方块，涉及 10 个区块同时标记为脏，一帧内重建 10 个区块还是会卡。
解决办法：每帧最多只重建 1-2 个区块，剩下的排队等下一帧。
这个叫做「帧预算」——给重建任务分配每帧的时间配额。
提示词：
帮我给区块重建加上帧预算控制。每帧最多重建 1 个区块，其他脏区块排队等下一帧处理。
————————————————
第三章：面剔除 —— 不画看不见的面
这一招是体素世界性能优化的最大功臣。
【问题：99% 的面你看不见】
一个 16×80×16 的区块，如果每个方块 6 个面全都画出来，那就是 16×80×16×6 = 122880 个面。
但实际上，你能看到的只有表面那一层！
两个方块紧贴着的面，从任何角度都看不见，画了纯属浪费。
【解决：相邻面剔除】
生成区块网格时，检查每个方块的 6 个方向。如果某个方向紧贴着另一个不透明方块，那个面就不生成。
举个例子：
方块 A 的右边紧贴着方块 B → A 的右面不画，B 的左面也不画。
方块 A 的上面是空气 → A 的上面要画。
经过这个优化，一个区块的面数通常从 12 万降到几千。
提示词：
帮我在生成区块网格时做相邻面剔除。遍历每个方块的 6 个方向，如果相邻方块是不透明的实心方块，就跳过那个面。只有面朝空气或透明方块的面才生成顶点。
【透明方块的特殊处理】
水、玻璃这类半透明方块需要特殊对待：
不透明方块旁边是水 → 不透明方块的那个面要画（因为隔着水能看到）
水方块旁边是水 → 水的那个面不画（同类相邻不画）
一般做法是把透明方块和不透明方块分开处理，用不同的材质和渲染批次。
————————————————
第四章：合批渲染 —— 减少 Draw Call
区块化 + 面剔除解决了面数问题，但 Draw Call 问题还在。
【问题】
如果每个方块是一个独立节点 + 独立模型组件，144 个区块 × 每区块上千个方块 = 十几万个 Draw Call。手机直接崩溃。
【解决：整个区块合成一个网格】
把一个区块里所有可见面合成一个 CustomGeometry 或者一个模型。
整个区块只有 1 个节点、1 个模型组件、1 个 Draw Call。
144 个区块 = 144 个 Draw Call，手机轻松扛住。
【怎么做】
核心是用 CustomGeometry 组件：
1. 创建区块节点
2. 给节点加一个 CustomGeometry 组件
3. 遍历区块里所有方块，把需要显示的面的顶点一个个加进 CustomGeometry
4. 设好位置、法线、UV 坐标
5. 调用 Commit() 提交
这样一个区块不管有多少方块，渲染时都只是一个 Draw Call。
如果区块里有透明方块（水、玻璃），通常分两个 CustomGeometry：一个不透明的、一个透明的。这样是 2 个 Draw Call，依然很少。
提示词：
帮我把区块里所有可见方块面合成一个 CustomGeometry。遍历区块里的方块，做相邻面剔除后，把需要显示的面的顶点加进 CustomGeometry，最后 Commit。不透明面和透明面分开两个 CustomGeometry。
【纹理图集：一张图打天下】
合批渲染还有个前提：同一批次的所有面必须用同一个材质。
如果泥土用泥土贴图、石头用石头贴图、草地用草地贴图……那就变成每种方块一个材质一个批次，合批就白做了。
解决办法：把所有方块贴图拼成一张大图（纹理图集 / Texture Atlas），所有面都用这一个材质，通过 UV 坐标选择不同区域的贴图。
比如 16×16 的图集，每格 1/16 = 0.0625。泥土贴图在第 2 行第 3 列，UV 就是 (2/16, 1/16) 到 (3/16, 2/16)。
提示词：
帮我做一个纹理图集系统。所有方块的贴图拼在一张 16x16 的大图上，每种方块在图集里有对应的 UV 坐标（top/side/bottom 可以不同）。区块网格生成时根据方块类型查 UV 坐标。
————————————————
第五章：视距控制 —— 远处不渲染
前几招解决了近处的问题，但远处呢？玩家站在山顶一眼望去，几百个区块全部渲染，GPU 还是受不了。
【渲染距离限制】
只渲染玩家周围一定范围内的区块。
比如 RENDER_DISTANCE = 6，表示只渲染玩家所在区块为中心、各方向 6 个区块范围内的区块。超出范围的区块不生成、不渲染。
这是 Minecraft 里「可视距离」那个设置的原理。
【雾效遮掩】
渲染距离有个问题：区块到边界时突然消失，看起来很突兀。
加上雾效就解决了：远处的区块被雾挡住，等完全进入雾里再消失，玩家感觉不到突然消失。
提示词：
帮我设置场景雾效。雾从 50 米开始逐渐变浓，到 300 米完全不可见。同时把渲染距离设成只渲染 300 米范围内的区块。
嗒啦啦会在 Zone 组件上设置 fogStart 和 fogEnd，配合区块渲染距离使用。
【DrawDistance 属性】
引擎的 Drawable 组件（StaticModel、CustomGeometry 等）有一个 drawDistance 属性。
设了这个值后，当物体离摄像机超过这个距离，引擎自动不渲染它。
这比自己算距离然后隐藏节点更高效，因为引擎在渲染管线内部直接跳过了，不需要 Lua 层参与。
提示词：
给所有树木装饰物设置 drawDistance = 200，超过 200 米就不渲染。
————————————————
第六章：对象池 —— 避免反复创建销毁
【问题】
体素世界里玩家挖方块，每挖一次都冒出一堆碎片粒子。每个粒子都是一个节点 + 一个模型组件。
如果每次都 CreateChild 创建新节点，用完了 Remove 销毁，频率一高就会触发 Lua 的垃圾回收（GC），导致帧率周期性卡顿。
【解决：对象池】
核心思路：节点用完不销毁，攒起来下次复用。
1. 创建一个池子（就是一个 Lua 数组）
2. 需要节点时，先从池子里拿。池子空了才创建新的
3. 节点用完了（粒子消失了），不销毁，塞回池子
4. 池子设一个上限（比如 50 个），防止无限膨胀
代码思路：
定义一个 pool 表和 maxPoolSize = 50
acquire 函数：
池子里有节点 → 拿最后一个出来，设 enabled = true
池子空 → 创建新节点
release 函数：
池子没满 → 设 enabled = false，塞回池子
池子满了 → 直接销毁
提示词：
帮我做一个节点对象池。粒子效果用完后不销毁节点，放回池子里复用。池子最多存 50 个节点。
【同样的思路用在其他地方】
对象池不止用在粒子上。任何频繁创建销毁的东西都可以用：
子弹 → 射出去飞到尽头不销毁，放回池子
敌人 → 死了不销毁节点，放回池子等刷新
UI 列表项 → 滚动列表用对象池做虚拟列表（引擎内置了 VirtualList 组件）
临时向量 → 每帧计算用到的 Vector3 不要每次 new，复用同一个
————————————————
第七章：Lua 层性能技巧
这些是 Lua 特有的优化手段，不涉及渲染，但对帧率影响很大。
【技巧一：常量本地化】
Lua 访问全局变量和表字段比访问局部变量慢得多。
在热循环（每帧跑几千次的循环）里，把常用的值提取成局部变量。
比如区块网格生成时：
做法：在文件顶部把 Config.World.CHUNK_SIZE、Config.World.BLOCK_SIZE、math.floor、math.max 等赋值给局部变量。
循环里直接用局部变量，不用每次查表。
这个优化看着小，但在每帧遍历几万个方块时，性能差距能有 30% 以上。
【技巧二：避免热路径创建对象】
Vector3(x, y, z) 每调用一次就创建一个新对象，产生 GC 压力。
如果在每帧的循环里写 Vector3(x, y, z)，一帧创建几千个临时 Vector3，GC 压力巨大。
解决办法：用一个预分配的 Vector3，每次修改它的 x/y/z 值，而不是创建新的。
思路：
预先创建一个 tempVec = Vector3()
需要用时：tempVec.x = 1; tempVec.y = 2; tempVec.z = 3
直接传 tempVec 给引擎函数
注意：这个 tempVec 会被下次使用覆盖，所以只适合「用完即走」的场景。如果你需要保存这个值，就老老实实创建新的 Vector3。
【技巧三：用数值键代替字符串键】
Lua 的 table 用数值键查找比字符串键快。
区块坐标 (chunkX, chunkZ) 存储时：
慢的做法：key = chunkX .. "," .. chunkZ（字符串拼接 + 字符串哈希）
快的做法：key = chunkX * 65536 + chunkZ（一次乘法 + 一次加法）
高频访问的数据用数值键，偶尔访问的数据用字符串键无所谓。
【技巧四：高度范围记录】
体素世界里，大部分区块的方块集中在某个高度范围内（比如地面是 30-50 层，上面全是空气）。
如果每次重建区块都从第 0 层遍历到第 80 层，那 0-29 层和 51-80 层全是无效遍历。
解决：记录每个区块方块的最低高度和最高高度（minY 和 maxY），只遍历这个范围。
提示词：
帮我给区块数据加上高度范围记录。每次设置方块时更新 minY 和 maxY，重建网格时只遍历 minY 到 maxY 的范围。
————————————————
第八章：世界大小预设 —— 给玩家选择权
不同设备性能差距巨大。电脑能流畅跑 256×256 的世界，手机可能只能跑 64×64。
好的做法是提供预设，让玩家自己选。
推荐预设：
tiny（微型）：渲染距离 2 个区块，约 64×64，25 个区块。测试用。
small（小型）：渲染距离 4，约 128×128，81 个区块。手机流畅。
medium（中型）：渲染距离 6，约 192×192，169 个区块。推荐默认值。
large（大型）：渲染距离 8，约 256×256，289 个区块。电脑用。
不建议更大了，再大内存会超过 1GB，手机和网页端都很危险。
提示词：
帮我做一个世界大小预设系统。提供 tiny/small/medium/large 四档，控制渲染距离和世界高度。默认用 medium。
————————————————
第九章：常见坑
坑1：区块重建时卡一下
原因：一帧内重建了太多区块。
解决：加帧预算，每帧最多重建 1 个。跟嗒啦啦说「区块重建加上每帧上限控制」。
坑2：远处突然冒出一块东西
原因：没有雾效，区块突然出现在视野里。
解决：加雾效。让区块在进入雾里之前就开始渲染，在完全离开雾区后再消失。
坑3：手机上帧率忽高忽低
原因：Lua GC 周期性触发。通常是因为每帧创建了大量临时对象。
解决：用对象池和临时对象复用。最常见的罪魁祸首是循环里写 Vector3(x,y,z)。
坑4：合批了但还是卡
原因：合批只解决 Draw Call，如果总面数还是很高，GPU 还是扛不住。
检查：每个区块的面数是不是太多？相邻面剔除做了没有？
坑5：透明方块和不透明方块渲染闪烁
原因：透明和不透明物体混在一个 CustomGeometry 里，渲染顺序冲突。
解决：分开两个 CustomGeometry，透明的那个用带 Alpha 的材质。
坑6：世界生成时卡好几秒
原因：一次性生成了整个世界的所有区块。
解决：分帧生成。第一帧生成几个区块，第二帧再生成几个，加个进度条。或者先生成玩家周围的区块，其他的异步慢慢来。
————————————————
优化检查清单
发布前对照这个清单检查：
架构层面：
世界是否做了区块化？
每个区块是否合成了单个或少量 CustomGeometry？
是否使用了纹理图集减少材质数量？
渲染层面：
是否做了相邻面剔除？（体素世界必做）
是否设了渲染距离？
是否加了雾效平滑过渡？
是否给远处的装饰物设了 drawDistance？
Lua 层面：
热循环里的常量是否本地化了？
是否避免了在循环里创建临时 Vector3 等对象？
是否用了对象池避免频繁 Create/Remove 节点？
区块重建是否有每帧上限控制？
区块遍历是否用了高度范围优化？
内存层面：
世界总大小是否在合理范围内？（手机建议不超过 300MB）
对象池是否设了上限防止无限膨胀？
不用的区块数据是否及时释放了？
————————————————
总结
大场景优化的核心就三层：
第一层：少画
区块化 + 面剔除 + 视距控制。看不见的不画。
第二层：合画
CustomGeometry 合批 + 纹理图集。画的时候一批搞定。
第三层：少算
常量本地化 + 对象池 + 高度范围优化 + 帧预算。Lua 层别做无用功。
做到这三层，你的体素世界或大地图在手机上也能流畅运行。
有问题评论区见！