9.2 KiB

Raw Permalink Blame History

GPR 三维体 · 方案 C：分块 + 金字塔 + 核外（应对超大数据量）

日期：2026-06-23
范围：当单个三维体在合理分辨率下仍超显存/内存时（几十公里测线、多工区合并、或必须超精网格），采用业界处理 TB 级体的标准架构：分块(bricking) + 多分辨率金字塔(LOD) + 逐块压缩 + 核外按需加载(out-of-core)。
定位（2026-06-23 用户定）：与 B 对等的两条已承诺路线之一，两者都做、用户运行时按需切换（不是 B 的兜底/预案）。对标地震(OpenVDS/ZGY)、数字病理/显微(OME-Zarr)。B 适合能整卷进显存的体、C 适合超显存/超大范围的体，由用户按数据选择，经同一 IVolumeRenderSource 接口切换。
POC（用户定）：C 的 POC 含"最小但真实的核外分页器"，正面验证最高风险点（分页器在 VTK 上可行性、块边接缝、LOD 闪烁、热路径解压），"POC 过 ⇒ 可落地"。
前置：地基(.iprb 解析/配准/接入) 与 int16 + 结构化建体与方案 B 共用。
⚠ 评审结论（2026-06-23，opus）+ 用户决策：Go——C 是已承诺路线，与 B 都做。 架构对标业界无误。开工注意：①vtkHDFWriter 写不了规则体（与 B 同源 CRITICAL，§2.2 已改正为裸 HDF5/分块）；②整卷核外分页器无 VTK 开箱基础（CRITICAL，月级，POC 即用最小真实分页器正面验证）；③vtkSmartVolumeMapper 自带 LowResResample 仅作 C 内的降质兜底手段，不替代 C。落地顺序：裸分块格式 → 切片核外 → 整卷核外分页器。

1. C 的适用场景（用户在 B/C 间按需选择的依据，非"门槛"）

C 与 B 并存，用户对某个体选 C 而非 B，典型是：

合理分辨率(5~10cm)下单体 int16 体积 超过本机显存；
测线长一个数量级（几十 km）或多工区拼接成连续大体；
需要在内存/显存恒定下浏览任意大的体。

B 与 C 同为成品、经同一 IVolumeRenderSource 切换；小体走 B（整卷最省力）、大体走 C（核外不爆内存），由用户按数据选。

2. 架构

建体(int16) → 分块(brick 64³/128³) → 逐块压缩 + 每块 min/max
            → 多分辨率金字塔(全分辨率 / 1/2 / 1/4 / 1/8 …)
            → 写入分块格式文件（离线/后台一次）
渲染 → 核外分页器：按相机视野 + LOD 选块 → 解压载入显存 → 相机移动换入换出
      内存/显存只驻留当前所需块（数 GB），与总体积无关
切片 → 只读切面相交的块（最便宜的子集）；等值面靠每块 min/max 剔除
交互 → 拖动用粗 LOD，停下加载全分辨率；沿拖动方向预取

2.1 存储格式（分块 + 金字塔 + 压缩）

⚠ 不能依赖 vtkHDFWriter（评审 CRITICAL，与 B 同源）：VTK 9.6 的 vtkHDFWriter 写不了 vtkImageData/规则体（vtkHDFWriter.h:6-9,232-235，仅 PolyData/UnstructuredGrid/composite）；且无规则体的多分辨率 overview（头文件唯一多级机制是 AMR 层级 vtkHDFReader.h:203-209，非金字塔）。所以"补 IOHdf 组件即可 VTKHDF 落盘 + overview"不成立——原 spec 的"待验证"实为"基本不支持"。
首选（改正后）：裸 vtkhdf5 C API 自写 chunked dataset（HDF5 原生 chunking + zlib 逐块压缩 + 随机访问），金字塔层作为多个 HDF5 dataset 自行组织；或自定义 brick 文件（裸分块 + 索引），每块 zlib + 头存 min/max + LOD 偏移表。与 B 的落盘层统一（B 本就要改成裸分块，正好一并设计成可分块/可多级）。
不引入独立 zstd/blosc（vcpkg 未含）；如压缩比不足再评估加入。

2.2 渲染端核外分页（C 的真正难点）

VTK 不开箱提供大体的 out-of-core GPU 体绘制（评审证实）。 注意两个相关但不够用的开箱件：
- vtkMultiBlockVolumeMapper 存在但不是分页器（vtkMultiBlockVolumeMapper.h:14-21：试图"同时加载所有块"，仅 GPU 分配失败才退化逐块重载）——它给的是"多块同时渲染 + 抖动抗块边接缝"，没有按视野换入换出/LOD 选块/预取。要复用它做渲染层，须在喂数据前自己完成"只放视野块"的筛选。
- vtkSmartVolumeMapper 的 LowResResample（见 B §2.2）是"自动降质看全貌"，不是核外——它是 C 之前的免费兜底，不是 C 的实现。
整卷核外分页器须从零自建（选块/LOD/LRU/解压/换入换出/预取）。三条路：
1. 切片优先（推荐先做）：切片只需读相交的块，复用 vtkImageReslice 对"当前块集合"重采样。这条最易落地，能先拿到"超大体看切片"的能力，不碰整卷核外。
2. 自建 LOD + brick 分页：在 vtkSmartVolumeMapper 之上，把视野内块按 LOD 作为多个 vtkImageData/vtkMultiBlockDataSet 动态加载/淘汰。整卷透明体绘制走这条，工作量最大。
3. 集成 OpenVDS（地震库）：能力最全但重依赖（vcpkg 未含，需自带 + 适配 VTK），适配成本高。
建议：先做 1（切片核外），整卷体绘制核外(2)列为后续。

