让十万粒子跑进浏览器：Vibe Particles Web

为什么要做浏览器版

Vibe Particles Web 是一次把实时粒子视觉搬进浏览器的实验。我想保留桌面创意工具那种“边调边看”的手感，同时让作品只靠一个网页就能打开，不必先安装专用图形软件。

浏览器也把输入、权限和导出放进同一套交互里：本地图片、视频、摄像头和程序化噪声都可以成为粒子目标，参数变化立即反馈到画面。

系统使用 Three.js 的 GPUComputationRenderer，在纹理中保存粒子位置与速度。目标纹理由输入模块生成，更新着色器读取目标、噪声、指针和音频数据，再把结果交给渲染着色器。

粒子数量固定为 100,000。这个选择让实现和视觉密度保持稳定，但不代表所有设备都能得到相同帧率；实际表现会受到 GPU、驱动、分辨率和输入源影响。

输入可以来自本地图片、本地视频、摄像头或程序化噪声。图片、视频、摄像头画面和麦克风数据只在当前页面处理，项目没有把这些媒体上传到服务器的接口。

Web Audio 分析麦克风频谱并影响运动参数，Web MIDI 的 Control Change 消息可以映射到部分粒子、运动和音频控制。两者都受浏览器权限与平台支持限制。

作品可以导出 PNG，也可以用 MediaRecorder 录制画布为 WebM。当前 WebM 只包含画布视频，不包含麦克风音轨；自定义预设则保存在浏览器的 localStorage 中。

我把它做成纯前端静态应用，以换取简单的本地运行与部署。代价是没有服务器端回退，也无法替浏览器统一摄像头、麦克风、MIDI、编码器和下载格式的差异。

固定粒子数量简化了计算纹理与几何结构，却没有按设备自动降级。控制界面也优先服务桌面指针操作，移动端体验和触控布局仍需要重新设计。

2026-08-04 的单机验收在 Windows、Chrome 150 和 NVIDIA GeForce RTX 4060 Laptop GPU 上完成。HTTP、WebGL2 首屏、变化中的粒子画布、图片与视频输入、模拟摄像头和麦克风、PNG、WebM 及预设持久化均有通过记录。

界面曾显示 165 FPS，这只是上述单台机器的一次观察值，不是可复现基准，也不能代表其他浏览器、GPU、分辨率或输入源的性能。

这次验收不等于完整的跨浏览器、跨 GPU、移动设备或真实 MIDI 硬件认证。依赖升级后的检查也只是一次聚焦启动与渲染的冒烟测试，并未重跑全部能力矩阵。

同日运行 npm audit --audit-level=moderate 得到 0 个已知漏洞，是当时锁定依赖下的审计结果。它不代表绝对安全，也不能把这个原型视为生产就绪版本。

麦克风权限被拒绝时，AudioManager 会捕获错误，但界面仍可能错误显示已连接。项目也还没有 WebGL2 缺失时的友好回退、移动端重设计、真实 MIDI 设备覆盖，以及预设导入与导出。

部分着色器遮罩使用跨驱动结果未定义的 reversed-edge smoothstep。边界与重生速度变化也处在不写回速度纹理的计算路径中，因此可能无法持久化。

音频平滑控制尚未接入 AudioManager。MIDI、MediaRecorder、视频编解码和下载格式的支持取决于浏览器与操作系统，当前 OSC 状态也只是占位信息。

下一步会先在获得明确授权后修正着色器可移植性，并把边界与重生速度迁移到真正写回速度纹理的计算 pass。随后补充可复现的 GPU 基准、浏览器与设备矩阵，以及自动化启动冒烟测试。

产品侧还要完善摄像头、麦克风和 MIDI 的拒绝状态，加入 WebGL2 不可用时的清晰提示，重做移动端控制，支持预设导入与导出，并验证各平台的录制兼容性。

源码已公开在 SiyanHub/vibe-particles-web。可以在 GitHub 查看或下载，也可以 clone 后按照 README 在本地安装依赖并运行。

仓库目前没有 LICENSE，也没有发布为 npm 包。因此，公开可见和可下载不等于已经授予复制、修改或再分发的许可；如需复用，请先联系作者确认授权。