场景搭建这件事做得越久越会发现一个扎心的规律好看的画面人人都想要但性能优化的账如果不从一开始就算最后往往要么砍美术、要么砍帧率两边都不讨好。我自己是从“先搭漂亮再调性能”这条路走过来的后来做移动端项目被真机帧率狠狠教过几次才慢慢总结出这套“好看与性能兼顾”的搭建思路。这篇指南不是高级 TA 才能看懂的底层论文而是给搞场景搭建的实干人看的从一帧的消耗到底花在哪到灯光烘焙怎么选、植被和贴图怎么控、移动端和 PC 端怎么分开调优再到最后怎么把性能检查变成日常工作的一部分。适合场景美术、关卡设计师、TA 和独立开发者参考尤其是那些被“明明看起来不复杂但跑起来就是卡”折磨过的团队。1. 一帧画面的预算账本先搞懂性能到底花在哪1.1 16.6 毫秒里CPU 和 GPU 都在忙什么大多数项目里卡顿不是“某个东西太卡”而是多个消耗项叠加起来超出了预算。先说三个最基础的单位60 帧每秒意味着每帧只有 16.6 毫秒一些移动端项目目标 30 帧也就是 33.3 毫秒但无论哪种CPU 和 GPU 都在抢这几十毫秒。CPU 这边最常顶着的是“绘制指令提交”和“逻辑计算”。Unity 里你每挂一个 MeshRenderer 或者一个带多个子物体的模型渲染管线就要记录一次状态切换、绑定材质、往 GPU 提交一批数据。成千上万的物体意味着成千上万条绘制命令。GPU 这边每一帧要做顶点变换、光栅化、像素着色还有频繁的纹理采样。顶点太多、像素填充太狠、贴图太大、Shader 太重都会把 GPU 的时间吃光。很多人搞混一个概念一个游戏卡不是因为“东西多”而是因为某个环节的瓶颈被打穿了。CPU 和 GPU 是并行跑的两条流水线CPU 卡并不代表 GPU 忙反过来也一样。用 Profiler 看数据时要分清当前瓶颈到底在 CPU 还是在 GPU否则很容易做无用功——比如你苦心把模型面数砍了一半结果发现瓶颈根本不在 GPU 顶点阶段帧率毫无变化白白消耗团队精力。这个“瓶颈思维”和 Julia 社区聊性能优化时常提的内存管理很像不考虑分配发生在哪、发生在高频循环还是低频初始化就不知道优化代码哪里有效果。场景搭建同理——先搞清楚每帧预算花在哪个环节比盲目减面、盲目删东西重要得多。1.2 场景里最常见也最隐秘的消耗项场景性能问题里有三个经常被低估的消耗项。第一个是 Draw Call 批次。它比面数更容易成为真正的瓶颈尤其在移动端。CPU 提交命令的成本远高于 GPU 处理三角形同一个模型用 10 个材质比 10 个模型共用 1 个材质更容易卡。美术层面能做的就是“共用材质、共用网格、图集化”后面会展开。第二个是 Overdraw也叫重复绘制。一个像素被反复画了好几次画面看起来没问题但 GPU 的像素填充率已经被悄悄吃没了。典型场景半透明粒子叠几层、草地叶片互相穿插、UI 图标的九宫格叠太多层。在 Unity 的 Scene 视图打开 Overdraw 模式看哪里白得发亮哪里就是填充率危机。别小看这个指标移动端尤其敏感很多时候帧率上不去不是三角形太密而是每一片草叶都被画了两三遍。第三个是纹理带宽和内存。现在高分辨率贴图很常见4K 甚至 8K 材质一拖进来显存或共享内存立刻见底。移动端 GPU 和 CPU 共享一块内存贴图越大读写带宽消耗越大手机升温越快最后引发降频帧率在游戏中途突然掉下来。你看灯的功耗热本身就是性能的敌人。这个问题游戏圈天天喊但做场景的往往到中后期才意识到贴图尺寸不是“越大越清晰”这么简单压缩格式、Mipmap、图集布局都影响最终体验。除了这三个还有物理碰撞体、动态阴影、实时反射探针、屏幕后处理等都会在特定场景里成为“隐藏刺客”。排查这种问题时第一件事不是猜而是把数据和指标摆出来。1.3 先建一张场景性能预算表既然每帧是一张预算账本搭建前就应该先把预算表定好。预算表不需要做得很学术但要能落地。以下是我在一个移动端项目里实际用过的模板目标设备是中端 Android 手机帧率目标 30 帧指标预算值说明帧耗时33.3msCPU 主线程和渲染线程各 6~8msGPU 控制在 16ms 以内Draw Call≤300超过这个数字CPU 渲染线程压力明显上升三角形≤40 万全场景一帧内可见三角形的估算上限Overdraw平均 ≤2后处理区域之外像素重复绘制次数控制在 2 倍以内纹理内存按项目分配压缩后单个场景建议不超项目内存预算的一半真机温度≤42℃连续跑 30 分钟后的机身温度超过就要降负载具体数字会因为项目平台和美术风格差异很大。重点不是数字本身而是把预算写进场景设计文档让美术、TA、客户端开发都看到。这样搭建过程中每一步都有据可依——这个墙面的贴图为什么只能给 1024因为预算表上写了这棵树为什么只能用 3 个 LOD因为预算表就给了这么多。如果一开始没有预算表优化就会变成“上线前大家一起挑毛病”美术改得心烦程序调得头大。有了预算表优化的入口就从“事后补救”变成了“事前设计”。所以这个部分写得再啰嗦都值得。2. 搭建前先定调灯光、烘焙与氛围方案的取舍2.1 动态光与烘焙为什么“静态优先”是大多数场景的最优解“好看和性能兼顾”这句话落到场景搭建里最核心的博弈场就是光照方案。一个大而化之的经验是能不动态就不动态能烘焙就烘焙。实时灯光越多每帧要做多次光照计算再加上实时阴影GPU 负载一下子就上去了。动态光照最低也是每盏灯 Multiple Pass 的叠加而烘焙静态光是一次性代价游戏运行期间完全不花 CPU/GPU——这个差价在移动端尤其明显。很多人觉得烘焙是“老办法”不够酷。但如果你做的场景大部分物体是不动的——地面、建筑、道具、植被这些静态物体用烘焙光照完全够效果还因为拥有全局光照信息而更柔和。你想实现那种既明亮又有层次的环境光反射通常不是靠多放几盏灯而是软件烘焙替你把光算好了。真正适合实时动态光的场景反而是少数比如大量角色、载具频繁移动的玩法地图或者有大量可破坏物、需要实时光照反馈的关卡。但动态光照也不是完全不用。现在 UE/Unity 都支持混合光照模式模型上区分“固定光”和“仅烘焙”物体可以把动态物体处理好又不至于全场景实时计算。核心原则把实时光照用在真正需要动态表现的地方其余交给烘焙。2.2 Lightmap、Light Probe 与阴影的落地配置烘焙不是简单点一下“Generate Lighting”就完了有几个参数直接决定“好看”和“性能”。Lightmap 分辨率是第一个关键。它是场景精度和内存之间的平衡。一片场景用一个 2048 方块能保证大面墙的明暗过渡细腻但内存也会明显上涨。实际经验是主体建筑和地形用 2048 或 1024小道具、装饰件用 512 甚至 256。烘焙前要检查 UV 利用率很多烘焙漏光和技术瑕疵都源自 UV 排列卷绕、UV 岛间距不够。Light Probe光照探针是动态物体的救星。角色、移动平台、能被搬动的箱子都会在场景里穿过不同光照区域。没有 Light Probe它们只会收到统一的环境光看起来像纸片一样浮在场景上。布点时沿着角色可能的行动路径放得更密一些在门框、走廊拐角、窗户旁边多放几个数值上并不贵但对画面完整度提升非常明显。阴影方案也要提前想。移动端项目我不会轻易开全屏实时阴影因为阴影深度贴图生成和采样都是 GPU 成本。常见的替代方案包括给主要物体加一个极低透明度的暗面模型或者用贴花式假阴影/Ambient Occlusion 贴图模拟接触阴影。PC 端的阴影可以开高一点但也要控制级联阴影的距离与分辨率远处可以淡出或退成烘焙阴影。2.3 后处理的加减法氛围感不等于滤镜堆叠后处理是拉高画面“氛围感”最便宜的手段也是压垮 GPU 最便宜的“毒药”。Bloom、Color Grading、HDR 范围映射、Motion Blur、景深……每加一个全屏效果等于每个像素都多跑一遍全屏计算。对 1080p 甚至 1440p 的移动端来说多个全屏效果叠加填充率马上就紧张了。我建议做场景时把后处理效果分成“必须项”和“加分项”。必须项只有几个基础色调、必要的光晕、仅作为氛围的 Bloom。加分项比如景深、径向模糊、体积光逐平台开开关。可以做一个“视觉完整性清单”对某个场景来说哪个效果拿掉后玩家会觉得“画面变丑了”列入必须项拿掉后大部分人察觉不到的列入加分项。这个清单再和技术侧对齐形成可执行的后处理降级策略比如低端机自动关掉 Motion Blur、减少 Bloom 采样层数。后处理本身不是问题问题在于用加法堆出好看而不是用精准的减法做高级感。摄影里讲究构图做减法场景搭建和后期调色也一样。3. 地编实操模型、贴图、植被与摆放策略3.1 用 LOD 和减面拿回帧率但别在错误的地方较劲LODLevel of Detail是场景搭建里必须掌握的基本功。同一棵树近处用高模远处用低模更远处直接换成一个十字片或者干脆剔除。UE 的 Nanite 能在超高面数下部分替代手工 LOD但多数项目还是手工配置 LODGroup。配置时注意三个参数切换距离、每级面数、过渡方式。切换距离不是随心设的要配合视锥和相机移动速度。移动端常见经验是近景 LOD0 距离设成 10~20 米中景 LOD1 在 20~50 米远景 LOD2 负责填满视野。面数梯度别一下砍太狠比如 10000 → 5000 → 1000中间档保留得细一点跳变会小很多。过渡方式上Crossfade交叉淡化效果平滑但会增加渲染开销Dither 过渡在某些移动 GPU 上会带来像素着色负担使用时也要实测。减面这件事别在错误的地方较劲。很多时候你花两小时在雕刻软件里把墙面减了 2000 个面不如把墙边放着的那个 10 万面装饰模型砍成正八棱柱。要根据预算去扫雷先看场景里哪些模型占的面数比例最大再决定值不值得减。用 Profiler 或统计工具按网格面数排序别靠肉眼感觉。3.2 贴图压缩与纹理复用视觉质量不会骗人内存会贴图尺寸规范很容易被美术忽略。很多团队文档里写着“场景贴图最大 2048”实际上文件夹里 4K、甚至 8K 的图是正常操作。在 PC 上 8K 可能影响不大但放到移动端就是灾难。一个常用的换算一张 1024x1024 的 RGBA32 纹理占 4MBASTC 4x4 压缩后约 1MBASTC 8x8 更低。一个普通场景里几十上百张贴图面数远小于贴图占的内存。贴图压缩格式要按平台选。Android 上优先 ASTC低端或老设备退回 ETC2iOS 全系列基本都支持 ASTC。关键点压缩会影响质量和色带表现尤其是天空渐变、灰阶高度图、法线贴图。经验是用“噪声抖动”打破色带很多引擎后处理或导入管线里能加。纹理复用比“压缩”更值得花时间。同样一块砖墙贴图配上不同 Tiling、不同色调差异就能覆盖小区里大半建筑外立面。把公用的砖、木纹、金属、地面材质做成图集或通用材质库让地编同学“拼贴”而不是“每面墙新建一张图”。这个习惯能同时省内存、省带宽、省制作时间——好看的场景从来不靠贴图堆数量。3.3 植被与重复物件的实例化摆放场景里最容易把帧率拖垮的就是植被——树、灌木、花、草丛几百上千棵是常态。同样一棵树用“复制粘贴”的方式摆 1000 棵游戏就在 1000 个独立 Draw Call 里游泳用 GPU Instancing所有同 Mesh 同材质的树被引擎合并成几个批次性能差距往往有几十倍。Unity 里开启实例化很简单把材质勾上 Enable GPU Instancing再确保物体共用同一个网格和材质引擎能自动合并。UE 这边常用 HISMHierarchical Instanced Static Mesh或 PCG 生成植被。注意实例化不等于完全没有代价每个实例仍然要参与视锥剔除读它的 Transform 数据但总开销远小于独立渲染。植被摆放时还要注意叶片越密、半透明越多Overdraw 越严重。草地的叶片如果叠得很厚即使 Draw Call 很低像素填充也不一定扛得住。我的做法是草丛整体用“贴片式”方式做一片草地由若干个大叶片模型组成再用稀疏的独立草叶点缀近看细节不丢远看不觉得假Overdraw 可控。3.4 合并与剔除让引擎替你省掉看不见的活“看不见的物体就不应该被渲染”——这句话听着像废话但很多场景都做不到。地编摆出来的物件跑起来时很多在墙后面、在视野外或者远到已经看不清了引擎却还在老老实实画它们。三个手段帮你把这个浪费找回来。第一个是视锥剔除引擎默认做只要模型包围盒没问题就不卡。第二个是遮挡剔除Occlusion Culling针对室内和城市这类封闭场景效果极好。Unity 里需要把场景标记为静态、烘焙遮挡窗口然后被墙挡住的东西就真的不画了。第三个是距离剔除或显示距离限制。超大场景里半径几百米外的建筑和粒子完全可以隐藏。这个距离阈值可以参考 LOD 的最远档——如果最远档已经足够低调就不必再渲染。合并与剔除之外还要小心静态批处理的内存副作用。Static Batching 会把一堆小物体合并成一个大的网格缓冲Draw Call 降下来了但内存会涨。物件太多且纹理太杂时合并内存可能超过收益。判断方法在场景中测完后看 Profiler 内存如果 Draw Call 已经不是瓶颈就别强行合并。4. 移动端与 PC 端的差异化调优平台决定手段4.1 移动端 GPU 的脾气带宽、发热与 TBDR移动端和 PC 最大的差异不是性能数字而是架构和物理限制。移动 GPU 大多采用 TBDRTile-Based Deferred Rendering架构画面先在芯片上的一小块内存里渲染完再一次性写回显存。这带来一个奇特的结果延迟光照和多 Pass 的渲染方案在某些移动 GPU 上反而比保存中间结果更高效因为 Framebuffer 不用来回写。但别高兴太早——纹理读取还是要走内存带宽依然极度宝贵。发热是移动端另一个隐形的墙。一个场景在手机上稳定 30 帧跑十分钟后芯片温度上来降频到 15 帧这在移动游戏里太常见了。这就是为什么做移动端优化时不能只看瞬时帧率还要看功耗和温升。很多团队会定一个目标某个场景在真机上连续跑 30 分钟机身温度不超过 42 度帧率不低于 30。这个目标逼着你在做场景时尽量少用重后处理、少拉高分辨率、少开实时反射。PC 端相对宽松有独立显卡的大显存、高带宽实时阴影和全局光照可以开得更猛高端卡还能硬件光追。但 PC 端的帧率期望也高动辄 144Hz、2K/4K 显示器功耗散热没那么大问题但“像素总量”依然对 GPU 填充率有压力。拿移动端的思路硬套 PC 端会显得性能冗余拿 PC 端的思路做移动端就是灾难。所以场景方案必须先定目标平台。4.2 各引擎的性能分析工具怎么用工具使用是另一个值得写透的主题。我以 Unity 和 UE 为例但思路通用。Unity 系Unity Profiler看 CPU 主线程和渲染线程耗时、内存峰值、GC 分配。连接真机时勾选 Deep Profile 会显著影响性能只适合小范围 Profiling。Frame Debugger逐条查看当前帧的 Draw Call 列表。这里的核心用法是可以看到每个批次消耗在哪里、是否有重复材质、是否命中了 SRP Batcher。UWA 或自建性能平台用于真机批量采样输出每帧耗时曲线。UE 系Unreal InsightsUE5 推出后基本替代了旧的 Profiler能看到 CPU/GPU 时间线以及每一帧里各系统占用的耗时。GPU Visualizerr.GPUStats相关命令可以看到“BasePass、ShadowDepths、Translucency”等阶段的 GPU 时间。抓帧工具方面RenderDoc 能抓取 DX/Vulkan 的一整帧逐 DrawCall 检查顶点数、像素数、资源绑定是深度学习“GPU 内部发生了什么”的利器。Android 上 Google 的 Android GPU Inspector 能读到 Adreno/Mali 等移动 GPU 的硬件计数器直接看填充率、带宽压力。这一层的工具光看引擎自带 Profiler 是不够的。查清楚是 CPU 瓶颈还是 GPU 瓶颈是顶点瓶颈还是像素瓶颈后面所有优化动作才会有方向。4.3 真机验证清单别拿编辑器帧率骗自己编辑器里的帧率和真机毫不相干。编辑器用的是桌面 GPU、没有降频、没有共享内存争抢、帧率统计方式也完全不一样。所以我给团队定的规矩是场景每次进入“验证期”必须上真机看数据。一份简单可执行的真机验证清单大致长这样跑场景前先确认手机电量在 30% 以上、关闭后台推送和录屏、开启飞行模式如果不需要网络。用统一的标准档位记录帧率比如同一台基准机、同一种画质档位、同一段固定路径。连续跑至少 10 到 15 分钟记录帧率曲线和机身温度观察是否出现降频后掉帧。用 Profiler 抓若干关键节点的 CPU/GPU 耗时看有没有特定物件进场后帧率跳水。最低配机型、主流机型、旗舰机型各跑一遍记录差异。这里顺带说一句有时候真机表现特别差不一定是场景问题。在 Windows 上跑 PC 端预览时如果系统后台拖着一堆服务、电源模式是省电挡、临时文件把磁盘占满帧率数据也会被严重干扰。把系统环境调干净再测至少能保证数据可信。也有人喜欢写一段批处理脚本一键关闭后台服务、切高性能电源、清临时文件这个在测试机上准备好一套干净环境倒是可以的。不过这种“系统级抢时间”只能算是测试环境的清洁问题真正决定场景好不好看的还是场景内部的光照、资产和控制方案。5. 场景优化的反直觉案例从坑里长出来的经验5.1 降了面数反而没提速有次我优化一个室内样板间目标是把动态阴影的问题先放一边单纯降模型面数。美术同学花了好几天把家具、墙面、装饰品全部做了减面处理三角面总数大概降了 40%。结果放真机上一跑帧率几乎没动。后面用 Frame Debugger 一查才明白Draw Call 一个都没少几千个独立物件依然把 CPU 的渲染线程塞满了。瓶颈根本不在 GPU 顶点处理而是在 CPU 的提交开销。这是个典型教训看到帧率卡第一个动作不应该是“砍面数”而是先用工具定位瓶颈。降面数只对 GPU 顶点处理瓶颈有效如果是 CPU Draw Call 瓶颈优先做合并材质、开启实例化、做图集。5.2 关掉阴影之后画面“发飘”了移动端项目实时阴影太重我决定把主光源的实时阴影关掉帧率立刻上去了不少。但测试群里反馈“画面变假了”“东西像贴在地上一样”。后来分析原因阴影在画面里承担着巨大的“接地感”和空间深度提示尤其物体之间小缝隙的阴影稍微缺一块视觉上就觉得浮起来。最终方案不是重新开回来而是用三种替代补上给地面和物体接缝做烘焙 AO在贴图上模拟接触阴影对关键角色和交互物件单独保留低分辨率的实时阴影范围为角色周边几米静态物体把阴影信息烘焙成 Lightmap 的一部分动态物体用 Light Probe 补。实践下来画面恢复了立体感帧率依然保持住了。这个案例让我彻底理解了一件事一味硬砍功能不是优化优化是“砍掉一个消耗项之后找到另一个更便宜的方式补回它的视觉职责”。5.3 贴图压缩造成的色带与烘焙漏光第一次把项目从开发机切到移动端平台时天空盒和渐变材质上出现了明显的色带一层一层的横纹特别难看。原因是 ETC2/ASTC 这种带损压缩格式在低码率下对渐变不友好差异细微的颜色被量化成几个跳变。解决办法分几路关键渐变贴图单独提高压缩率Shader 里给颜色加一点微小的抖动Dither打散色带天空盒这类超大渐变纹理尽量不压缩或者用程序化天空替代贴图。烘焙漏光则是另一个经常被甩锅的问题场景明明没有光能进来的地方出现了发亮的缝、漏光的边缘。排查时发现大多是模型的问题——墙与墙之间有微小缝隙、两个平面互相重叠、UV 岛之间间隙太大。后来我们把“所有体积表面必须闭合、没有重叠面、UV 留出安全间距”写进地编规范烘焙前再用脚本批量检查漏光率大幅下降。这些属于“光看漂亮渲染图永远发现不了必须看贴图、看几何、看 UV”的底层问题。5.4 LOD 切换的跳变与“优化过度”的边界LOD 切换是另一个磨人的问题。有时候 LOD0 到 LOD1 的面数差太大或者距离设得太激进玩家正常走路时能看到树冠和墙体“啪”地变了一个形状非常出戏。后来把切换距离拉开、在中间档多留一档再加上过渡动画跳动基本消失了。另外不同物件的关键程度不一样——主角身边的物件、UI 里显示的道具、剧情镜头看得到的装饰LOD 切换要非常克制远处的填充物则可以大胆减。最后我还要提醒一句“优化过度”的反面有些场景优化过头了贴图全压小、阴影全去掉、后处理全关、LOD 距离压得很近帧率自然好看但画面也失去了个性和氛围。玩家说不上来哪里不对就是觉得“这个游戏很便宜”。优化的底线是保住视觉完整性和独特气质。比较好的做法是维护一份场景“不可妥协清单”这个场景的核心氛围、关键材质质感、标志性的光影效果无论如何都要保留其他辅助效果按预算逐级关闭。这样团队在降级时有优先级而不是一刀切。6. 从“搭完再调”到“边搭边验证”的流程化方法6.1 分阶段搭建每一层都要过一遍机器场景搭建如果还停留在“全部搭完再统一优化”那后面大概率是灾难。我现在的做法是分阶段搭建每个阶段结束都跑一次真机验证白盒布局期用简单的方块和灰模搭出关卡结构、动线、空间尺度。这个阶段就要确认大场景的物件数量、可见距离、大体遮挡关系。资产导入期把真实美术资源替换进来从灰模过渡到正式场景。每导一批资源就统计 Draw Call、内存、三角形看有没有瞬间超预算的。精修打磨期做光照烘焙、后处理、氛围调整。烘焙重、后处理重、粒子特效重全都集中在这个阶段所以每调一次都要看真机。这种流程能让超预算的“病灶”在早期暴露比如白盒期就发现场景太大导致物件数量必然超预算那就提前调整关卡范围或拆分场景而不是等几个月的资产都做完了才发现。6.2 把性能检查变成日常动作而不是上线前的大扫除性能检查和写代码跑测试一样应该是日常动作不能等到快上线才“大扫除”。在实际操作中我会在项目里放一些简单的编辑器工具脚本帮助地编在搭建时随时自查。这里分享一个 Unity 编辑器小脚本的思路用来统计当前选中场景里的 Mesh 三角形总数和大致 Draw Call 数量using UnityEngine; using UnityEditor; using System.Collections.Generic; public static class SceneStatWindow { [MenuItem(Tools/统计场景负载)] static void CountScene() { MeshRenderer[] renderers Object.FindObjectsOfTypeMeshRenderer(); int verts 0; int tris 0; HashSetMaterial mats new HashSetMaterial(); foreach (MeshRenderer mr in renderers) { if (!mr.enabled || !mr.gameObject.activeInHierarchy) continue; MeshFilter filter mr.GetComponentMeshFilter(); if (filter ! null filter.sharedMesh ! null) { verts filter.sharedMesh.vertexCount; tris filter.sharedMesh.triangles.Length / 3; } foreach (Material mat in mr.sharedMaterials) if (mat ! null) mats.Add(mat); } Debug.Log($[场景负载] 顶点: {verts} 三角形: {tris} 唯一材质数: {mats.Count}); } }注意这个脚本只做粗估真正的 Draw Call 还要结合 Static Batching、GPU Instancing、SRP Batcher 看。但日常产出来说它已经能救命了——很多地编同学可能连“我的场景有多少三角形”都答不上来。6.3 谁来为“好看与性能”负责流程越往后越会发现一个场景能不能既好看又流畅往往不是某一个人的事而是一个机制的事。团队里最好有人专门对场景的整体性能负责——通常 TA 或主美带客户端程序支持。TA 的职责是定预算、写规范、维护资源检查工具、做平台降级方案主美负责守住视觉底线客户端程序和 TA 一起在真机上看数据。地编同学是最直接接触场景的人他们需要懂起码的性能常识Draw Call 是什么、LOD 怎么配、贴图大小怎么选、阴影广告牌怎么用。不需要看懂底层渲染源码但要知道自己摆一个物件、换一张贴图、加一排灯光会对帧率产生什么量级的影响。这比上线前专门组织一场“性能优化突击”要省太多成本。我最后再分享一个很小但很实际的习惯把团队定的场景性能预算表打印出来或者放在场景文档第一页每次接一个新场景任务第一眼先看预算。不要低估这种“贴墙上的规矩”的力量。我见过太多项目性能知识大家都懂但一到做场景就放飞自我——因为预算没有成为设计输入的硬约束。预算一旦写进文档和流程大家都按同一套标准干活好看与性能的自然融合就会发生。