做场景搭建这么多年我最大的感受是好看和流畅这件事在绝大多数团队里都是“鱼与熊掌”尤其是项目一旦进入中后期模型面数堆上去了、特效不加节制地叠帧率就像坐过山车一样往下掉。场景搭建这事如果你的目标只是“出个效果图”那随便磨但如果目标是“能跑的实时场景”那从第一天起性能和视觉就得放在同一张桌子上谈。这篇内容不聊虚的全部来自我实际踩坑和复盘后的经验。核心围绕场景搭建全流程中“好看”和“性能”的平衡点从设计阶段的取舍、资产管线的优化到渲染层面的调度再到上线前的性能体检整理成一套可以直接上手的实战指南。适合刚接手场景搭建需求的前端工程师、数字孪生项目开发者以及所有被“既要炫酷又要流畅”逼疯的人。1. 场景搭建的核心思路先定性能预算再谈视觉效果很多项目一开始就错了因为大家都急着看效果恨不得第一周就把场景堆得满满当当但没有任何一个人能说清楚这个场景的目标帧率是多少、允许的显存占用是多少。没有预算的设计就像不带钱包逛商场最后结账时一定尴尬。1.1 为什么你的场景会越来越卡场景变卡的本质是硬件资源被超出预期的数据量拖垮了。这里的数据量主要有四个来源三角形数量每帧要处理多少个三角形直接决定 GPU 的负载。纹理内存所有贴图加起来占多少显存超出显存就会触发纹理压缩和频繁换页。Draw Call 次数CPU 每次通知 GPU 画一个物体都有开销物件多了就卡在 CPU 上。着色器复杂度材质越复杂GPU 每个像素要算的指令越多。大多数项目的卡顿不是某一个原因而是四个一起爆。比如一个场景里放了几百个带独立材质的装饰物每个都有一张 2K 贴图那么 Draw Call 和纹理内存同时爆不管显卡多好都扛不住。1.2 性能预算驱动的设计流程我建议在场景设计启动前就把性能预算写成一个清单让美术、前端、策划如果涉及交互都认领指标。一份典型的预算大致长这样指标中端机型目标高端机型目标帧率30 FPS60 FPSDraw Call≤ 250≤ 500三角形数量≤ 30 万≤ 100 万纹理内存≤ 1.5 GB≤ 3 GB单场景加载时间≤ 3 秒≤ 1.5 秒有了这张表场景里每加一棵树、一面墙、一个粒子系统你都能立刻判断它“预算够不够”。这不是限制创造力而是给创造力划出安全的边界。我见过太多团队前期完全放开到最后砍需求砍到面目全非比一开始就设限痛苦得多。2. 资源管线的优化从源头给场景“减重”场景好不好看模型和贴图占七成场景卡不卡模型和贴图也占七成。所以资源管线这一环省下来的每一分成本都会在渲染时加倍回报。2.1 模型面数的三个层级我在项目里习惯把模型分成三个层级来管理精度级近景特写用于玩家/相机贴近时看到的模型面数可以放到 5 万到 10 万细节纹理清晰正常视距下肉眼几乎看不出分段。常规级中景主体用于场景中的主要建筑和大型道具面数控制在 1 万到 3 万保留主要结构线和材质分界。远景级远景Cull用于远距离填充视野的背景面数压到 3000 以下甚至可以只保留轮廓和颜色配合雾效把细节藏起来。这套思路的本质是“好钢用在刀刃上”。你在远景物体上放大量面数帧率掉了但玩家根本看不清这属于最典型的浪费。2.2 贴图压缩与纹理图集贴图是显存消耗的大头解决方案不外乎两点压缩格式和排列方式。纹理压缩方面CRN、ETC2、ASTC 这类压缩格式能大幅降低显存占用。比如用 ASTC 6x6 压缩一张 2K 贴图视觉损失很小但显存占用比未经压缩的 RGBA 少一半以上。注意压缩格式要和目标平台匹配移动端选 ASTC 或 ETC2桌面端可以用 BC7。纹理图集方面把多个小物件的贴图拼到一张大图上可以显著减少纹理切换和 Draw Call。但拼图集时要注意 UV 边缘的出血距离留出 2 到 4 像素的余量不然贴图压缩后边缘容易出现“接缝”。这个坑我踩过好几次项目里一旦出现接缝排查起来特别费劲。2.3 模型格式与加载策略现在场景引擎基本都支持 glTF 2.0它是目前实时渲染领域的“通用语言”。但直接扔一个原始 glTF 进去文件和解析开销都偏大。建议集成 Draco 压缩可以对几何数据做极高压缩比复杂模型的顶点数据能缩小到原来的十分之一甚至更低加载速度和网络传输时间都会明显改善。加载策略上不要一上来就把所有资源全部加载。主流方案是首屏只加载必须的“视觉基座”比如地面、天空、主体建筑。相机移动到某区域时再动态加载周边细节。通过加载进度条或占位体灰色盒体过渡让用户无感知。这套“渐进加载”策略对中低端机尤其友好它保证了用户第一眼看到的是完整场景而不是白屏加转圈。3. 渲染层实现用“组合拳”保住帧率资源端减重之后真正的技术博弈在渲染层。在这个层面你需要同时管理“画什么”“以什么顺序画”“画面细节怎么分级”这三件事。3.1 LOD 与遮挡剔除别让 GPU 干无用功LODLevel of Detail技术是场景性能的“肱骨之臣”。它的核心逻辑是根据物体在屏幕上占的像素大小切换不同精度的模型。离得远就显示 200 面的低模离得近就切换成 2 万面的高模中间过程可以设置多个过渡档位。配合 LOD 的还有遮挡剔除。市面上大多数引擎都内置了遮挡剔除Occlusion Culling但默认配置并不一定适合你的场景。需要手动调整“最小剔除距离”和“遮挡体尺寸”等参数确保剔除查询本身不会消耗太多 CPU。这里有个经验值如果遮挡剔除带来的帧率提升不足 5%说明你的场景遮挡关系太少比如露天大平原这时候直接关闭遮挡剔除省下查询开销反而更划算。3.2 光照烘焙与动态实时光的取舍光照对氛围的提升是决定性的但它也是性能消耗大户。实时光照尤其是带阴影的平行光或者多盏点光会迫使 GPU 为每盏光重新计算光照和阴影贴图性能开销呈指数级增长。我的建议是静态场景全绑定烘焙动态物体角色、车辆只挂一盏实时阴影灯。烘焙光照Lightmap / Light Probe可以把光影信息预先计算成贴图运行时零计算开销画面还能获得柔和的环境光遮蔽效果。代价是第一光照一旦烘焙完场景就不再受灯光移动影响第二烘焙质量取决于 UV2 展开得是否干净UV2 重叠或者留白太少烘焙出来的阴影就会出现瑕疵。所以建模阶段就要求美术把 UV2 留好这属于前置规范。3.3 合并 Draw Call 的实践细节Draw Call 数量是移动端场景最敏感的性能指标。合并 Draw Call 的常规手段包括静态合批、动态合批、GPU 实例化Instancing。静态合批适合完全不动的物体比如建筑墙体、装饰雕塑把相同材质的 Mesh 合并成一个大的 Geometry。操作上很容易忽略的一点合并前必须确保材质完全相同哪怕只是贴图引用不同合批就无法生效。GPU 实例化适合大量重复的物体比如路灯、树木、摆件。只要这些物体的网格相同就可以用一份网格数据 一堆变换矩阵渲染成千上万个实例。在某些项目里我把 5000 棵树从 5000 个 Draw Call 压到了 1 个 Draw Call帧率直接翻倍。这里要注意实例化物体的材质中不能有受时间影响的变量如不同的动画时间偏移否则会打断实例化。还有一些小技巧尽量用图集代替散图减少材质球数量尽量在材质里共用 Shader 变体少写“色相偏移”之类的动态分支。4. 后期特效与氛围优化要“气氛”不要“负担”很多场景“看起来一般”不是模型问题而是缺少氛围但“跑不动”也往往是特效堆出来的。后期特效和氛围优化是体现一个场景搭建基本功的地方。4.1 雾效与天空盒性价比最高的氛围提升在保证性能的前提下提升氛围最划算的两招一个是雾效一个是天空盒。雾效可以掩盖远景加载的不足还能统一画面色调。但要注意全屏全距离的指数雾Exponential Fog在部分引擎里可能开销较高建议使用高度雾Height Fog或者距离雾加参数限制让雾效只作用于远距离区域。天空盒适合用 HDR 全景贴图配合轻微的环境光反射能极大增强金属和玻璃材质的表现力。但 HDR 贴图分辨率不要盲目拉高2K 到 4K 足够。过高的天空盒分辨率会让 GPU 在像素着色阶段做很多无效计算而视觉差异微乎其微。4.2 粒子系统的减负方案粒子是移动端场景的头号杀手表现力好但也最容易失控。使用粒子时注意几个原则限制同屏粒子总数中等机型建议不超过 2000 个。用“视差滚动层”替代大范围粒子比如飘雪、落叶通过几层半透明贴图做滚动就能获得类似效果成本几乎为零。粒子贴图做成图集不要在粒子材质上叠加多个动态纹理。粒子系统生命周期结束后一定要释放否则会出现“越跑越卡”的长期内存泄漏问题。血泪教训有一次我用粒子模拟了 3000 个火星飞溅中端机上帧率从 50 直接掉到 18后来改成两层视差贴图加 200 个粒子视觉还原度九成帧率稳回 55。粒子这东西克制比堆量更能出效果。4.3 后处理链路的轻量化组合Bloom泛光、景深、颜色校正这些后处理特效每个都是 GPU 的“加餐”。做氛围提升时可以组合但要注意顺序和数量通常顺序色彩校正 → Bloom → 景深 → 暗角。优先保留色彩校正LUT它能让整个场景的色调统一起来视觉高级感提升明显性能开销小。景深效果建议在 UI 层面配合实现避免全屏景深采样。Bloom 的阈值和强度要调得克制过强的泛光会把画面糊成一片反而显廉价。每一次后处理叠加都会增加一张全屏纹理的采样和混合计算。如果性能吃紧优先砍掉最不影响“第一眼惊艳感”的那一项通常砍的是景深。5. 性能排查与典型问题处理实录无论准备工作做得多细一进入真机调试总会冒出各种性能问题。我把这些年遇到的典型问题和排查思路整理一下可以当速查表用。5.1 帧率突然掉一半先查 Draw Call 还是纹理先别急着猜拿性能分析工具看数据。以 WebGL 项目为例我会同时开两套工具浏览器自带的 Performance Monitor 看 CPU 耗时借助 Spector.js 抓取 Draw Call 调用记录和纹理绑定情况原生项目则用引擎自带的 Profiler。数据出来后按“大头优先”原则定位如果 Draw Call 数量超过预算优先考虑合批和实例化或者减少场景内独立物体数量。如果纹理内存占用过高优先压缩贴图格式、缩小分辨率、检查是否有未回收的纹理对象。如果 Shader 变体过多导致编译卡顿优先给材质做变体分组移除不用的关键字。排查最忌讳“这优化一点那优化一点”的零散改法。先把数据搞清楚再针对最大瓶颈下手本来一个小时的定位时间可以压缩到十分钟。5.2 场景加载慢到让人崩溃加载慢无非两个原因资源太大、或者加载逻辑串行。前者通过 Draco 压缩和纹理压缩解决后者则需要改成并行加载和分帧加载。并行加载指的是把资源网格切成多个页面或区块同时发起请求不让一个慢资源阻塞整个场景。分帧加载指的是每帧只从待加载队列中处理固定数量的资源避免主进程被 IO 操作卡死。实际操作时我会在代码里做一层资源队列管理每个资源标记优先级高优先级放首屏低优先级放视野外每帧最多处理 3 到 5 个低优先级资源的实例化。这样一个 50MB 的场景资源可以平滑加载完不像以前那么卡在某个瞬间。5.3 内存持续增长像漏了一样内存泄漏在场景搭建里最常见的元凶是纹理和网格加载后没有被释放事件监听器没有移除或者定时器还在驱动已经销毁的物体。排查时我会强制做一次“场景切换”从场景 A 切到场景 B再切回来比起看内存曲线更有效的是看“对象数量”曲线。如果每次切换后对象数量都比上一次高那肯定有对象没有被销毁。定位到具体哪类对象MeshTextureMaterial再反向查代码。注意不要忽略粒子系统的动态纹理很多粒子系统每帧都会生成新的 RenderTarget如果不手动释放显存就像破了个洞你越跑越卡。5.4 常见问题速查表症状可能原因解决方案帧率低但 GPU 占用不高Draw Call 过多CPU 瓶颈合批、实例化、减少物体帧率低且 GPU 占用高纹理采样或 Shader 复杂压缩纹理、精简 Shader、降低后处理加载卡顿明显资源太大或 IO 串行Draco 压缩、并行加载场景切回后内存上涨物体未释放检查销毁逻辑手动释放资源物体闪烁Z-fighting 或 UV 接缝修正近裁剪面距离加图集留边远处物体消失视锥剔除或 LOD 切换异常调整 LOD 距离和剔除范围6. 工具选型与实测参数参考这一节给参考的方案和技术参数。工具选型具体取决于你的项目引擎我这里以目前最常见的分支为例分享但思路是通用的。6.1 编辑器与引擎的搭配如果你做的是独立场景如产品展示、线上展厅我建议用轻量级 Web 方案Three.js / Babylon.js 起步配合 Blender 做资产处理。这个组合的好处是迭代快、调试直观、素材生态成熟而且渲染效果与游戏引擎的差距近年来已经很小。如果做的是大体量的数字孪生或复杂交互场景建议选 Unity 或 Unreal。Unity 胜在生态成熟、优化资料多移动端适配好Unreal 胜在画面上限高但对中低端移动设备不友好。没有绝对的好坏取决于团队熟悉哪个以及目标机型是什么。6.2 优化参数的实测基准以下是我个人项目里反复验证过的一套基准参数可以作为起点再根据你的目标平台微调纹理分辨率主要物体 2048次要物体 1024远景和地表 512。LOD 距离第 0 级 0-10 米第 1 级 10-30 米第 2 级 30-100 米100 米外直接裁剪或替换为极简体。阴影贴图分辨率1024 足够移动端2048 用于桌面端特写。最大点光源数量移动端场景控制在 2 盏以内多于这个数量的都用烘焙解决。全局后期Bloom LUT 色彩校正 暗角三件套基本满足 90% 的场景氛围需求。这套参数在多数中端机型上能稳定在 30 FPS 以上高端机型能到 60 FPS。不同项目差异很大但可以从小参数开始跑帧率测试再逐步调大直到找到你的设备“甜点值”。6.3 素材优化流程任何第三方素材资源模型、贴图、SP 材质等进入场景之前我推荐走一个固定检查流程杀面数检查三角形数量凡是超出该层级预算的统一减面。杀材质把同类型物体的材质尽量合并成一个减少 Shader 变体数量。杀贴图检查是否有 1K 以上但细节用不到的贴图统一压到合理分辨率。合批检查确认同材质的物体是否适合合并、是否能走实例化。打 AssetBundle按场景区块或功能模块拆分资源包避免一个超大 Bundle 加载全部。这一整套流程相当于给所有资源过一道“安检”。不通过的资源进不了场景问题从源头上就被过滤掉。7. 移动端适配的特别提示如果你的场景有移动端版本下面这些经验的优先级会高于前面的一切。7.1 关注“发热”而不是只看帧率移动端限制性能和体验的核心因素是功耗。手机跑 3D 场景很容易发热一旦发热系统就会降频帧率再高也会掉下来。所以移动端的目标不是“跑满 60 帧”而是“在 45-60 帧之间平稳运行且功耗可控”。降低功耗最有效的手段限制 GPU 频率、降低后处理分辨率、控制粒子数量、减少全屏特效。很多时候你会发现帧率从 60 降到 45视觉差异很小但手机温度低了整整几度续航和流畅度体验反而更好。7.2 多尺度适配策略移动端的屏幕尺寸和 DPI 五花八门UI 适配只是第一层场景层面要做的是“多尺度的渲染精度适配”。核心思路根据实际屏幕像素比动态调整渲染分辨率。举例来说渲染分辨率并非常年锁定 1.0而可以跟随设备实际渲染负荷动态调节在 0.85 到 1.0 之间。高负载场景下将分辨率下调一点像素密度虽有小幅损失但中端机能保持住 50 帧以上的流畅感远好过卡成 PPT。场景搭建最终考验的是“克制”知道哪里该省哪里该花把有限的性能预算花在玩家第一眼最关注的地方。我个人的体会是场景优化的基本功不是加功能而是做取舍而每一次取舍都应该是清晰的性能数据支撑下的判断而不是凭感觉。这套方法帮我在多个项目里稳定拿到了“看着高级、跑着流畅”的结果希望你也能用上。最后再分享一个小技巧每次完成一个阶段的优化截一张图存下来把对应的性能数据也存下来后面回归对比时你会发现这些记录是你最有价值的资产。
