1. 先搞清楚“爆炸分解”到底在做什么第一次听到“3D模型爆炸分解”很多人会误以为是模型真的被炸碎了。其实不是。它更准确的名字叫Exploded View爆炸视图工业设计里用了几十年装配手册、维修指南、产品宣传片里到处都能看到。比如你买一台洗衣机说明书最后一页画着桶身、电机、螺丝、垫片沿着一条条轴线散开那个就是爆炸分解。放到 Web 端用 Three.js 做这件事本质上是把模型里的每个零件从原始位置沿某个方向平移一段距离让遮挡关系打开再配合缓动动画让整个过程平滑发生。它不改变模型的几何形状不切割网格只动位置和旋转。这一点想通了后面所有实现思路都顺了。我做这个需求是给一个工业设备的展示页用的客户要求“点一下按钮设备散开给参观者看内部结构再点一下装回去”。设备模型是别人用 SolidWorks 导出的 glTF一共 47 个零件节点层级大概三层。整个功能做完核心代码不到 200 行但踩的坑是真的多——模型没居中、零件命名混乱、爆炸方向乱飞、移动端卡成幻灯片每一个都够写一篇。所以下面我把整套东西从思路到代码到避坑完整捋一遍。这篇内容适合三类人看一是刚接触 Three.js、想找个完整小项目练手的朋友二是接到产品 3D 展示需求、不知道从哪下手的开发者三是已经能做模型加载、但动画和交互总是差口气的同学。只要你手上有 glTF 或 GLB 模型跟着做就能跑起来。2. 整体方案设计为什么这么拆2.1 先明确技术选型的几个决定拿到需求后我先列了几个必须回答的问题这几个问题的答案直接决定了代码结构。第一个问题爆炸方向怎么定三种常见做法。一种是从模型包围盒中心往外推每个零件沿“中心到自身”的方向平移一种是指定固定轴向比如全部沿 Y 轴上下分层还有一种是根据零件在装配体里的语义手动标定方向。第一种实现最简单视觉效果也最“放射状”但问题是零件多了以后方向会很乱尤其零件分布不均匀的时候。我最后选的是包围盒中心方向 可覆盖的方案默认按中心方向爆炸但允许通过配置表给特定零件指定固定方向。这样通用和可控兼顾。第二个问题动什么是改position还是改matrix还是用Object3D的父子层级结论是改position最稳。Three.js 里每个Object3D都有自己的局部坐标系直接改position是在父节点坐标系下移动正好符合“零件在装配体里挪位置”的直觉。用矩阵会绕用层级重组会破坏原始结构都不划算。第三个问题动画用什么驱动手写requestAnimationFrame做插值还是用库如果项目里已经引入了 GSAP 或者 Tween.js直接用没问题。但这是个独立展示页我不想为了一个动画多打包几十 KB所以选了手写缓动函数 requestAnimationFrame。核心就一个easeInOutCubic二十行代码搞定可控性还最高。第四个问题性能怎么保47 个零件听起来不多但如果每个零件都单独建一个AnimationAction或者每帧遍历整棵树改属性中低端手机上会掉帧。我的做法是预计算每个零件的目标位置存进数组动画期间只遍历这个扁平数组不碰场景树。这个优化很关键后面会展开讲。2.2 整体架构分三层方案定下来后代码我按三层组织数据层负责从 glTF 场景里收集所有需要爆炸的零件节点算出每个节点的起始位置、目标位置、移动方向、延迟时间存成一个扁平数组。这层只在模型加载完成后跑一次。动画层接收进度值t0 到 1遍历数据层数组用缓动后的值插值计算每个零件当前位置写回position。这层不关心业务纯函数。控制层管理爆炸状态展开/收拢/动画中处理按钮点击、进度条拖动、自动循环播放这些交互把状态映射到进度值传给动画层。这么分的最大好处是加需求不慌。后来客户要“爆炸到一半暂停”我只改控制层动画层完全不用动。再后来要“每个零件依次弹出、有先后顺序”我只在数据层的延迟参数上做文章。分层清晰改动成本就低。2.3 为什么不选另一种常见做法网上很多教程讲爆炸分解用的是递归遍历场景树、给每个 mesh 加 Tween的方式。我一开始也这么写的跑起来发现问题Tween 对象一多每帧开销上去了而且暂停、反向播放、进度条回拖这些交互很难做因为每个 Tween 都是独立时间线。所以如果你做的是“点一下让它自己播完”这种简单场景Tween 方案够用。但只要涉及可拖动的进度条、正反向连续控制、爆炸比例实时调节就一定要用我上面说的“单一进度值驱动”的架构。单个进度值 0 到 1映射到所有零件的位置这套模型是最好扩展的。这也是我做这个项目最大的一个认知转变动画不是一堆独立的时间线而是一个可被外部控制的连续状态。3. 模型预处理把脏活干在前面3.1 模型本身的坑比代码多代码写得好不好是次要的模型质量才是决定这个功能成败的关键。我拿到手的第一版模型导出后加载进场景问题一大堆。第一个大坑模型完全没居中。原始模型的坐标原点在 SolidWorks 装配体的某个基准点上导致加载后模型飘在场景外几米远的地方。不做处理直接爆炸零件会飞得不知所踪。解决办法是在模型加载完成后用Box3算出整体包围盒再算包围盒中心把模型根节点整体平移让中心对准原点。代码大概这样const box new THREE.Box3().setFromObject(model); const center box.getCenter(new THREE.Vector3()); model.position.sub(center);注意这里有个细节平移完之后要重新计算一次包围盒因为包围盒是基于当前世界坐标算的模型挪了位置包围盒也要更新。我第一版忘了这步结果爆炸方向全是偏的查了半天。第二个大坑零件命名是乱的。SolidWorks 导出的节点名字经常是Part1_1、Part1_2这种根本看不出是哪个零件。如果要做“点击某个零件高亮显示名称”这种功能就必须重新命名。我的做法是在 Blender 里打开模型对照工程图把关键零件手动改成语义化名字比如Motor_Housing、Bearing_01。这个工作没法自动化但一次投入后面所有功能都受益。第三个大坑零件层级太深。有些导出工具会生成一堆无意义的空节点把真正的 mesh 埋得很深。爆炸的时候如果按节点全遍历会把空节点也算进去产生无效计算。所以收集零件时我加了一个过滤只收集isMesh为 true 的节点或者有几何体的节点。3.2 一次性收集而不是每帧遍历模型预处理的核心产物是一个数组我管它叫explodeItems。每个元素的形状是这样{ object: mesh, // 零件对象引用 originPos: Vector3, // 原始位置复制不是引用 targetPos: Vector3, // 爆炸后的目标位置 delay: 0 // 动画延迟比例 }这里强调一个极易踩的坑originPos必须是clone()出来的新向量。如果你写originPos: mesh.position那存的就是引用动画一开始改positionoriginPos也跟着变收拢的时候就回不到原位了。我被这个坑折磨了快二十分钟最后打出日志才发现两个值一直是相等的。收集逻辑const explodeItems []; const box new THREE.Box3().setFromObject(model); const center box.getCenter(new THREE.Vector3()); const maxDistance 0; model.traverse((child) { if (!child.isMesh) return; const worldPos child.getWorldPosition(new THREE.Vector3()); const dir worldPos.clone().sub(center); const dist dir.length(); if (dist 0.001) return; // 跳过在中心的零件 dir.normalize(); explodeItems.push({ object: child, originPos: child.position.clone(), targetPos: child.position.clone().add(dir.multiplyScalar(dist * 0.8)), delay: 0 }); });注意里面那个dist * 0.8这是爆炸距离系数。为什么不用固定距离因为零件大小差异大用固定距离的话大零件几乎没动、小零件飞太远。用“到中心的距离乘以系数”能让爆炸幅度和模型尺度成比例视觉上更协调。0.8 是试出来的经验值一般 0.5 到 1.2 之间都行看模型紧凑程度。还有个细节getWorldPosition拿到的是世界坐标但position是局部坐标。如果模型的父节点有缩放或旋转两者不一致方向算出来会偏。稳妥的做法是确保模型根节点没有额外变换或者用localToWorld/worldToLocal做转换。我因为已经做了居中处理根节点变换是单位矩阵所以直接用世界坐标算方向没问题。3.3 手动方向覆盖表怎么用前面说的中心方向方案在某些模型上会出问题。比如一个管道系统所有管子都在同一条轴线上零件到中心的距离向量几乎是垂直于管轴的爆炸后管子会向侧面散开看起来很奇怪。这时候就要用固定方向。我加了一个配置对象const dirOverride { Pipe_A: new THREE.Vector3(1, 0, 0), Pipe_B: new THREE.Vector3(-1, 0, 0), Cover_Top: new THREE.Vector3(0, 1, 0) };在收集循环里判断一下如果当前节点名在覆盖表里用指定的方向否则用中心方向。方向向量不用归一化也行因为后面会normalize。这个机制让我能对个别“不听话”的零件单独调不用改通用逻辑。4. 动画实现缓动与进度驱动4.1 缓动函数为什么必须手写缓动函数决定了动画的“手感”。线性运动看起来像机器人太生硬。工业展示要的是“稳、顺、有质感”标准答案就是easeInOutCubic——开始慢、中间快、结束慢。这个曲线在视觉上最舒服几乎没有争议。Three.js 自带MathUtils里有几个缓动函数但类型不全而且很多时候你需要自定义参数。我的建议是直接手写反正就几行function easeInOutCubic(t) { return t 0.5 ? 4 * t * t * t : 1 - Math.pow(-2 * t 2, 3) / 2; }这个函数接受 0 到 1返回也是 0 到 1。数学上保证f(0)0、f(1)1、f(0.5)0.5中间平滑过渡。为什么是三次方不是二次方三次方的加速度变化更连续视觉上“顿挫感”更弱。二次方在起点和终点附近还是能感觉到一点急刹。顺便说一个坑缓动函数的输入必须被 clamp 到 0 到 1。如果你的进度值因为浮点误差变成 1.0000001某些缓动公式会算出异常大的值。我在应用缓动前会加一句t Math.min(1, Math.max(0, t))一劳永逸。4.2 进度值驱动的核心渲染循环整个动画的核心就一个函数接收进度t把每个零件放到该在的位置function applyExplode(t) { const eased easeInOutCubic(Math.min(1, Math.max(0, t))); for (let i 0; i explodeItems.length; i) { const item explodeItems[i]; const localT item.delay 0 ? Math.min(1, Math.max(0, (eased - item.delay) / (1 - item.delay))) : eased; item.object.position.lerpVectors(item.originPos, item.targetPos, localT); } }lerpVectors是 Three.js 向量自带的线性插值方法等价于origin (target - origin) * t但内部做了优化比你手写三元表达式快一点也更简洁。这段代码里有三个值得讲的点。第一延迟机制怎么实现的。item.delay是 0 到 1 之间的值表示这个零件比整体晚多久开始动、早多久结束。比如delay 0.2意味着前 20% 的进度它不动然后在剩下的 80% 里完成移动。公式(eased - delay) / (1 - delay)就是把整体进度映射到零件的局部进度上。这个机制让爆炸可以有“由内到外依次绽放”的层次感比所有零件同时飞出去高级得多。第二为什么要遍历扁平数组而不是遍历场景树。场景树遍历每次都要递归调traverse还会碰到不需要动的节点开销大。扁平数组直接for循环性能最好而且可以和场景树的复杂度解耦。这个优化在零件数多的时候效果特别明显我的 47 个零件数组循环每帧耗时几乎可以忽略。第三position.lerpVectors会不会影响scale和rotation。不会。它只改position。所以如果你的模型在加载时有别的变换不受影响。这也是为什么坚持只动位置的原因之一。4.3 渲染循环与控制状态机光有applyExplode还不够还需要一个循环在动画期间持续调用它。我用了一个通用的补间驱动let progress 0; // 当前进度 let targetProgress 0; // 目标进度 let isAnimating false; function tick() { requestAnimationFrame(tick); if (isAnimating) { const diff targetProgress - progress; if (Math.abs(diff) 0.001) { progress targetProgress; isAnimating false; } else { progress diff * 0.12; // 指数逼近 } applyExplode(progress); } renderer.render(scene, camera); }这里的补间策略是指数逼近每帧把当前进度向目标进度靠近 12%。好处是正反向都能用同一套逻辑不管你要展开还是收拢只管改targetProgress剩下的自动完成。而且中途改变目标比如展开到一半又点收拢会自然平滑地转向不会突兀跳变。0.12这个系数控制速度。太小了慢吞吞太大了像瞬移。经验值 0.08 到 0.18 之间。想更精确控制时长的话可以换成基于时间的插值但要处理时间戳和暂停复杂度上升。展示类项目用指数逼近足够了。控制层的按钮逻辑就非常简单了btn.addEventListener(click, () { targetProgress targetProgress 0.5 ? 0 : 1; isAnimating true; });两行搞定展开和收拢的切换。这就是单一进度值架构的好处。提示如果你的项目需要“爆开比例 0% 到 100% 实时拖动”直接把 slider 的值除以 100 赋给 targetProgressisAnimating true都不需要因为拖动事件本身就会触发重渲染。但为了兼容其他交互建议还是统一走 tick 循环。5. 进阶效果与性能优化5.1 让爆炸更有层次的三个技巧基础的爆炸做完后我加了几个小效果观感提升明显。第一个是错峰延迟。前面提到的delay参数我按零件到中心的距离来分配越靠外的零件延迟越小先动越靠内的延迟越大。这样看起来像花从中心绽开或者反过来收缩。实现就是在收集阶段加一句item.delay (1 - dist / maxDistance) * 0.3;整体延迟范围 0 到 0.3即最慢的零件在前 30% 进度里保持不动。范围不能太大超过 0.5 会感觉“怎么还不齐”。第二个是高光扫描。爆炸过程中给零件加一点emissive发光或者用描边效果突出正在移动的零件。这个需要改材质注意要 clone 材质再改直接改会污染共享材质导致所有同材质零件一起亮。Three.js 里很多导出模型是共用材质的这个坑非常常见。第三个是相机微动。爆炸的时候相机稍微拉远一点点给零件留出空间同时能中和“模型突然变大”的错觉。我在 tick 里加了个相机距离的插值跟随 progress 变化幅度很小大概 10%但效果好。5.2 性能上的具体数字和优化零件少的时候怎么写都行零件多了就得抠。我实测过一组数据同一台测试机中端安卓机Chrome47 个零件的场景优化项每帧耗时说明遍历场景树改位置2.1ms递归开销 无效节点遍历扁平数组改位置0.3ms只遍历需要的节点每个零件独立 Tween4.5ms多时间线管理开销单一进度值驱动0.4ms一次计算全局进度数据不一定严谨但趋势很明显扁平数组 单一进度值是最省的路。差了一个数量级。除了这个还有几个优化点值得说。合并几何体。如果有些零件永远一起动比如螺丝和它的垫片可以在预处理阶段用BufferGeometryUtils.mergeGeometries把它们合并成一个 mesh。这样零件数直接减少遍历开销和 draw call 都降。代价是失去单独控制能力所以要看需求。按需渲染。Three.js 默认每帧都渲染哪怕场景没变化。展示页长时间挂着很浪费。可以加一个“脏标记”只有动画中或有交互时才渲染。实现就是在 tick 里判断isAnimating || needsRender否则跳过renderer.render。这个改动对移动端续航和发热帮助很大。function tick() { requestAnimationFrame(tick); if (isAnimating) { // ... 更新进度和位置 needsRender true; } if (needsRender) { renderer.render(scene, camera); needsRender false; } }限制像素比。高分屏上devicePixelRatio可能是 3等于渲染 9 倍的像素。展示页完全没必要。我一般设Math.min(window.devicePixelRatio, 2)视觉上和 3 差别很小性能翻倍。5.3 移动端和响应式的注意事项移动端做这个功能有几件事必须处理。触摸事件和点击事件的冲突。如果同时绑了click和touchstart移动端会触发两次。解决办法是统一用pointerdown或者只在click里处理并加防抖。我吃过这个亏按钮一点就展开又立刻收拢查了半天是重复触发。模型面数要控制。展示用的模型最好在 Blender 里做一次减面把总面数控制在一百万三角面以内。工业模型动辄几百万面手机上直接卡死。如果模型来自 CAD 导出通常面数夸张减面是必须的。加载进度要可见。大模型加载可能十几秒没有进度提示用户以为页面挂了。用GLTFLoader的onProgress回调显示进度条体验差别很大。内存要释放。组件卸载时记得dispose几何体和材质从场景里移除。SPA 里反复切换页面不释放内存会一路涨。function disposeModel(model) { model.traverse((child) { if (child.isMesh) { child.geometry.dispose(); if (Array.isArray(child.material)) { child.material.forEach((m) m.dispose()); } else { child.material.dispose(); } } }); }6. 踩坑记录与排查速查6.1 我实际遇到过的六个典型问题问题一爆炸后收不回去。原因就是前面提的originPos存了引用而非副本。排查方法打印零件的originPos和初始位置对比如果动画后两者都变了就是这个问题。修复就是用.clone()。问题二零件飞向奇怪方向。三个可能原因。一是模型未居中中心点算错二是零件在父节点下有变换局部坐标和世界坐标不一致三是某些零件恰好位于中心方向向量是零向量normalize后变成 NaN。修复分别是先居中、用世界坐标算方向、跳过距离小于阈值的零件。问题三部分零件不动。检查是不是被过滤掉了。我的过滤条件是isMesh如果某个零件是Points或Line或者几何体为空就会被跳过。按需放宽条件。问题四动画卡顿。先看是不是每帧遍历场景树了再看是不是每个零件独立 Tween。还要检查有没有在动画中重建材质或几何体。最容易被忽略的是在 tick 里创建新对象比如每帧new THREE.Vector3()会产生垃圾回收压力。所有向量都该预分配复用。问题五模型发黑或材质错乱。多半是材质共享问题。改一个零件的颜色结果所有用同材质的都变了。解决是改之前material.clone()。但注意 clone 会增加内存别滥用。问题六移动端触摸拖动旋转时误触发爆炸。这是交互冲突。给OrbitControls的旋转和模型的拖拽区分手势或者用长按、双击触发爆炸不要用单击。6.2 排查速查表现象最可能原因快速验证解决收不回去originPos 存了引用打印 originPos 和 position用 clone()方向乱飞模型未居中 / 坐标不一致打印包围盒中心先居中再算方向零件 NaN 位置零向量 normalize打印方向向量跳过中心零件动画卡顿遍历场景树 / 每帧 new用 Performance 面板看扁平数组 预分配材质串色共享材质被改检查 material.uuidclone 后再改点击重复触发click touch 都绑了打日志看触发次数统一用 pointerdown移动端模糊devicePixelRatio 过高看 canvas 尺寸限制到 26.3 独家避坑经验几个文档里不会写、但实际项目里特别重要的点。导出模型时勾选“应用修改器”和“保留层级”。Blender 导出 glTF 时有个选项会把所有变换烘焙进网格有时候方便有时候麻烦。如果你要做爆炸分解保留层级和独立变换是对的否则零件位置信息丢了就没法单独移动。测试模型不要用最终模型。最终模型可能几百 MB开发阶段每次改代码重新加载太痛苦。我是先用一个几十 KB 的简化模型几个方块、圆柱拼的把逻辑跑通最后一天再换真模型调试。这个习惯让我开发效率翻了一倍。给爆炸系数留个运行时调参入口。我在开发时加了个lil-gui面板滑杆调爆炸距离、缓动速度、延迟范围。调完记下最佳值写死。没有这个我可能要改几十次代码重新加载页面。动画期间禁用交互。零件正在飞的时候如果用户又点按钮状态会打架。我的做法是动画中把按钮置灰或者直接用状态机拒绝新指令。注意不是简单的if (isAnimating) return因为你可能希望中途反向要区分“完成中”和“进行中”。相机near和far要匹配模型尺寸。模型如果很大默认的near 0.1、far 2000会导致深度精度问题或模型被裁掉。加载后根据包围盒动态设这两值能省很多莫名其妙的显示问题。最后的体会是爆炸分解这个效果本身技术含量不算高难的是工程化——把它做成一个能适应不同模型、能响应各种交互、性能还过得去的东西。真正花时间的地方是模型预处理和边界情况处理写核心动画的那几十行反而是最快的。如果你也在做类似的功能我的建议是先想清楚“进度值驱动”这个架构然后花大力气在数据层的收集和预处理上后面会省很多事。