简而言之： 巨大比例的玩家在朴素硬件上——笔记本、Steam Deck 之类的掌机、更老的 GPU——而一个只在高端机器上跑的环境把他们 排除在外。好消息：大多数环境性能丢在几个可预测的地方（过绘制、绘制调用、密集植被、过大贴图），并用几个自律的习惯夺回。这是一份 不掏空你美术就命中低帧预算的实用手册，外加用固定相机在回退发货前抓住它们的方法。
这是最贵的一类场景来跑——层层透明叶片、成千上万实例、沉重过绘制。一旦你知道帧时间去了哪，它也是最大、最容易的胜利所住之处。
## 先定一个预算，以毫秒计
在你最弱的受支持硬件上挑一个目标帧时间——60 fps 用 16.6 ms，30 用 33.3 ms——并把它当作硬限。"以后优化"意味着"以 后重建"；预先做预算便宜得多。
没有数字的优化只是凭感觉。在你的地板硬件上——Steam Deck、一台中端笔记本、无论你的最低配是什么——决定你瞄准的帧，并把它换成毫 秒，因为毫秒会累加而百分比会撒谎。然后在你构建时把每个场景都守在那，而非在末尾。那些在低端上流畅发货的团队并不优化得更狠；他们只 是从一开始就绝不让一个场景撑爆预算，这只是美术做完、一切都依赖它之后再把性能抠回来的成本的一小部分。
## 知道时间去了哪
环境帧时间通常被过绘制（透明植被）、太多绘制调用（未批处理对象）、过大贴图（内存带宽）以及昂贵的光照/阴影所吃掉。在盲目 优化前，做剖析以找出你的瓶颈。
猜测优化浪费数天。打开一个剖析器，找出你是 CPU 受限（通常是绘制调用）还是 GPU 受限（通常是过绘制、着色或带宽），并攻击真正的瓶 颈。话虽如此，环境以可预测的方式失败，而几乎总是其中之一：来自层层透明植被的过绘制；来自成千上万未实例化对象的绘制调用；来 自过大或过多贴图的贴图内存/带宽；以及来自太多动态光或高分辨率阴影图的光照/阴影开销。本手册其余部分按其惯常影响的次序逐一 处理它们。
## 植被与过绘制：惯常的反派
透明植被卡片相互重叠并把同一批像素重新着色许多次——那就是过绘制，也是低端头号杀手。减少叶片卡片重叠，使用激进的 LOD，并 狠狠剔除远处植被。
密集植物是大多数低端帧预算死亡之处，因为每张半透明叶片卡片都逼迫 GPU 去着色它随后会在其上重画的像素——在厚密树冠里有时每像素十次以 上。修复：使用更紧凑、浪费透明区域更少的叶片卡片，随植被退远快速跌到更便宜的 LOD，并设硬剔除距离，好让远处的草与灌丛干脆停止绘制。 在掌机上，"草到地平线"与"草在合理距离剔除"之间的差别，可能就是 25 与 40 fps 之间的全部差别。把植被烘焙成原生实例，好让 GPU 能批处 理它，并让引擎的实例化去干重活。
## 绘制调用与实例化
每个单独提交的独特对象都是一次绘制调用，成千上万个会让 CPU 停顿。把重复网格实例化，好让数百份拷贝只花一次调用；在有意义 之处合并静态杂物。
若你 CPU 受限，绘制调用通常就是原因。你请引擎渲染的每个不同的东西都携带开销，而一个用一千块个体岩石与灌丛手放的场景，会把 CPU 淹在 提交成本里。实例化是解药：作为实例绘制的重复网格把数百份拷贝坍缩成单次调用，这正是那些烘焙成原生引擎实例的散布工具对性能要紧的 原因——看着像一千株植物的散布，花费却像一小把。在实例化不适用之处，把小的静态杂物合并成组合网格也削减调用数。这是一个像 [Numivo] (/features) 那样的工作流——绘制密度，然后烘焙成朴素的实例化网格——在弱硬件上直接见效之处，因为输出正是 GPU 想要的那件便宜东西。
并非每个场景都得最大限度地密集。安静、开阔的空间几乎不花什么，也给硬件与玩家双方一份歇息——为你的密度做节奏本身就是一种优化。
## LOD、剔除距离与贴图尺寸
给每个重要网格 LOD，好让远处拷贝便宜；设剔除距离，好让屏幕上极小的对象停止绘制；并把贴图分辨率封顶到相机在距离上能分辨的 程度。这三样以小力气夺回很多。
三个不起眼的习惯扛起剩余预算的大头。LOD：远处网格应切换到更低模版本，因为在一棵 20 像素的树上放全细节是浪费。剔除距离：任何 在屏幕上小到注意不到的东西都应完全停止渲染——小道具、卵石、细草——按对象类型调。贴图尺寸：把分辨率封顶到在玩家距离上实际可分辨的 程度（见纹素密度逻辑——远处的东西需要少得多的纹素），因为过大贴图会烧掉低端 GPU 挤不出的内存带宽。调对了这些都不伤观感；它们只是让你 停止为没人看得见的细节付钱。
## 用固定相机找出回退
定义几台"预算相机"——你最差的远景、最密的战斗空间、最忙的室内——并在每个 build 检查它们的帧时间。随机飞掠会藏起回退；每次 同样残酷的视角会把它们暴露出来。
随着内容加入，性能悄悄腐烂，而你随意在关卡里溜达是抓不到它的。相反，钉死你那一小把最差的视角——密林眺望点、拥挤的市集、特效沉重的 战斗——并对着预算，在每个 build 精确测量那些。当一个数字变红，你就知道是最近一次改动造成的，以及大致在哪。这就是一个在末尾才发现性能 危机的团队，与一个在 2 ms 回退出现当天就修好的团队之间的差别。在低端目标上，让其中一台相机跑在真实的 Steam Deck 或最低配机器上，而 不只是编辑器估算。
## 值得偷的现场数字
- 帧预算：16.6 ms（60 fps） / 33.3 ms（30 fps）——在你的地板硬件上设定
- 惯常的低端杀手：植被过绘制——更紧凑的卡片、快速 LOD、狠剔除
- 重复网格 → 实例：数百份拷贝一次绘制调用
- 把贴图尺寸封顶到相机可分辨的细节——远处需要少得多的纹素
- 用固定预算相机抓回退，每个 build 测量
## 迷你问答
我得在好看与低端之间选吗？ 比你以为的少。大多数低端开销是浪费——过绘制、未批处理的调用、过大贴图——而非可见质量。砍掉浪费，美术 就活下来；弱硬件上的玩家很少想念你曾付钱、他们却看不见的那份细节。
动态光照在 Steam Deck 上是禁区吗？ 不是禁区，而是有预算。限制动态光与投影者的数量，在场景静止之处倚靠烘焙光照，把动态开销留给要 紧之处。这是一条预算线，不是一道禁令。
在掌机上单个改动帮助最大的是什么？ 通常是驯服植被：更紧凑的叶片卡片、激进的 LOD，以及草与灌丛上的硬剔除距离。过绘制是最常见的掌 机瓶颈，而植被正是过绘制所住之处。
我该多早在目标硬件上测试？ 从第一个纵切片起。强力开发机上的编辑器估算，恰恰藏起掌机将有的那些问题。早早在真实的最低配设备上弄到一 个 build 并把它留在循环里。
在土豆上跑，不是把你的游戏弄丑——而是不为玩家看不见的细节付钱。以毫秒做预算，杀掉过绘制，把重复实例化，剔除不可见，并在每个 build 盯 住你最差的相机——你的环境就会既好看又为那庞大的、不在高端机器上的观众跑起来。
