1. 这期圈子里最值得跟进的三个动向Three.js 今日案例热点185期这两天圈子里讨论最多的是几个和版本、渲染底层相关的消息。很多人可能还停留在“Three.js 就是WebGL的封装库”这个印象里但这期的热点几乎都在讲同一件事新渲染管线、新版本升级、以及一批用新特性砸出来的视觉效果案例。看完这期热门案例我的感受是如果你还在用几年前的写法怼业务现在确实是一个需要停下来梳理技术栈的时间点。第一个动向是WebGPU渲染器开始真正进入可用阶段。之前WebGPU一直处于“能跑Demo但没法上生产”的状态但最近几期案例里已经出现了基于WebGPURenderer的复杂场景包括粒子系统、后处理链、大范围模型实例化帧数和画质都比同级别WebGL场景有明显提升。当然离全面替换WebGL还差得远——兼容性、材质适配、生态工具链都还在追赶可方向已经非常明确了。第二个动向是R150版本之后颜色管理和光照行为发生了根本性变化。这个变化看起来很不起眼但直接影响你项目里的每一个材质颜色、每一盏灯的亮度。很多人在升级Three.js版本后突然发现场景变暗了、颜色变灰了不是代码写错了而是默认色彩空间和光照计算方式变了。这一期热点里好几个案例都在反复强调“升级之后不要还按老思路调曝光”。第三个动向是案例风格开始从“炫技”转向“业务落地”。这期热门的几个案例不再只是转个圈、飘个粒子而是实打实的品牌产品页、数字孪生场景、可视化大屏。它们普遍采用的技术组合是GLTF模型压缩加载、InstancedMesh大量复用、精细的后处理调色、移动端动态分辨率。这些不是花架子是真正能扛住线上用户访问的方案。1.1 先搞懂WebGPU渲染器到底改变了什么WebGPU不是Three.js搞出来的新花样而是一套全新的Web图形API标准定位是取代老旧的WebGL。以前WebGL的渲染流程是把数据交给GPU然后一路走固定管线很多操作你控制不了。WebGPU更像是让你直接面对GPU能力本身你可以自己管理缓冲区、渲染通道、资源绑定不需要给GPU换着花样喂数据。用生活类比来说WebGL像是一个只提供固定套餐的食堂你只能在既定窗口里选菜WebGPU则是给你一个开放厨房锅碗瓢盆都摆出来了想怎么组合都可以。对应到Three.js上就是新增的WebGPURenderer替代了原来的WebGLRenderer它内部走的是WebGPU管线能和现代GPU架构更好地贴合。实际接入时非常简单import * as THREE from three; import WebGPURenderer from three/webgpu; const renderer new WebGPURenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); document.body.appendChild(renderer.domElement);看着和WebGLRenderer差不多但背后的资源管理逻辑完全不同。最直观的差异是很多老的材质扩展库不兼容比如你过去常用的某些后处理插件、某些自定义ShaderMaterial写法在WebGPU模式下可能要重写。不过Three.js官方一直在推TSLThree Shading Language让材质节点化写法能够跨WebGL和WebGPU。这期的案例里不少已经改成TSL写法了代码看起来更像在搭积木。我自己的建议是线上项目除非你有充足时间踩坑否则先别盲目切WebGPU但新项目、个人实验、Demo验证可以大胆用。平时学习时尽量把TSL的写法熟悉起来别等生态成熟了才临时抱佛脚。1.2 从R152到R160升级必踩的三个API换名这期案例讨论中有三个API更名出现频率最高基本属于升级必踩。第一个是颜色空间相关的配置。旧写法是用renderer.outputEncoding THREE.sRGBEncoding从R152开始被废弃要改成renderer.outputColorSpace THREE.SRGBColorSpace;如果你用到纹理还需要注意纹理本身的色彩空间。过去很多人的贴图发暗、偏灰根源就是纹理加载后没有设置texture.colorSpace THREE.SRGBColorSpace。新版里的默认行为更接近物理正确但前提是你得把SRGB纹理标记清楚。第二个是光照模式的改变。R155之后renderer.useLegacyLights默认值改成了false这意味着光照计算不再沿用老的“近似物理”模型而是走新的物理光照模型。最明显的感受是同样的灯光参数场景明显变暗了因为新模型里光的能量衰减更真实。老项目升级后如果发现“灯光不够亮”不要直接堆灯光强度先确认useLegacyLights是否还是false然后按物理单位重新调参数。第三个是BufferGeometry相关API的命名调整。BufferGeometry本身还在但很多几何体辅助方法有了变化例如geometry.computeBoundingSphere在某些调用时机下可能不再自动触发。这个坑比较隐蔽通常表现为“模型一部分看不见了”或者“包围盒计算错误”。升级后最好跑一遍场景中的renderer.compile相关流程确保几何体信息完整。2. 案例拆解一个镜面粒子形变Demo是怎么复现出来的这期热度最高的一个案例是镜面粒子形变粒子先拼成一段文字然后像水波一样散开重新聚合成另一个图形鼠标扫过时粒子会跟随指针轻微流动。整体视觉非常干净浅景深模糊背景粒子自带金属拉丝质感。很多人在评论里问效果是怎么做的其实拆开看核心就是四个部分字形采样、粒子定位、噪声位移、后期虚化。我先说思路。字形采样用的是Canvas画文字然后读取像素信息const canvas document.createElement(canvas); const ctx canvas.getContext(2d); ctx.font bold 120px Arial; ctx.fillText(185, 0, 120); const imgData ctx.getImageData(0, 0, canvas.width, canvas.height); const positions []; for (let y 0; y canvas.height; y 4) { for (let x 0; x canvas.width; x 4) { if (imgData.data[(y * canvas.width x) * 4 3] 128) { positions.push(x, y, 0); } } }这段代码的原理是遍历画布像素把不透明的地方当成粒子锚点。x 4和y 4的步长决定了粒子密度步长越大粒子越稀疏。如果你想要更密的粒子可以改成 2但粒子数量会变成四倍GPU压力直线上升。这个案例里最终大概用了3万多个粒子配合ShaderMaterial跑起来压力不大。然后是把定位好的粒子放进BufferGeometryconst geometry new THREE.BufferGeometry(); geometry.setAttribute(position, new THREE.Float32BufferAttribute(positions, 3));核心逻辑在ShaderMaterial里。每个粒子的位置不是静态的而是根据时间和噪声函数偏移// 顶点着色器片段 uniform float uTime; uniform float uProgress; uniform vec2 uMouse; void main() { vec3 pos position; // 按进度把粒子从文字状态推向随机散开状态 vec3 randomDir random(pos.xy) * 400.0; pos mix(pos, randomDir, uProgress); // 加入噪声波动 float wave sin(pos.x * 0.05 uTime * 2.0) * cos(pos.y * 0.05 uTime * 1.5); pos.z wave * 30.0; // 鼠标影响 float dist distance(pos.xy, uMouse); pos.z sin(dist * 0.1 - uTime * 4.0) * 15.0; vec4 mvPosition modelViewMatrix * vec4(pos, 1.0); gl_PointSize (300.0 / -mvPosition.z) * 1.5; gl_Position projectionMatrix * mvPosition; }里面用到的random()函数其实就是一段伪随机算法目的是让每个粒子有一个固定的、可复现的偏移量。这样当uProgress从0变化到1时粒子可以平滑地从文字状态变成漂浮的云团状。核心的动画过渡就是靠这个mix函数完成的。2.1 核心变量与材质参数逐个讲如果你要复现这个效果建议先从一个静态的文字粒子开始确认字形采样没问题了再慢慢加运动和后期。先说要留意的几个材质参数。ShaderMaterial通常需要自己处理透明度尤其粒子系统深度写入必须关掉否则粒子之间会互相遮挡产生难看的裁切const material new THREE.ShaderMaterial({ uniforms: { uTime: { value: 0 }, uProgress: { value: 0 }, uMouse: { value: new THREE.Vector2(0, 0) }, uTexture: { value: circleTexture } }, vertexShader: vertexShaderText, fragmentShader: fragmentShaderText, transparent: true, depthWrite: false, blending: THREE.AdditiveBlending });depthWrite: false一定要写。粒子本身是大量半透明点的集合如果不关深度写入后面的粒子会被前面的粒子挡住视觉上会出现很多残缺的缺口整个形态会显得很碎。AdditiveBlending是另一个选择。这种混合模式会让粒子颜色叠加变亮适合做发光、星空这类效果。但如果是镜面金属质感用加法混合容易过曝反而丢失细节。原案例里用的是正常混合再加上一张圆形渐变纹理让粒子边缘柔和过渡。我用下来发现圆形纹理的深浅直接影响最终观感纹理太实的话粒子变成小圆片太虚的话粒子像烟雾。圆点纹理可以用Canvas生成不用额外加载图片const canvas document.createElement(canvas); canvas.width 64; canvas.height 64; const ctx canvas.getContext(2d); const gradient ctx.createRadialGradient(32, 32, 0, 32, 32, 32); gradient.addColorStop(0, rgba(255,255,255,1)); gradient.addColorStop(1, rgba(255,255,255,0)); ctx.fillStyle gradient; ctx.fillRect(0, 0, 64, 64); const circleTexture new THREE.CanvasTexture(canvas);片元着色器里直接乘上这个纹理的alpha值粒子的圆润感就出来了。gl_PointSize的公式也值得说。300.0 / -mvPosition.z是典型的透视缩放离相机越远粒子的屏幕尺寸越小。再乘一个系数控制整体大小。这个系数需要你根据场景尺寸调没有固定标准。如果你发现粒子太小像噪点就把系数往上加如果粒子像马赛克块就调低。射线交互部分用THREE.Raycaster把鼠标位置转换成世界坐标const raycaster new THREE.Raycaster(); const pointer new THREE.Vector2(); const mouseWorld new THREE.Vector3(); window.addEventListener(pointermove, (e) { pointer.x (e.clientX / window.innerWidth) * 2 - 1; pointer.y -(e.clientY / window.innerHeight) * 2 1; raycaster.setFromCamera(pointer, camera); const point raycaster.ray.at(1, mouseWorld); material.uniforms.uMouse.value.copy(point); });这里注意的是射线方向取相机到鼠标的射线在距离相机一定距离处取一个点作为粒子偏移的参考点。如果你的相机是透视相机这个点在场景中会随视距变化实现效果时要注意粒子的偏移幅度是否与视觉统一。2.2 为什么噪声运动用Simplex而不是Math.random很多初学粒子的人第一反应是用Math.random()生成偏移量但出来的效果通常是“抖”不是“流动”。原因是Math.random()产生的是白噪声每个粒子完全独立毫无空间连贯性。而Simplex噪声的特点是相邻位置的值是连续变化的空间上平滑过渡。就像风吹过麦田麦穗的运动不是每个都随机乱晃而是有波浪传播感的。所以粒子浮动的核心一定得是噪声函数。你可以直接用Three.js封装好的ImprovedNoise也可以自己实现一个简化版的3D噪声。我在这个Demo里用的是一个经典3D Simplex噪声实现在顶点着色器里采样noise(pos * frequency time * speed)就能让粒子像水波一样涌动。Shader里加入噪声后还有一个常见误区粒子位移逻辑放在JavaScript里做。三万多个粒子每个粒子在CPU里每帧更新坐标直接卡成PPT。正确做法是把位置计算全部丢给顶点着色器JavaScript只负责更新uTime、uProgress这些uniform变量。GPU是并行处理的几万粒子的坐标计算对它来说非常轻松。你可以在动画循环里这么写function animate() { requestAnimationFrame(animate); material.uniforms.uTime.value performance.now() / 1000; renderer.render(scene, camera); }performance.now() / 1000转成秒单位这样shader里的uTime就是连续递增的方便做时间相关的动画。如果你用Date.now()数值过大过细shader浮点数精度下降动画会出现不自然的跳变。3. 从热点案例里提炼的5条可复用优化清单看这期案例时我发现几个受欢迎的作品有一个共同点场面很大但跑起来很流畅。这类作品能上线当品牌页用不是靠电脑性能硬扛而是做了大量的优化。我从这些案例里提炼了五条可以直接复用的优化手段任何Three.js项目都适用。合并Draw Call能用InstancedMesh就不要一个个创建Mesh。InstancedMesh可以把同一几何体、同一种材质的多个实例合成一次绘制。比如场景里有1000棵树普通做法创建1000个Mesh产生1000次Draw Call用InstancedMesh的话一次Draw Call就能画完性能差距是数量级的。纹理和模型加载压缩GLTF模型如果带着大量高分辨率贴图加载会非常慢。建议用gltf-transform这类工具统一压缩模型网格该精简就精简纹理转成WebP或KTX2格式减小体积。Draco压缩能减小顶点数据体积但解压需要消耗CPU时间不要在低端机上无脑开最高压缩率。材质共享多个Mesh尽量复用同一个Material实例。材质对象创建和编译是有开销的材质数量多了Three.js需要维护大量的program和uniform绑定GPU切换状态也会变慢。如果只是颜色不同优先用顶点颜色或instanceColor而不是为每种颜色新建材质。阴影策略阴影是最耗性能的特性之一。不要给所有灯光开启阴影不要把所有物体都设为castShadow和receiveShadow。大场景里优先使用一张烘焙好的阴影贴图或者用低多边形代理物体来投射阴影。如果非要实时阴影控制shadow map的分辨率用256或512而不是无脑设2048。后处理通道合并很多效果需要多个后处理Pass叠加比如Bloom、景深、色彩校正。后处理每多一个Pass就多一次全屏纹理的读和写开销不小。能用EffectComposer里一个Pass搞定的效果就不要拆成两个。还有些效果可以用AreaLight和透明材质模拟不一定非得走后处理。3.1 移动端真正的性能瓶颈不在渲染在填充率与CPU我在复现这些案例时发现桌面端跑60帧到了手机端可能只有20帧。很多人第一反应是“换低端显卡”但实际上移动端真正的瓶颈往往不是GPU渲染三角形速度而是填充率和CPU端的每帧计算。填充率很好理解屏幕上的每个像素最终都要被像素着色器处理一遍。如果场景里有大量半透明叠加、全屏后期效果等于一个像素要反复被计算好几次这种开销叫Overdraw。移动端GPU的填充率和带宽有限Overdraw一高帧率骤降。解决办法之一是动态分辨率缩放。根据当前帧率调整renderer.setPixelRatiofunction adaptiveResolution() { const currentRatio renderer.getPixelRatio(); if (fps 30 currentRatio 1) { renderer.setPixelRatio(Math.max(1, currentRatio - 0.5)); } else if (fps 55 currentRatio Math.min(window.devicePixelRatio, 2)) { renderer.setPixelRatio(currentRatio 0.5); } }降低像素比等于用更少的像素渲染画面会略微模糊但对帧率的提升非常明显。品牌页这种场景里用户滑动过程中降低一点清晰度完全感知不出来滚动停止后再恢复高分辨率体验几乎无损。CPU端的瓶颈也要防。小心在动画循环里做几何体遍历、矩阵更新、包围盒计算这些操作。尤其是每帧都去调用mesh.position.set()不代表就高效真正高效的做法是只更新需要变化的那部分节点其他节点保持静态矩阵。很多轨迹动画用matrixAutoUpdate就够了不需要每帧手动更新所有物体。3.2 GLTF模型优化的菜鸟误区这期案例里有一个数字孪生场景里面放了一整套机房设备模型。模型文件原始大小接近200MB加载时浏览器直接卡住。很多人的第一反应是“上Draco压缩”但Draco只压缩网格顶点数据对贴图纹理无计可施。200MB里可能有150MB是贴图所以真正有效的优化是先把纹理压下来。我常用的流程是先跑一遍gltf-transformgltf-transform optimize model.glb model-optimized.glb --texture-compress webp --meshopt-compression这个工具会把纹理转成WebP格式同时用Meshopt压缩网格数据。实测下来200MB的模型能压到30MB左右加载速度提升非常明显。如果模型结构本身有问题比如包含几千个独立的节点、每个节点都带不同的材质还需要先用建模软件清理材质和节点合并。还有一个小细节GLTF里的动画采样通常是把烘焙好的关键帧全部保留文件体积不小。如果动画帧率原先是60fps可以转成30fps文件体积直接减半而且肉眼几乎看不出差别。很多数字孪生项目里的人物动画、设备旋转动画都可以这么压缩。4. 调试与排查这期案例中出现的5类报错与修复复现热点案例永远绕不开调试。这期我在验证几个案例代码时遇到了不少报错和诡异现象单独拉出来说说都是新手容易卡住的地方。4.1 黑屏、白屏常见的五个原因黑屏是Three.js新手遇到最多的问题几乎80%的情况出在下面几个环节第一画布没有尺寸。很多人初始化了WebGLRenderer但没设置renderer.setSize()或者CSS里画布高度为0结果就是什么都看不到。第二没有启动渲染循环。Three.js不像CSS动画自动播放只有调用renderer.render(scene, camera)才产生画面。第三相机摆放位置不对模型在相机背面或者相机穿模在模型内部。第四材质本身是黑色尤其是ShaderMaterial没写输出颜色只写了透明度。第五忘了加灯光用了MeshStandardMaterial但场景里没有光源物体就是全黑的。排查顺序我个人总结了一个口诀先看画布再看相机再看灯光最后看材质。基本上可以覆盖90%的黑屏问题。4.2 贴图发黑或不显示这期有好几个案例用了外部纹理贴图复现时发现贴图加载出来了但颜色特别黑。这是典型的色彩空间问题。Three.js在新版里物理渲染色彩空间是Linear而普通图片默认是sRGB需要显式标记const texture new THREE.TextureLoader().load(texture.jpg); texture.colorSpace THREE.SRGBColorSpace;如果不设置纹理被当作Linear数据参与光照计算结果就是亮度偏低、颜色失真。另外还要注意UV坐标很多从建模软件导出的模型UV没有问题但如果是在代码里动态生成的几何体比如BoxGeometry调整了分段数UV可能和你预期的不一样贴图会拉伸成奇怪的样子。贴图不显示的另一个常见原因是跨域。如果纹理放在CDN上且CDN没有返回正确的CORS头WebGL会出于安全策略拒绝使用纹理。解决办法是确保CDN配置了crossorigin头或者把纹理放到同域名下。4.3 动画抖动与载入跳变粒子平滑过渡时出现抖动多半是浮点精度问题。我在前面提到过时间戳用performance.now() / 1000是秒为单位这个数值在长时间运行后会变大导致Shader里计算出现精度损失。一个常见解法是取模material.uniforms.uTime.value (performance.now() % 100000) / 1000;另外GLTF动画如果包含多个动画片段播放时要注意动画权重。用AnimationMixer时如果两个动画没有正确淡入淡出切换瞬间会跳变。解决办法是在切换动画前先设置.fadeIn()和.fadeOut()不要直接action.play()。4.4 性能数字不准排查性能问题时很多人直接看renderer.info里的draw calls、triangles。这个数据在没有后处理时是很准的但一旦加了EffectComposerdraw calls数字会包含后处理Pass的绘制而且后期Pass是全屏四边形triangles会虚高。你看到“draw calls 50”的时候实际场景可能只有20个Draw Call其余都是后处理开销。想要精确分析场景本身的性能还是在浏览器DevTools的Performance面板里录制一段或者用SpectorJS捕捉WebGL命令逐帧看场景绘制信息和状态切换。这个工具能直接列出每一帧的Draw Call列表、绑定的纹理、Program切换次数排查性能问题比看笼统的数字高效得多。4.5 常见问题速查表现象可能原因解决方法画面全黑画布无尺寸/相机在模型内部/无灯光检查setSize、相机距离、场景灯光类型和强度贴图颜色发灰发暗纹理未设置SRGBColorSpace加载纹理后显式设置texture.colorSpace模型加载慢模型体积大、纹理未压缩用gltf-transform压缩纹理和网格粒子系统卡顿每帧在CPU更新粒子坐标把位移计算移到顶点着色器仅传uniform时间动画切换跳变未设置动画淡入淡出使用AnimationMixer的fadeIn/fadeOut后处理画面模糊像素比过高或Blur半径过大降低setPixelRatio或调小模糊半径阴影边缘锯齿严重Shadow Map分辨率不足调大shadow.mapSize或改用PCFSoft阴影模型局部闪烁深度冲突或面重叠检查几何体是否有重叠面调整camera near/far5. 实操体验从一个案例看整体工作流我不是光看案例就完事这期我挑了其中一个人物全息投影案例做了完整复现。全息投影算是一个不大但全面的场景外部模型、自发光材质、动态粒子、交互控制、后处理发光基本上涵盖了前面讲的所有技术点。完整流程是这样的先搭基础场景安装依赖和入口然后加载人物模型调整模型格式和材质接着做粒子环绕效果通过Shader控制粒子沿着人物轮廓运动再把Bloom后处理挂上让发光部位有光晕最后做鼠标旋转交互和加载进度。每一步都有对应的问题要处理。用到的技术选型是Vite Three.js RawShaderMaterial。之所以不选React项目直接写是因为这个场景不需要复杂状态管理纯Three.js足够。如果你要嵌套到React工程里建议把Three场景逻辑封装成一个独立的类避免组件重新渲染导致Canvas多次初始化。5.1 创作环境与工程搭建要点工程搭建很简单初始化一个Vite项目然后安装Three.jsnpm create vitelatest hologram-project -- --template vanilla cd hologram-project npm install threeThree.js的主入口文件建议直接从指定的模块路径引入不要引入整包import * as THREE from three; import { EffectComposer } from three/examples/jsm/postprocessing/EffectComposer.js; import { RenderPass } from three/examples/jsm/postprocessing/RenderPass.js; import { UnrealBloomPass } from three/examples/jsm/postprocessing/UnrealBloomPass.js;目录结构我会分成src/scene.js、src/effects.js、src/controls.js几个模块把场景构建、效果器、交互逻辑分开。项目小的时候看似没必要但当你调后处理参数或换模型时这种分离能让你少走很多弯路。5.2 从案例到落地最容易做的三个裁切案例能跑得漂亮不代表它能直接上线。我在把Demo转成可落地方案时通常会做三个裁切。一是性能预算裁切。热门案例里的粒子动辄十万后处理拉满光线追踪般的反射效果满天飞。真上线时品牌页首屏加载时间不能超过三秒手机上要稳住30帧。所以粒子数量砍到原来的三分之一后处理只保留一个UnrealBloomPass反射效果能用环境贴图替代就替代。二是交互复杂度裁切。案例为了演示效果会做很多复杂的鼠标交互、键盘快捷键、多视角切换。真实业务页面里用户只想快速浏览核心信息过度交互反而干扰。我通常只保留悬浮旋转、点击点击缩放这两个操作。三是资源体积裁切。模型压缩、纹理压缩、音频裁剪这些不能等上线前再做而是要在方案阶段就规划好。这里说的是一个长期有效的原则不要无脑把热门案例整段复制到业务里而是提取出适合业务的部分哪怕这个部分只用了案例里20%的技术点。能让项目跑起来并且跑得稳比把效果做满更重要。我个人这期实操下来最深的体会是Three.js已经过了那个“demo看起来很炫但业务不可用”的阶段。现在的新版本、新工具链让WebGL/WebGPU复杂场景逐渐有了生产级落地的可能性。但越是这样越不能只追新特性反而要更重视工程化、性能预算、资源压缩这些“不性感”的环节。你最终上线跑得稳靠的往往不是某个神奇的渲染魔法而是这些基础工作做到位了。最后再分享一个小技巧无论是调材质还是调后处理参数别在代码里反复改数值然后刷新页面。用dat.GUI或lil-gui把参数暴露到面板上实时滑动调整。等你调出满意的效果后再固化到代码里。比起盲改刷新效率能高出一个量级。 
长河君 · 2026/10/14 8:52:36 · 阅读 1.2k Three.js进阶：WebGPU渲染器、粒子系统与性能优化
1. 这期圈子里最值得跟进的三个动向Three.js 今日案例热点185期这两天圈子里讨论最多的是几个和版本、渲染底层相关的消息。很多人可能还停留在“Three.js 就是WebGL的封装库”这个印象里但这期的热点几乎都在讲同一件事新渲染管线、新版本升级、以及一批用新特性砸出来的视觉效果案例。看完这期热门案例我的感受是如果你还在用几年前的写法怼业务现在确实是一个需要停下来梳理技术栈的时间点。第一个动向是WebGPU渲染器开始真正进入可用阶段。之前WebGPU一直处于“能跑Demo但没法上生产”的状态但最近几期案例里已经出现了基于WebGPURenderer的复杂场景包括粒子系统、后处理链、大范围模型实例化帧数和画质都比同级别WebGL场景有明显提升。当然离全面替换WebGL还差得远——兼容性、材质适配、生态工具链都还在追赶可方向已经非常明确了。第二个动向是R150版本之后颜色管理和光照行为发生了根本性变化。这个变化看起来很不起眼但直接影响你项目里的每一个材质颜色、每一盏灯的亮度。很多人在升级Three.js版本后突然发现场景变暗了、颜色变灰了不是代码写错了而是默认色彩空间和光照计算方式变了。这一期热点里好几个案例都在反复强调“升级之后不要还按老思路调曝光”。第三个动向是案例风格开始从“炫技”转向“业务落地”。这期热门的几个案例不再只是转个圈、飘个粒子而是实打实的品牌产品页、数字孪生场景、可视化大屏。它们普遍采用的技术组合是GLTF模型压缩加载、InstancedMesh大量复用、精细的后处理调色、移动端动态分辨率。这些不是花架子是真正能扛住线上用户访问的方案。1.1 先搞懂WebGPU渲染器到底改变了什么WebGPU不是Three.js搞出来的新花样而是一套全新的Web图形API标准定位是取代老旧的WebGL。以前WebGL的渲染流程是把数据交给GPU然后一路走固定管线很多操作你控制不了。WebGPU更像是让你直接面对GPU能力本身你可以自己管理缓冲区、渲染通道、资源绑定不需要给GPU换着花样喂数据。用生活类比来说WebGL像是一个只提供固定套餐的食堂你只能在既定窗口里选菜WebGPU则是给你一个开放厨房锅碗瓢盆都摆出来了想怎么组合都可以。对应到Three.js上就是新增的WebGPURenderer替代了原来的WebGLRenderer它内部走的是WebGPU管线能和现代GPU架构更好地贴合。实际接入时非常简单import * as THREE from three; import WebGPURenderer from three/webgpu; const renderer new WebGPURenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); document.body.appendChild(renderer.domElement);看着和WebGLRenderer差不多但背后的资源管理逻辑完全不同。最直观的差异是很多老的材质扩展库不兼容比如你过去常用的某些后处理插件、某些自定义ShaderMaterial写法在WebGPU模式下可能要重写。不过Three.js官方一直在推TSLThree Shading Language让材质节点化写法能够跨WebGL和WebGPU。这期的案例里不少已经改成TSL写法了代码看起来更像在搭积木。我自己的建议是线上项目除非你有充足时间踩坑否则先别盲目切WebGPU但新项目、个人实验、Demo验证可以大胆用。平时学习时尽量把TSL的写法熟悉起来别等生态成熟了才临时抱佛脚。1.2 从R152到R160升级必踩的三个API换名这期案例讨论中有三个API更名出现频率最高基本属于升级必踩。第一个是颜色空间相关的配置。旧写法是用renderer.outputEncoding THREE.sRGBEncoding从R152开始被废弃要改成renderer.outputColorSpace THREE.SRGBColorSpace;如果你用到纹理还需要注意纹理本身的色彩空间。过去很多人的贴图发暗、偏灰根源就是纹理加载后没有设置texture.colorSpace THREE.SRGBColorSpace。新版里的默认行为更接近物理正确但前提是你得把SRGB纹理标记清楚。第二个是光照模式的改变。R155之后renderer.useLegacyLights默认值改成了false这意味着光照计算不再沿用老的“近似物理”模型而是走新的物理光照模型。最明显的感受是同样的灯光参数场景明显变暗了因为新模型里光的能量衰减更真实。老项目升级后如果发现“灯光不够亮”不要直接堆灯光强度先确认useLegacyLights是否还是false然后按物理单位重新调参数。第三个是BufferGeometry相关API的命名调整。BufferGeometry本身还在但很多几何体辅助方法有了变化例如geometry.computeBoundingSphere在某些调用时机下可能不再自动触发。这个坑比较隐蔽通常表现为“模型一部分看不见了”或者“包围盒计算错误”。升级后最好跑一遍场景中的renderer.compile相关流程确保几何体信息完整。2. 案例拆解一个镜面粒子形变Demo是怎么复现出来的这期热度最高的一个案例是镜面粒子形变粒子先拼成一段文字然后像水波一样散开重新聚合成另一个图形鼠标扫过时粒子会跟随指针轻微流动。整体视觉非常干净浅景深模糊背景粒子自带金属拉丝质感。很多人在评论里问效果是怎么做的其实拆开看核心就是四个部分字形采样、粒子定位、噪声位移、后期虚化。我先说思路。字形采样用的是Canvas画文字然后读取像素信息const canvas document.createElement(canvas); const ctx canvas.getContext(2d); ctx.font bold 120px Arial; ctx.fillText(185, 0, 120); const imgData ctx.getImageData(0, 0, canvas.width, canvas.height); const positions []; for (let y 0; y canvas.height; y 4) { for (let x 0; x canvas.width; x 4) { if (imgData.data[(y * canvas.width x) * 4 3] 128) { positions.push(x, y, 0); } } }这段代码的原理是遍历画布像素把不透明的地方当成粒子锚点。x 4和y 4的步长决定了粒子密度步长越大粒子越稀疏。如果你想要更密的粒子可以改成 2但粒子数量会变成四倍GPU压力直线上升。这个案例里最终大概用了3万多个粒子配合ShaderMaterial跑起来压力不大。然后是把定位好的粒子放进BufferGeometryconst geometry new THREE.BufferGeometry(); geometry.setAttribute(position, new THREE.Float32BufferAttribute(positions, 3));核心逻辑在ShaderMaterial里。每个粒子的位置不是静态的而是根据时间和噪声函数偏移// 顶点着色器片段 uniform float uTime; uniform float uProgress; uniform vec2 uMouse; void main() { vec3 pos position; // 按进度把粒子从文字状态推向随机散开状态 vec3 randomDir random(pos.xy) * 400.0; pos mix(pos, randomDir, uProgress); // 加入噪声波动 float wave sin(pos.x * 0.05 uTime * 2.0) * cos(pos.y * 0.05 uTime * 1.5); pos.z wave * 30.0; // 鼠标影响 float dist distance(pos.xy, uMouse); pos.z sin(dist * 0.1 - uTime * 4.0) * 15.0; vec4 mvPosition modelViewMatrix * vec4(pos, 1.0); gl_PointSize (300.0 / -mvPosition.z) * 1.5; gl_Position projectionMatrix * mvPosition; }里面用到的random()函数其实就是一段伪随机算法目的是让每个粒子有一个固定的、可复现的偏移量。这样当uProgress从0变化到1时粒子可以平滑地从文字状态变成漂浮的云团状。核心的动画过渡就是靠这个mix函数完成的。2.1 核心变量与材质参数逐个讲如果你要复现这个效果建议先从一个静态的文字粒子开始确认字形采样没问题了再慢慢加运动和后期。先说要留意的几个材质参数。ShaderMaterial通常需要自己处理透明度尤其粒子系统深度写入必须关掉否则粒子之间会互相遮挡产生难看的裁切const material new THREE.ShaderMaterial({ uniforms: { uTime: { value: 0 }, uProgress: { value: 0 }, uMouse: { value: new THREE.Vector2(0, 0) }, uTexture: { value: circleTexture } }, vertexShader: vertexShaderText, fragmentShader: fragmentShaderText, transparent: true, depthWrite: false, blending: THREE.AdditiveBlending });depthWrite: false一定要写。粒子本身是大量半透明点的集合如果不关深度写入后面的粒子会被前面的粒子挡住视觉上会出现很多残缺的缺口整个形态会显得很碎。AdditiveBlending是另一个选择。这种混合模式会让粒子颜色叠加变亮适合做发光、星空这类效果。但如果是镜面金属质感用加法混合容易过曝反而丢失细节。原案例里用的是正常混合再加上一张圆形渐变纹理让粒子边缘柔和过渡。我用下来发现圆形纹理的深浅直接影响最终观感纹理太实的话粒子变成小圆片太虚的话粒子像烟雾。圆点纹理可以用Canvas生成不用额外加载图片const canvas document.createElement(canvas); canvas.width 64; canvas.height 64; const ctx canvas.getContext(2d); const gradient ctx.createRadialGradient(32, 32, 0, 32, 32, 32); gradient.addColorStop(0, rgba(255,255,255,1)); gradient.addColorStop(1, rgba(255,255,255,0)); ctx.fillStyle gradient; ctx.fillRect(0, 0, 64, 64); const circleTexture new THREE.CanvasTexture(canvas);片元着色器里直接乘上这个纹理的alpha值粒子的圆润感就出来了。gl_PointSize的公式也值得说。300.0 / -mvPosition.z是典型的透视缩放离相机越远粒子的屏幕尺寸越小。再乘一个系数控制整体大小。这个系数需要你根据场景尺寸调没有固定标准。如果你发现粒子太小像噪点就把系数往上加如果粒子像马赛克块就调低。射线交互部分用THREE.Raycaster把鼠标位置转换成世界坐标const raycaster new THREE.Raycaster(); const pointer new THREE.Vector2(); const mouseWorld new THREE.Vector3(); window.addEventListener(pointermove, (e) { pointer.x (e.clientX / window.innerWidth) * 2 - 1; pointer.y -(e.clientY / window.innerHeight) * 2 1; raycaster.setFromCamera(pointer, camera); const point raycaster.ray.at(1, mouseWorld); material.uniforms.uMouse.value.copy(point); });这里注意的是射线方向取相机到鼠标的射线在距离相机一定距离处取一个点作为粒子偏移的参考点。如果你的相机是透视相机这个点在场景中会随视距变化实现效果时要注意粒子的偏移幅度是否与视觉统一。2.2 为什么噪声运动用Simplex而不是Math.random很多初学粒子的人第一反应是用Math.random()生成偏移量但出来的效果通常是“抖”不是“流动”。原因是Math.random()产生的是白噪声每个粒子完全独立毫无空间连贯性。而Simplex噪声的特点是相邻位置的值是连续变化的空间上平滑过渡。就像风吹过麦田麦穗的运动不是每个都随机乱晃而是有波浪传播感的。所以粒子浮动的核心一定得是噪声函数。你可以直接用Three.js封装好的ImprovedNoise也可以自己实现一个简化版的3D噪声。我在这个Demo里用的是一个经典3D Simplex噪声实现在顶点着色器里采样noise(pos * frequency time * speed)就能让粒子像水波一样涌动。Shader里加入噪声后还有一个常见误区粒子位移逻辑放在JavaScript里做。三万多个粒子每个粒子在CPU里每帧更新坐标直接卡成PPT。正确做法是把位置计算全部丢给顶点着色器JavaScript只负责更新uTime、uProgress这些uniform变量。GPU是并行处理的几万粒子的坐标计算对它来说非常轻松。你可以在动画循环里这么写function animate() { requestAnimationFrame(animate); material.uniforms.uTime.value performance.now() / 1000; renderer.render(scene, camera); }performance.now() / 1000转成秒单位这样shader里的uTime就是连续递增的方便做时间相关的动画。如果你用Date.now()数值过大过细shader浮点数精度下降动画会出现不自然的跳变。3. 从热点案例里提炼的5条可复用优化清单看这期案例时我发现几个受欢迎的作品有一个共同点场面很大但跑起来很流畅。这类作品能上线当品牌页用不是靠电脑性能硬扛而是做了大量的优化。我从这些案例里提炼了五条可以直接复用的优化手段任何Three.js项目都适用。合并Draw Call能用InstancedMesh就不要一个个创建Mesh。InstancedMesh可以把同一几何体、同一种材质的多个实例合成一次绘制。比如场景里有1000棵树普通做法创建1000个Mesh产生1000次Draw Call用InstancedMesh的话一次Draw Call就能画完性能差距是数量级的。纹理和模型加载压缩GLTF模型如果带着大量高分辨率贴图加载会非常慢。建议用gltf-transform这类工具统一压缩模型网格该精简就精简纹理转成WebP或KTX2格式减小体积。Draco压缩能减小顶点数据体积但解压需要消耗CPU时间不要在低端机上无脑开最高压缩率。材质共享多个Mesh尽量复用同一个Material实例。材质对象创建和编译是有开销的材质数量多了Three.js需要维护大量的program和uniform绑定GPU切换状态也会变慢。如果只是颜色不同优先用顶点颜色或instanceColor而不是为每种颜色新建材质。阴影策略阴影是最耗性能的特性之一。不要给所有灯光开启阴影不要把所有物体都设为castShadow和receiveShadow。大场景里优先使用一张烘焙好的阴影贴图或者用低多边形代理物体来投射阴影。如果非要实时阴影控制shadow map的分辨率用256或512而不是无脑设2048。后处理通道合并很多效果需要多个后处理Pass叠加比如Bloom、景深、色彩校正。后处理每多一个Pass就多一次全屏纹理的读和写开销不小。能用EffectComposer里一个Pass搞定的效果就不要拆成两个。还有些效果可以用AreaLight和透明材质模拟不一定非得走后处理。3.1 移动端真正的性能瓶颈不在渲染在填充率与CPU我在复现这些案例时发现桌面端跑60帧到了手机端可能只有20帧。很多人第一反应是“换低端显卡”但实际上移动端真正的瓶颈往往不是GPU渲染三角形速度而是填充率和CPU端的每帧计算。填充率很好理解屏幕上的每个像素最终都要被像素着色器处理一遍。如果场景里有大量半透明叠加、全屏后期效果等于一个像素要反复被计算好几次这种开销叫Overdraw。移动端GPU的填充率和带宽有限Overdraw一高帧率骤降。解决办法之一是动态分辨率缩放。根据当前帧率调整renderer.setPixelRatiofunction adaptiveResolution() { const currentRatio renderer.getPixelRatio(); if (fps 30 currentRatio 1) { renderer.setPixelRatio(Math.max(1, currentRatio - 0.5)); } else if (fps 55 currentRatio Math.min(window.devicePixelRatio, 2)) { renderer.setPixelRatio(currentRatio 0.5); } }降低像素比等于用更少的像素渲染画面会略微模糊但对帧率的提升非常明显。品牌页这种场景里用户滑动过程中降低一点清晰度完全感知不出来滚动停止后再恢复高分辨率体验几乎无损。CPU端的瓶颈也要防。小心在动画循环里做几何体遍历、矩阵更新、包围盒计算这些操作。尤其是每帧都去调用mesh.position.set()不代表就高效真正高效的做法是只更新需要变化的那部分节点其他节点保持静态矩阵。很多轨迹动画用matrixAutoUpdate就够了不需要每帧手动更新所有物体。3.2 GLTF模型优化的菜鸟误区这期案例里有一个数字孪生场景里面放了一整套机房设备模型。模型文件原始大小接近200MB加载时浏览器直接卡住。很多人的第一反应是“上Draco压缩”但Draco只压缩网格顶点数据对贴图纹理无计可施。200MB里可能有150MB是贴图所以真正有效的优化是先把纹理压下来。我常用的流程是先跑一遍gltf-transformgltf-transform optimize model.glb model-optimized.glb --texture-compress webp --meshopt-compression这个工具会把纹理转成WebP格式同时用Meshopt压缩网格数据。实测下来200MB的模型能压到30MB左右加载速度提升非常明显。如果模型结构本身有问题比如包含几千个独立的节点、每个节点都带不同的材质还需要先用建模软件清理材质和节点合并。还有一个小细节GLTF里的动画采样通常是把烘焙好的关键帧全部保留文件体积不小。如果动画帧率原先是60fps可以转成30fps文件体积直接减半而且肉眼几乎看不出差别。很多数字孪生项目里的人物动画、设备旋转动画都可以这么压缩。4. 调试与排查这期案例中出现的5类报错与修复复现热点案例永远绕不开调试。这期我在验证几个案例代码时遇到了不少报错和诡异现象单独拉出来说说都是新手容易卡住的地方。4.1 黑屏、白屏常见的五个原因黑屏是Three.js新手遇到最多的问题几乎80%的情况出在下面几个环节第一画布没有尺寸。很多人初始化了WebGLRenderer但没设置renderer.setSize()或者CSS里画布高度为0结果就是什么都看不到。第二没有启动渲染循环。Three.js不像CSS动画自动播放只有调用renderer.render(scene, camera)才产生画面。第三相机摆放位置不对模型在相机背面或者相机穿模在模型内部。第四材质本身是黑色尤其是ShaderMaterial没写输出颜色只写了透明度。第五忘了加灯光用了MeshStandardMaterial但场景里没有光源物体就是全黑的。排查顺序我个人总结了一个口诀先看画布再看相机再看灯光最后看材质。基本上可以覆盖90%的黑屏问题。4.2 贴图发黑或不显示这期有好几个案例用了外部纹理贴图复现时发现贴图加载出来了但颜色特别黑。这是典型的色彩空间问题。Three.js在新版里物理渲染色彩空间是Linear而普通图片默认是sRGB需要显式标记const texture new THREE.TextureLoader().load(texture.jpg); texture.colorSpace THREE.SRGBColorSpace;如果不设置纹理被当作Linear数据参与光照计算结果就是亮度偏低、颜色失真。另外还要注意UV坐标很多从建模软件导出的模型UV没有问题但如果是在代码里动态生成的几何体比如BoxGeometry调整了分段数UV可能和你预期的不一样贴图会拉伸成奇怪的样子。贴图不显示的另一个常见原因是跨域。如果纹理放在CDN上且CDN没有返回正确的CORS头WebGL会出于安全策略拒绝使用纹理。解决办法是确保CDN配置了crossorigin头或者把纹理放到同域名下。4.3 动画抖动与载入跳变粒子平滑过渡时出现抖动多半是浮点精度问题。我在前面提到过时间戳用performance.now() / 1000是秒为单位这个数值在长时间运行后会变大导致Shader里计算出现精度损失。一个常见解法是取模material.uniforms.uTime.value (performance.now() % 100000) / 1000;另外GLTF动画如果包含多个动画片段播放时要注意动画权重。用AnimationMixer时如果两个动画没有正确淡入淡出切换瞬间会跳变。解决办法是在切换动画前先设置.fadeIn()和.fadeOut()不要直接action.play()。4.4 性能数字不准排查性能问题时很多人直接看renderer.info里的draw calls、triangles。这个数据在没有后处理时是很准的但一旦加了EffectComposerdraw calls数字会包含后处理Pass的绘制而且后期Pass是全屏四边形triangles会虚高。你看到“draw calls 50”的时候实际场景可能只有20个Draw Call其余都是后处理开销。想要精确分析场景本身的性能还是在浏览器DevTools的Performance面板里录制一段或者用SpectorJS捕捉WebGL命令逐帧看场景绘制信息和状态切换。这个工具能直接列出每一帧的Draw Call列表、绑定的纹理、Program切换次数排查性能问题比看笼统的数字高效得多。4.5 常见问题速查表现象可能原因解决方法画面全黑画布无尺寸/相机在模型内部/无灯光检查setSize、相机距离、场景灯光类型和强度贴图颜色发灰发暗纹理未设置SRGBColorSpace加载纹理后显式设置texture.colorSpace模型加载慢模型体积大、纹理未压缩用gltf-transform压缩纹理和网格粒子系统卡顿每帧在CPU更新粒子坐标把位移计算移到顶点着色器仅传uniform时间动画切换跳变未设置动画淡入淡出使用AnimationMixer的fadeIn/fadeOut后处理画面模糊像素比过高或Blur半径过大降低setPixelRatio或调小模糊半径阴影边缘锯齿严重Shadow Map分辨率不足调大shadow.mapSize或改用PCFSoft阴影模型局部闪烁深度冲突或面重叠检查几何体是否有重叠面调整camera near/far5. 实操体验从一个案例看整体工作流我不是光看案例就完事这期我挑了其中一个人物全息投影案例做了完整复现。全息投影算是一个不大但全面的场景外部模型、自发光材质、动态粒子、交互控制、后处理发光基本上涵盖了前面讲的所有技术点。完整流程是这样的先搭基础场景安装依赖和入口然后加载人物模型调整模型格式和材质接着做粒子环绕效果通过Shader控制粒子沿着人物轮廓运动再把Bloom后处理挂上让发光部位有光晕最后做鼠标旋转交互和加载进度。每一步都有对应的问题要处理。用到的技术选型是Vite Three.js RawShaderMaterial。之所以不选React项目直接写是因为这个场景不需要复杂状态管理纯Three.js足够。如果你要嵌套到React工程里建议把Three场景逻辑封装成一个独立的类避免组件重新渲染导致Canvas多次初始化。5.1 创作环境与工程搭建要点工程搭建很简单初始化一个Vite项目然后安装Three.jsnpm create vitelatest hologram-project -- --template vanilla cd hologram-project npm install threeThree.js的主入口文件建议直接从指定的模块路径引入不要引入整包import * as THREE from three; import { EffectComposer } from three/examples/jsm/postprocessing/EffectComposer.js; import { RenderPass } from three/examples/jsm/postprocessing/RenderPass.js; import { UnrealBloomPass } from three/examples/jsm/postprocessing/UnrealBloomPass.js;目录结构我会分成src/scene.js、src/effects.js、src/controls.js几个模块把场景构建、效果器、交互逻辑分开。项目小的时候看似没必要但当你调后处理参数或换模型时这种分离能让你少走很多弯路。5.2 从案例到落地最容易做的三个裁切案例能跑得漂亮不代表它能直接上线。我在把Demo转成可落地方案时通常会做三个裁切。一是性能预算裁切。热门案例里的粒子动辄十万后处理拉满光线追踪般的反射效果满天飞。真上线时品牌页首屏加载时间不能超过三秒手机上要稳住30帧。所以粒子数量砍到原来的三分之一后处理只保留一个UnrealBloomPass反射效果能用环境贴图替代就替代。二是交互复杂度裁切。案例为了演示效果会做很多复杂的鼠标交互、键盘快捷键、多视角切换。真实业务页面里用户只想快速浏览核心信息过度交互反而干扰。我通常只保留悬浮旋转、点击点击缩放这两个操作。三是资源体积裁切。模型压缩、纹理压缩、音频裁剪这些不能等上线前再做而是要在方案阶段就规划好。这里说的是一个长期有效的原则不要无脑把热门案例整段复制到业务里而是提取出适合业务的部分哪怕这个部分只用了案例里20%的技术点。能让项目跑起来并且跑得稳比把效果做满更重要。我个人这期实操下来最深的体会是Three.js已经过了那个“demo看起来很炫但业务不可用”的阶段。现在的新版本、新工具链让WebGL/WebGPU复杂场景逐渐有了生产级落地的可能性。但越是这样越不能只追新特性反而要更重视工程化、性能预算、资源压缩这些“不性感”的环节。你最终上线跑得稳靠的往往不是某个神奇的渲染魔法而是这些基础工作做到位了。最后再分享一个小技巧无论是调材质还是调后处理参数别在代码里反复改数值然后刷新页面。用dat.GUI或lil-gui把参数暴露到面板上实时滑动调整。等你调出满意的效果后再固化到代码里。比起盲改刷新效率能高出一个量级。