Three.js 渲染管线精解Draw Call 归并与大规模 3D 场景优化一、百个物体就卡WebGL 那道隐形墙接手一个智慧园区可视化项目时前任留下的代码在 800 棵树模型下直接卡成 PPT。表面看是「物体太多」根因却不在顶点数而在Draw Call绘制调用的爆发。一次提交CPU 就要做一次状态切换、缓冲区绑定、驱动层调度。当场景有上千个独立 MeshCPU 每帧要发出上千次调用瓶颈瞬间从「GPU 算力」转移到「CPU 提交效率」。这事我见过太多团队栽进去。某 GIS 厂商曾做过对比同一份城市建筑数据从 500 栋加到 2000 栋FPS 从 55 掉到 8但 GPU 占用率反而下降到 30%。明显的 CPU 提交受限。Three.js 默认一个 Mesh 对应一次 Draw Call。要渲染城市级楼宇、粒子星系或海量标注点必须主动把绘制调用压下去。核心手段是合批Batching、实例化Instancing与纹理图集Texture Atlas它们根本上都是「用更少次的提交画更多的东西」。二、管线拆解从场景图到屏幕像素理解优化先要看清一帧是怎么画出来的。Three.js 在渲染前会做视锥裁剪丢弃相机看不见的物体然后按材质与几何体排序以合并状态接着遍历可见对象逐个发起 Draw Call最后 GPU 执行顶点着色、光栅化与片元着色输出像素。优化空间就藏在这条链路的每一环。flowchart TD A[Scene 场景图] -- B[视锥裁剪: 剔除不可见物体] B -- C[按 material/geometry 排序] C -- D[合批/实例化合并] D -- E[逐 Draw Call 提交 GPU] E -- F[顶点着色器变换] F -- G[光栅化] G -- H[片元着色器上色] H -- I[深度测试与帧缓冲] subgraph CUT[可优化点] J[裁剪减少提交数] K[排序减少状态切换] L[实例化压低 Draw Call] end B -.对应.- J C -.对应.- K D -.对应.- L实例化InstancedMesh是降 Draw Call 的利器当千百个物体共用同一几何体与材质、只是位置/颜色不同可以只提交一次把每个实例的变换矩阵塞进一个实例属性缓冲由 GPU 在顶点着色器里分别摆放。这样一千棵树也只占一次 Draw Call。合批则适用于静态且材质相同的物体在加载期把多个几何体的顶点合并成一个大 BufferGeometry运行时当作单个 Mesh 绘制。代价是失去了单独拾取与变换的能力适合背景、建筑外壳等「不动也不单独交互」的部分。三、生产级实例化海量同类物体的高效渲染下面给出一个 InstancedMesh 实战示例演示如何用一次 Draw Call 渲染上万个带独立位置与颜色的标记点并在数据更新时做增量同步避免整批重建。import * as THREE from three; // 用实例化把 N 个同类标记压成一次 Draw Call根治 CPU 提交瓶颈 function createMarkers(count: number, geometry: THREE.BufferGeometry, material: THREE.Material) { const mesh new THREE.InstancedMesh(geometry, material, count); // 启用实例颜色每个标记独立着色仍只占用一次绘制调用 mesh.instanceColor new THREE.InstancedBufferAttribute(new Float32Array(count * 3), 3); const dummy new THREE.Object3D(); // 复用临时对象避免每帧 new 触发 GC const update (positions: Array[number, number, number], colors: Array[number, number, number]) { for (let i 0; i count; i) { const [x, y, z] positions[i]; dummy.position.set(x, y, z); dummy.updateMatrix(); // 把位置写入 4x4 矩阵供顶点着色器摆放实例 mesh.setMatrixAt(i, dummy.matrix); mesh.setColorAt(i, new THREE.Color(colors[i][0], colors[i][1], colors[i][2])); } // 仅标记实例缓冲需上传不让整个几何体重新提交 mesh.instanceMatrix.needsUpdate true; if (mesh.instanceColor) mesh.instanceColor.needsUpdate true; }; return { mesh, update }; } // 渲染循环限制像素比避免高分屏把片元量放大数倍拖垮 GPU function startLoop(renderer: THREE.WebGLRenderer, scene: THREE.Scene, camera: THREE.PerspectiveCamera) { // 上限设为 2devicePixelRatio 在手机上可能到 3全开极易过热掉帧 renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); let raf 0; const tick () { raf requestAnimationFrame(tick); renderer.render(scene, camera); }; tick(); // 返回清理函数组件卸载必须取消循环否则页面切走仍空转耗电 return () cancelAnimationFrame(raf); }这段实现的三处关键第一InstancedMesh把上万个标记合并为单次提交Draw Call 从 N 降到 1第二needsUpdate只标记实例缓冲重传而非重建几何体增量更新低成本第三setPixelRatio封顶与cancelAnimationFrame清理分别守住了 GPU 负载上限与隐藏页的资源浪费。四、优化边界合批与实例化的代价这些手段不是免费的必须清楚其边界。第一InstancedMesh 的实例共享同一材质无法对单个实例单独换贴图除非用图集 实例 UV 偏移。若业务要每个物体有截然不同的外观实例化就失灵需回到图集方案或接受更多 Draw Call。第二合批会牺牲灵活性。合并后的大几何体无法单独做变换、拾取或隐藏任何局部改动都要重建整批。因此它只适合静态背景不适合需要频繁增删的动态物体。第三过度裁剪也有坑。视锥裁剪依赖包围盒若物体包围盒算错如骨骼动画未更新 bounds会被错误剔除而「消失」。Three.js 的frustumCulled默认开启遇到诡异消失可临时关闭排查。某动画项目曾因此耗掉两个通宵定位——一批带动画的旗帜一夜间全部隐形。第四是材质切换成本。即便不增加 Draw Call频繁切换material也会触发状态切换开销。应尽量把场景按材质聚类渲染减少「红树、蓝树、红车、蓝车」这种交错顺序改成「先所有树、再所有车」。最后是移动端现实。手机 GPU 带宽与填充率有限setPixelRatio过高会让片元阶段成为新瓶颈。当物体不多却仍卡往往不是 Draw Call 问题而是过度绘制overdraw半透明叠加、大面积后处理都会成倍增加像素工作量此时该优化着色器而非合批。五、总结Three.js 性能优化的第一性原则是把 Draw Call 数量压到与「真实需要的提交次数」一致。落地要点有三第一同类大量物体优先用 InstancedMesh 一次提交画完静态同类物体用合批减少调用第二渲染循环必须限制像素比并设置生命周期清理避免隐藏页空转与移动端过热第三认清边界实例化共享材质、合批丢失单体交互、材质切换仍有开销、卡顿也可能来自 overdraw 而非 Draw Call。先定位瓶颈用renderer.info看 drawCalls再对症下药才是工程化的正确顺序。这条路在百万级顶点下能跑通回报是值得的。
Three.js 渲染管线精解Draw Call 归并与大规模 3D 场景优化一、百个物体就卡WebGL 那道隐形墙接手一个智慧园区可视化项目时前任留下的代码在 800 棵树模型下直接卡成 PPT。表面看是「物体太多」根因却不在顶点数而在Draw Call绘制调用的爆发。一次提交CPU 就要做一次状态切换、缓冲区绑定、驱动层调度。当场景有上千个独立 MeshCPU 每帧要发出上千次调用瓶颈瞬间从「GPU 算力」转移到「CPU 提交效率」。这事我见过太多团队栽进去。某 GIS 厂商曾做过对比同一份城市建筑数据从 500 栋加到 2000 栋FPS 从 55 掉到 8但 GPU 占用率反而下降到 30%。明显的 CPU 提交受限。Three.js 默认一个 Mesh 对应一次 Draw Call。要渲染城市级楼宇、粒子星系或海量标注点必须主动把绘制调用压下去。核心手段是合批Batching、实例化Instancing与纹理图集Texture Atlas它们根本上都是「用更少次的提交画更多的东西」。二、管线拆解从场景图到屏幕像素理解优化先要看清一帧是怎么画出来的。Three.js 在渲染前会做视锥裁剪丢弃相机看不见的物体然后按材质与几何体排序以合并状态接着遍历可见对象逐个发起 Draw Call最后 GPU 执行顶点着色、光栅化与片元着色输出像素。优化空间就藏在这条链路的每一环。flowchart TD A[Scene 场景图] -- B[视锥裁剪: 剔除不可见物体] B -- C[按 material/geometry 排序] C -- D[合批/实例化合并] D -- E[逐 Draw Call 提交 GPU] E -- F[顶点着色器变换] F -- G[光栅化] G -- H[片元着色器上色] H -- I[深度测试与帧缓冲] subgraph CUT[可优化点] J[裁剪减少提交数] K[排序减少状态切换] L[实例化压低 Draw Call] end B -.对应.- J C -.对应.- K D -.对应.- L实例化InstancedMesh是降 Draw Call 的利器当千百个物体共用同一几何体与材质、只是位置/颜色不同可以只提交一次把每个实例的变换矩阵塞进一个实例属性缓冲由 GPU 在顶点着色器里分别摆放。这样一千棵树也只占一次 Draw Call。合批则适用于静态且材质相同的物体在加载期把多个几何体的顶点合并成一个大 BufferGeometry运行时当作单个 Mesh 绘制。代价是失去了单独拾取与变换的能力适合背景、建筑外壳等「不动也不单独交互」的部分。三、生产级实例化海量同类物体的高效渲染下面给出一个 InstancedMesh 实战示例演示如何用一次 Draw Call 渲染上万个带独立位置与颜色的标记点并在数据更新时做增量同步避免整批重建。import * as THREE from three; // 用实例化把 N 个同类标记压成一次 Draw Call根治 CPU 提交瓶颈 function createMarkers(count: number, geometry: THREE.BufferGeometry, material: THREE.Material) { const mesh new THREE.InstancedMesh(geometry, material, count); // 启用实例颜色每个标记独立着色仍只占用一次绘制调用 mesh.instanceColor new THREE.InstancedBufferAttribute(new Float32Array(count * 3), 3); const dummy new THREE.Object3D(); // 复用临时对象避免每帧 new 触发 GC const update (positions: Array[number, number, number], colors: Array[number, number, number]) { for (let i 0; i count; i) { const [x, y, z] positions[i]; dummy.position.set(x, y, z); dummy.updateMatrix(); // 把位置写入 4x4 矩阵供顶点着色器摆放实例 mesh.setMatrixAt(i, dummy.matrix); mesh.setColorAt(i, new THREE.Color(colors[i][0], colors[i][1], colors[i][2])); } // 仅标记实例缓冲需上传不让整个几何体重新提交 mesh.instanceMatrix.needsUpdate true; if (mesh.instanceColor) mesh.instanceColor.needsUpdate true; }; return { mesh, update }; } // 渲染循环限制像素比避免高分屏把片元量放大数倍拖垮 GPU function startLoop(renderer: THREE.WebGLRenderer, scene: THREE.Scene, camera: THREE.PerspectiveCamera) { // 上限设为 2devicePixelRatio 在手机上可能到 3全开极易过热掉帧 renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2)); let raf 0; const tick () { raf requestAnimationFrame(tick); renderer.render(scene, camera); }; tick(); // 返回清理函数组件卸载必须取消循环否则页面切走仍空转耗电 return () cancelAnimationFrame(raf); }这段实现的三处关键第一InstancedMesh把上万个标记合并为单次提交Draw Call 从 N 降到 1第二needsUpdate只标记实例缓冲重传而非重建几何体增量更新低成本第三setPixelRatio封顶与cancelAnimationFrame清理分别守住了 GPU 负载上限与隐藏页的资源浪费。四、优化边界合批与实例化的代价这些手段不是免费的必须清楚其边界。第一InstancedMesh 的实例共享同一材质无法对单个实例单独换贴图除非用图集 实例 UV 偏移。若业务要每个物体有截然不同的外观实例化就失灵需回到图集方案或接受更多 Draw Call。第二合批会牺牲灵活性。合并后的大几何体无法单独做变换、拾取或隐藏任何局部改动都要重建整批。因此它只适合静态背景不适合需要频繁增删的动态物体。第三过度裁剪也有坑。视锥裁剪依赖包围盒若物体包围盒算错如骨骼动画未更新 bounds会被错误剔除而「消失」。Three.js 的frustumCulled默认开启遇到诡异消失可临时关闭排查。某动画项目曾因此耗掉两个通宵定位——一批带动画的旗帜一夜间全部隐形。第四是材质切换成本。即便不增加 Draw Call频繁切换material也会触发状态切换开销。应尽量把场景按材质聚类渲染减少「红树、蓝树、红车、蓝车」这种交错顺序改成「先所有树、再所有车」。最后是移动端现实。手机 GPU 带宽与填充率有限setPixelRatio过高会让片元阶段成为新瓶颈。当物体不多却仍卡往往不是 Draw Call 问题而是过度绘制overdraw半透明叠加、大面积后处理都会成倍增加像素工作量此时该优化着色器而非合批。五、总结Three.js 性能优化的第一性原则是把 Draw Call 数量压到与「真实需要的提交次数」一致。落地要点有三第一同类大量物体优先用 InstancedMesh 一次提交画完静态同类物体用合批减少调用第二渲染循环必须限制像素比并设置生命周期清理避免隐藏页空转与移动端过热第三认清边界实例化共享材质、合批丢失单体交互、材质切换仍有开销、卡顿也可能来自 overdraw 而非 Draw Call。先定位瓶颈用renderer.info看 drawCalls再对症下药才是工程化的正确顺序。这条路在百万级顶点下能跑通回报是值得的。
