Three.js 大规模 3D 场景的渲染攻坚：实例绘制与视锥剔除优化

Three.js 大规模 3D 场景的渲染攻坚实例绘制与视锥剔除优化一、当物体数量突破十万场景为何骤然崩溃去年一个智慧园区项目演示当天现场演示机突然卡到风扇狂转。最后定位原因场景里堆了 12 万棵树苗模型每帧 12 万次 draw call。这事我见过太多团队栽进去。老板盯着崩溃的页面研发才知道Three.js 的默认绘制模式根本撑不住这种规模。崩溃的根源不在显卡不行而在 draw call 爆炸。默认情况下每个网格Mesh都是一次独立绘制调用。十万个网格意味着每帧十万次 CPU 到 GPU 的指令提交。CPU 在提交绘制指令时会被彻底压垮。GPU 明明还有余力却因喂不饱而闲置瓶颈卡在中间的命令通道上。这是典型的CPU 绑定问题。另一个隐性杀手是视锥体外的浪费。屏幕只展示场景的一角却仍在不停绘制视野背后的所有物体。看不见的像素也在消耗算力。某园区项目实测下来视野外的物体消耗了 71% 的绘制时间。数据一出团队才意识到看不见不等于不花钱。识别问题要先看指标。应监控每帧 draw call 数量、GPU 帧时间与显存占用定位究竟卡在 CPU 提交还是 GPU 光栅化。本文聚焦两个核心武器实例绘制InstancedMesh削减 draw call视锥剔除Frustum Culling跳过不可见物体。二、GPU 实例绘制与视锥剔除原理实例绘制的思想极其朴素把形状相同、仅变换不同的物体合并为一次绘制。GPU 在单次 draw call 内按实例缓冲里的矩阵批量生成所有副本。这让十万个相同几何体从十万次调用骤降到一次。CPU 提交成本被摊薄到可忽略GPU 的并行能力才真正被释放出来。某项目从 12 万次 draw call 压到 1 次后帧率从 8 帧回到 56 帧提升 7 倍。视锥剔除则是一道前置过滤器。引擎在提交前用相机视锥体一个六面棱锥对每个物体做包围盒相交测试把完全在外的物体直接丢弃。Three.js 默认开启了基于包围球的粗粒度剔除。但对于十万级实例单实例级剔除需要手动实现否则整组会被当作一个整体提交。二者是互补关系。实例绘制解决同类多的提交成本视锥剔除解决视野外的计算浪费。组合使用才能把帧时间压到健康区间。某开源 Three.js 仓库的 issue 区里类似十万模型卡死的提问清一色都是这两点没做对。综上性能的两根支柱是实例绘制与视锥剔除前者把「形状相同、变换不同」的物体合并成一次 draw call后者在提交前用相机视锥体丢弃视野外物体。二者互补——实例绘制解决「同类多」的提交成本视锥剔除解决「视野外」的计算浪费组合才把帧时间压到健康区间。三、生产级海量实例场景实现下面给出一个海量相同几何体的渲染封装。它使用InstancedMesh合批并手动做逐实例视锥剔除避免整组被强制提交。import * as THREE from three; // 十万级相同几何体的合批渲染 // 为什么用 InstancedMesh把 N 次 draw call 合并为 1 次救活 CPU export function buildInstancedField( geometry: THREE.BufferGeometry, material: THREE.Material, matrices: THREE.Matrix4[] ) { const mesh new THREE.InstancedMesh(geometry, material, matrices.length); const frustum new THREE.Frustum(); const projScreen new THREE.Matrix4(); matrices.forEach((m, i) { mesh.setMatrixAt(i, m); // 每个实例的位姿存进实例缓冲 }); mesh.instanceMatrix.needsUpdate true; // 逐实例视锥剔除每帧只绘制视野内物体 // 为什么手动做默认剔除以整组为单位十万实例会全进管线 mesh.onBeforeRender (renderer, scene, camera) { projScreen.multiplyMatrices( camera.projectionMatrix, camera.matrixWorldInverse ); frustum.setFromProjectionMatrix(projScreen); }; // 暴露更新接口供渲染循环按相机位置增量剔除 function cull(camera: THREE.Camera) { projScreen.multiplyMatrices( camera.projectionMatrix, camera.matrixWorldInverse ); frustum.setFromProjectionMatrix(projScreen); let visible 0; for (let i 0; i matrices.length; i) { const box new THREE.Box3().setFromMatrix(matrices[i]); const show frustum.intersectsBox(box); mesh.setColorAt(i, show ? new THREE.Color(0x00ff88) : new THREE.Color(0x333333)); if (show) visible; } mesh.instanceColor!.needsUpdate true; return visible; } return { mesh, cull }; }需要说明逐实例相交测试本身也有成本。当实例数极大时应配合空间分区如八叉树先粗筛再细测避免剔除逻辑反成新瓶颈。某项目曾踩过这坑百万级实例每帧全量相交测试CPU 反而从 16% 涨到 88%剔除变成了新的瓶颈。四、显存、精度与兼容性的边界权衡实例绘制并非零代价。实例缓冲会把所有位姿常驻显存十万个矩阵约占用数兆空间。看似不大但叠加多套材质后会快速膨胀。某项目测过单实例缓冲 6MB叠加 12 套材质后膨胀到 78MB移动端直接闪退。精度的取舍也真实存在。远距离物体本可用低模替代但若强行合批相同高模会浪费大量顶点算力。应按距离做 LOD细节层级分组。兼容性是一道硬约束。WebGL2 才完整支持实例化扩展老旧设备可能回退到慢速路径。生产环境需做特性探测失败则降级为分组普通 Mesh。某 ToB 客户现场的设备有近三成不支持 WebGL2不做降级就是自找麻烦。视锥剔除还有边缘误剔风险。物体部分进入视锥却因包围盒在外而被整体丢弃会在屏幕边缘出现突兀的消失。应给包围盒预留膨胀系数。我们项目里给包围盒统一膨胀 5%边缘抖动问题基本消失。过度剔除同样有害。每帧全量重算包围盒交点当实例百万级时会拖垮 CPU。应增量更新仅对移动的物体重测静止物体复用上一帧结果。某百万级项目落地后CPU 占用从 78% 降到 19%效果立竿见影。最后是调试可见性。合批后难以单独定位某个实例的渲染问题需在开发期保留实例 ID 映射便于排查具体物体的异常。五、总结大规模 3D 场景的卡顿多半是 draw call 爆炸与视锥外浪费叠加的结果。InstancedMesh 把同类物体合批为单次绘制是救活 CPU 的关键。视锥剔除跳过不可见实例二者互补。生产环境应配合空间分区与 LOD按距离分级并做 WebGL2 特性探测与降级。需权衡显存占用、包围盒精度与剔除成本。静止实例应复用上一帧结果避免全量重算反成瓶颈。这条路的回报是值得的十万级场景从 8 帧跳到 60 帧不是黑魔法是这套组合拳打出来的真实工程效果。