Web 三维可视化技术对比：ParaView Web vs 本项目 wasm + Three.js
对比对象：
- ParaView 5.10.0 Web 套件 ：
D:\ParaView-5.10.0-Windows-Python3.9-msvc2017-AMD64\share\paraview-5.10\web- 本项目 Web 方案 ：3DVisualizationOfReservoirsHisim/wasm（Emscripten + Three.js）
分析日期：2026-10-11
一、一句话结论
| ParaView Web | 本项目 wasm + Three.js | |
|---|---|---|
| 本质 | 客户端-服务器远程渲染（瘦客户端，像素流） | 浏览器内本地计算 + 本地 GPU 渲染（胖客户端，几何流） |
| 数据去向 | 数据留在服务器，浏览器只收"画面" | 数据下载进浏览器，在浏览器里解析、生成几何、上屏 |
两者不是同一代技术路线：ParaView Web 解决的是"重数据/重渲染放不进浏览器 "，你的 wasm 解决的是"无服务器、纯静态部署也能交互"。
二、ParaView Web 套件构成（实测）
share/paraview-5.10/web 下有 4 个独立应用：
| 应用 | 大小 | 定位 |
|---|---|---|
| glance | 13.9 MB / 31 文件 | 通用查看器 （最常用）：单 HTML 文件内嵌整个应用（ParaViewGlance.html 5.2 MB），Angular 前端，连接 pvserver/pvweb 远程渲染 |
| lite | 14.5 MB / 61 文件 | Python 脚本环境 ：浏览器端 pyodide 式体验，连接 pvpython 内核 |
| divvy | 3.5 MB / 27 文件 | 多视图协同（远程可视化墙/大屏拼接） |
| visualizer | 2.5 MB / 11 文件 | 经典 ParaView Web 查看器（旧一代） |
glance 技术栈拆解
- 前端 ：Angular + webpack 打包（
vendors.*.js2.3 MB、glance.*.js666 KB）+ PWA（workbox-sw/serviceWorker.js离线缓存）。 - 通信 ：WebSocket（wslink 协议）------浏览器发送"操作意图"（改视角/改参数），服务器 VTK 渲染管线出图，回传 JPEG/PNG 图像块。
- 渲染发生在 ：桌面端
bin\pvserver.exe+ 全套 VTK/OSPRay/nvIndex DLL（1.3 GB 那一坨就是服务端算力）。 - UI 资源：SVG 图标、字体（eot/ttf/woff）、CSS------纯展示层。
三、本项目 wasm + Three.js 构成（实测）
| 组件 | 大小 | 角色 |
|---|---|---|
src/main.cpp |
15.8 KB | C++ 核心：EMSCRIPTEN_KEEPALIVE 导出 ~10 个函数（网格解析、几何提取、属性访问） |
dist/reservoir.wasm |
5.6 MB | 编译产物：亿级网格的数据解析 + 几何生成在浏览器内跑 |
dist/reservoir.js |
166 KB | Emscripten glue（加载器 + JS↔WASM 绑定） |
test.html |
86 KB | 页面 + Three.js 0.160 WebGL 渲染 （import * as THREE、OrbitControls、VolumeRenderer） |
渲染管线
.grdecl/bin 数据文件 ──HTTP Range/下载──▶ 浏览器
→ reservoir.wasm 解析网格/属性（本地 CPU，SIMD）
→ 生成顶点/索引/颜色 Buffer
→ Three.js BufferGeometry → WebGL → 浏览器 GPU 光栅化没有任何服务器 ：一个静态文件目录 + 任意 HTTP 服务（甚至 file:// 受限场景用本地 http-server）即可部署。
四、逐维度技术对比
| 维度 | ParaView Web (glance) | 本项目 wasm + Three.js |
|---|---|---|
| 架构模式 | C/S 远程渲染（像素流） | 纯浏览器端（几何流） |
| 部署成本 | 需常驻 pvserver 进程/集群，1.3 GB 服务端 | 静态托管（Nginx/GitHub Pages/CDN），零后端 |
| 传输内容 | 图像帧（每次交互都要回传） | 原始数据一次下载（或按需分块） |
| 交互延迟 | 受网络 RTT 限制；旋转时"糊帧→清帧" | 本地 GPU 直接渲染，60 FPS 顺滑 |
| 渲染能力 | 完整 VTK：体渲染/OSPRay 光追/nvIndex GPU 加速/LOD/并行 | WebGL 实时光栅化：表面/切片/等值面；体渲染靠 shader 近似 |
| 数据规模上限 | 服务器内存为准（TB 级，亿级网格无压力） | 浏览器内存为准（单 tab ~2--4 GB，需降采样/分块） |
| 计算能力 | 服务器 CPU+GPU 全栈（滤波/等值面/积分都在服务端） | WASM 本地 CPU（SIMD 可用，但无 CUDA） |
| 离线/弱网 | 不可（必须连服务器） | 可（数据+代码全在本地） |
| 并发用户 | 每用户一个渲染进程（服务器成本线性增长） | 每用户自扛（服务端零成本） |
| 安全/数据主权 | 数据不出机房（军工/油企内网友好） | 数据必须下发到用户浏览器（脱敏红线问题） |
| 包体积 | glance 前端 ~14 MB + 服务端 1.3 GB | 全量 ~6 MB（wasm 5.6 + js 0.17 + html） |
| 开发栈 | Angular + VTK/C++/Python 服务端 | 原生 JS/ES Module + C++/Emscripten |
| 工程成熟度 | 10+ 年工业打磨，PWA、多端适配、协同（divvy） | 单页 demo 级，但已验证亿级网格降采样管线 |
五、各自的"杀手锏"与"死穴"
ParaView Web
- 杀手锏：① 服务端完整 VTK 渲染栈（光追体渲染、nvIndex）；② 数据不出内网；③ TB 级数据集无压力；④ 客户端零安装、老弱设备也能看（只收图像）。
- 死穴：① 必须有服务器 + 运维；② 网络差 = 交互卡；③ 每并发都要烧一份服务器算力。
本项目 wasm + Three.js
- 杀手锏 ：① 零后端静态部署，CDN 一挂全球可用；② 本地 60 FPS 交互（无网络往返）；③ 离线可用；④ 6 MB 全家桶。
- 死穴：① 浏览器内存天花板（亿级网格必须降采样到 ~3000 万单元，这正是你项目已有的对策）；② 无光线追踪/体渲染质量受限；③ 原始数据下发到客户端（涉密场景不可接受）。
六、对你项目的可借鉴清单
- 分块渐进加载 ：glance 的"图像块流式回传"思想 → 可映射为你的几何分块流式上传（Z 轴 chunk 已实现，Web 端可按视锥优先加载）。
- PWA 离线缓存 （workbox/serviceWorker）：你的
test.html可加 Service Worker 缓存 wasm + 数据，实现断网可用。 - wslink 协议设计 ：ParaView 把"操作意图序列化"为轻量 JSON-RPC------若未来做混合架构（重属性计算回服务端），可直接复用 pvpython 的 wslink。
- glance 单文件分发 ：
ParaViewGlance.html把整个应用打进一个 HTML------你的test.html已是类似思路（86 KB 内嵌），发布传播体验好。 - hybrid 路线（最有价值） ：学习 ParaView 的 pvrenderserver/pvdataserver 分离 思想------将来若客户要"数据不出内网"，可把 reservoir.wasm 换成内网 pvserver 后端，前端 Three.js 只保留交互层，形成同一前端两种后端的产品矩阵。
七、选型建议（决策树）
数据涉密不出内网？ ──是──▶ ParaView Web（pvserver 私有部署）
│
否
▼
需要体渲染/光追级画质做汇报？ ──是──▶ ParaView Web / 桌面版
│
否
▼
目标用户网络差 / 无服务器预算 / 要离线 / 要 60FPS 顺滑交互？
│
是 ──▶ 本项目 wasm + Three.js（降采样 + 分块已就位）场景"wasm 路线"------零部署成本 + 可分享 URL 是 ParaView Web 给不了的。