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 帧不是黑魔法，是这套组合拳打出来的真实工程效果。