Three.js + WebGL 粒子动画实测：10 万粒子流畅运行

Three.js + WebGL 粒子动画实测：10 万粒子流畅运行 | 极客日志

文章配图

测试环境

Windows 桌面，WPF + WebView2。

处理器 Intel(R) Core(TM) i9-14900HX (2.20 GHz)
机带 RAM 32.0 GB (31.7 GB 可用)
系统类型 64 位操作系统，基于 x64 的处理器
操作系统版本 Windows 11 家庭中文版

实现原理

核心思路是：用 C# 承载页面，用 Three.js 组织 3D 场景，用 WebGL 做底层 GPU 绘制。

整体如下：

WPF 窗口中嵌入 WebView2。
在 C# 中动态拼接 HTML，并通过 NavigateToString 注入页面。
页面侧加载 three.min.js，创建 Scene / Camera / WebGLRenderer。
粒子通过 THREE.BufferGeometry 与多个 BufferAttribute 存储。
每帧在 JS 中更新粒子位置与生命周期，提交属性更新后由 GPU 渲染。
页面每秒统计一次 FPS，通过 window.chrome.webview.postMessage(...) 回传给 C#，在 UI 上实时显示。

总结为：这是一个'CPU 负责粒子状态更新，GPU 负责大规模点精灵绘制'的混合型架构。

关键技术点

1. 跨技术栈集成：WPF 与 Web 3D 的桥接

C# 端调用 EnsureCoreWebView2Async() 初始化浏览器内核。
使用 WebMessageReceived 接收前端消息，把 FPS 同步回桌面 UI。
这样可以让原生桌面应用拥有 WebGL 渲染能力，同时保留 WPF 的业务壳层。

2. 大规模粒子数据结构：BufferGeometry

粒子位置、颜色、尺寸、生命周期都以 Float32Array 组织。
通过 geometry.setAttribute(...) 绑定到 GPU 可消费的缓冲属性。
相比逐对象管理，结构化数组 + 批量绘制是海量粒子的基础。

3. 自定义 Shader：粒子视觉在 GPU 完成

顶点着色器负责点大小透视缩放、生命周期透明度系数计算。
片段着色器利用 gl_PointCoord 裁剪圆形粒子并做柔和边缘。
材质配置启用 AdditiveBlending，形成更亮的粒子叠加效果。

4. 仿真更新模型：每帧 CPU 循环

当前粒子运动（重力、阻力、边界反弹、重生）都在 JS for 循环中执行。
这使逻辑直观易控，但也带来一个关键瓶颈：粒子数线性增长时，CPU 计算和属性回写成本同步上升。

核心代码

1. 粒子总量入口

private const int ParticleCount = 100000;
这是压测的直接控制阀，影响所有数组长度和每帧循环规模。

2. GPU 友好数据准备

positions / colors / sizes / lifetimes / maxLifetimes 都是 Float32Array。
BufferAttribute 绑定后由 THREE.Points 进行一次性批量绘制。

3. 渲染材质与 Shader

THREE.ShaderMaterial({...}) 挂载 vertexShader 与 fragmentShader。
开启 transparent + AdditiveBlending + depthWrite:false，确保粒子叠加效果。

4. 每帧更新与提交

updateParticles(deltaTime) 内遍历全部粒子更新状态。
更新后设置：
- particles.geometry.attributes.position.needsUpdate = true
- particles.geometry.attributes.lifetime.needsUpdate = true
这一步会触发 GPU 侧缓冲同步，粒子越多，带宽与提交压力越大。

5. 桌面侧 FPS 可观测性

页面端每秒 postMessage('FPS: ' + fps)。
C# 侧 WebMessageReceived 更新 txtFPS.Text。
这让测试过程具备了稳定的在线观测能力。

实测结果

1 万粒子：FPS 145 , 非常流畅； 10 万粒子：FPS 53 ，流畅； 50 万粒子：FPS 14 ，明显卡顿； 100 万粒子：FPS 7，严重卡顿，接近不可用；

性能分析

1. 为什么 1 万到 10 万仍能跑得动？

WebGL 批量绘制能力较强，点精灵渲染天然适合并行。
数据结构使用 BufferGeometry，减少了对象级 draw call。
Shader 逻辑相对轻量，没有复杂纹理采样或后处理。

2. 为什么到 50 万、100 万会急剧下滑？

核心原因不是'GPU 不能画点'，而是CPU + 数据传输 + GPU 渲染三者叠加后的总成本爆炸：

CPU O(N) 更新成本：每帧遍历所有粒子，计算速度、位置、碰撞、重生。
缓冲更新成本：position/lifetime 每帧都标记 needsUpdate，意味着大体量数据频繁上传。
像素填充压力：粒子数量增大后，叠加混合（Additive）会显著增加片段处理负担。
浏览器容器开销：WebView2 本质是嵌入式浏览器，不是纯原生图形管线，存在额外调度成本。

3. 从数据看当前实现的可用区间

推荐实时区间：1 万 ~ 10 万（视业务目标而定）。
风险区间：>10 万后帧率明显衰减，尤其在复杂效果叠加时。
极限演示区间：几十万到百万可以'展示数量级'，但不适合交互型实时动画。

总结

它验证了 WebView2 + Three.js + WebGL 路线在桌面应用中的可行性。
它给出了当前实现的性能基线：10 万以内可用，数十万后显著下降，百万级不可实时。
它说明了后续优化的重点不只是'继续堆 GPU'，而是要系统处理CPU 更新模型与数据上传路径。

文章配图

Three.js + WebGL 粒子动画实测：10 万粒子流畅运行

测试环境

实现原理

关键技术点

1. 跨技术栈集成：WPF 与 Web 3D 的桥接

2. 大规模粒子数据结构：BufferGeometry

3. 自定义 Shader：粒子视觉在 GPU 完成

4. 仿真更新模型：每帧 CPU 循环

核心代码

1. 粒子总量入口

2. GPU 友好数据准备

3. 渲染材质与 Shader

4. 每帧更新与提交

5. 桌面侧 FPS 可观测性

实测结果

性能分析

1. 为什么 1 万到 10 万仍能跑得动？

2. 为什么到 50 万、100 万会急剧下滑？

3. 从数据看当前实现的可用区间

总结

更多推荐文章

相关免费在线工具

Three.js + WebGL 粒子动画实测：10 万粒子流畅运行

测试环境

实现原理

关键技术点

1. 跨技术栈集成：WPF 与 Web 3D 的桥接

2. 大规模粒子数据结构：BufferGeometry

3. 自定义 Shader：粒子视觉在 GPU 完成

4. 仿真更新模型：每帧 CPU 循环

核心代码

1. 粒子总量入口

2. GPU 友好数据准备

3. 渲染材质与 Shader

4. 每帧更新与提交

5. 桌面侧 FPS 可观测性

实测结果

性能分析

1. 为什么 1 万到 10 万仍能跑得动？

2. 为什么到 50 万、100 万会急剧下滑？

3. 从数据看当前实现的可用区间

总结

微信扫一扫，关注极客日志

更多推荐文章

相关免费在线工具