# 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. 工作量与落地顺序（仅在需要时启动）

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

---

## 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 也不替代用户选择。