2.3 建体/金字塔流水线

复用方案 B 的 int16 + 结构化建体产出全分辨率体 → 分块 → 逐级降采样建金字塔 → 逐块压缩落盘。
离线/后台执行一次，结果即持久化产物（C 的"保存插值后体"天然就是这个分块金字塔文件）。

3. 持久化

C 的存储格式本身就是方式二（明细缓存）：分块 + 金字塔 + 压缩，是"算一次、之后秒开"的载体，且读取只碰视野块、内存可控。
方式一（参数档 VolumeBuildParams+GridSpec）仍保留，用于复算/详情/校验。
切片/异常坐标仍锚定 GridSpec（与 A/B 一致），保证跨 LOD 一致。

4. 评估

优点

不设规模上限：任意大小（几十 GB ~ TB）皆可，内存/显存恒定在数 GB。
切片只读相交块、等值面块级剔除、拖动 LOD 降级 —— 大体交互可做到流畅。
与业界(地震/医学)成熟路径同构，可借鉴现成设计。

缺点/风险（评审分级）

CRITICAL：vtkHDFWriter 写不了规则体 → 落盘须自写裸 HDF5/分块（§2.1 已改），是中大件，非"补组件"。
CRITICAL：整卷核外分页器无 VTK 开箱基础，从零自建（选块/LOD/LRU/预取），月级且风险集中；或集成重依赖 OpenVDS。
HIGH：VTKHDF 无规则体多分辨率 overview，金字塔须全自管。
HIGH：压缩块解压在交互热路径（拖动每帧换块解压），CPU 可能成瓶颈——不止 IO 放大。
MEDIUM：LOD 降采样的半像素偏移 → 异常拾取跨层落点漂移（"GridSpec 锚定保证一致"未覆盖此情形）。
MEDIUM：块边接缝（MultiBlock 抖动可部分缓解）/ LOD 切换闪烁（需 morphing/淡入自解决）。
复杂度高 → 维护成本与缺陷面大。
依赖断点（评审）：C 声称"复用 B 的落盘"，而 B 那层须先从 VTKHDF 改成裸分块 HDF5——C 的"地基已就绪"前提依赖 B 先这么做。

适用

仅当数据真正超出方案 B 的单显卡承载。当前明星路用不到。

5. 工作量与落地顺序（仅在需要时启动）

地基 + int16 + 结构化建体（与 B 共用，若已做则复用）。
分块格式 + 逐块压缩 + 每块 min/max（VTKHDF 或自定义）（~中大）。
多分辨率金字塔生成流水线（后台一次）（~中）。
切片核外：按切面读相交块重采样（~中）—— 先交付这条。
整卷体绘制核外分页器 + LOD 拖动降级 + 预取（~大，后续）。
显存/内存缓存与淘汰策略（~中）。

6. 与 A/B 的关系

能力：A ⊂ B ⊂ C；成本同序递增。
A、B 共享渲染/切片现有架构；C 是不同的存储+渲染架构（分块+核外），是 B 撞到显存天花板后的演进，不是平行替代。
推荐策略：现在做 B 满足明星路与多数工程；把 C 的"分块格式 + 切片核外"作为预案，待出现真正超大数据再启动；整卷体绘制核外列为最后一档。

切片核外"最易落地"有隐藏前提（评审）：它要求分块格式已做完才能"读相交块"。所以"先交付切片核外"≠ 可跳过分块——§5 顺序（先分块格式再切片核外）正确，别误读为切片核外是独立小工程。

结论（用户定：Go，C 与 B 都做）：C 的总体架构成立、对标 OpenVDS/ZGY/OME-Zarr 无误，是与 B 对等的已承诺成品；工程最重、渲染端整卷核外非开箱、落盘须裸 HDF5（已改）。

落盘与 B 统一：裸分块格式（不依赖 vtkHDFWriter），B 落盘本就改裸分块，C 的分块/切片核外在同一格式上增量获得。
整卷核外分页器是 C 的最高风险件（两个 CRITICAL + 热路径解压 HIGH，月级），POC 即以"最小真实分页器"正面验证，确保"过了能落地"。
B/C 切换：经 IVolumeRenderSource 运行时切换，用户按数据选；LowResResample 是 C 内的降质手段，不替代 C 也不替代用户选择。

9.2 KiB Raw Permalink Blame History Unescape Escape