# Track B 总验收实测结果（build-stream 多线合并流式建体）

工具：`tools/gpr_poc`（CLI），子命令 `build-stream`。
执行机：Windows 11，MSVC（VS18 Community）+ Ninja，Release（/O2），开发机（RTX 3060 Laptop GPU 旁）。
日期：2026-06-23。

整条流式链路（B1→B5 成果在 B6 串起来）：
`assembleGprSurveySlab（道窗口）→ sampleGprPoint（结构化插值）→ StreamingVolumeWriter（增量 zlib 写 brick）→ buildPyramidStreaming（从盘 brick 逐级降采样）→ WholeVolumeSource(load)`。

> Track B 的核心命题：把建体管线改成沿 X 分段（slab）流式（逐段读道→插值→写 brick→释放），
> 使建「20 线合并大体」的峰值内存**有界、不随线数增长**、无 OOM，且产物可被 `load` 读回。
> 对比基线：旧 double-survey 非流式方案，单线装配峰值 ≈4.2 GB，20 线 ≈84 GB → 装配阶段必然 OOM。

---

## 1. 验收命令

```
gpr_poc build-stream "D:\Downloads\明星路" --cellXY 0.2 --cellZ 0.05 --out <storeDir> --levels 2
gpr_poc load <storeDir>
```

- 合并方式：**沿 X 顺序排列**（退路近似）——各线按 brick 对齐的 X 偏移依次拼入一个连续 store。
  真实 RTK 几何拼接（按各线实际平面坐标拼成路网大体）留 **Track D**。
- 量化 scale/offset **全局一致**：先扫一遍全部 20 线得全局 min/max（流式下不能每 slab 各算），
  再以全局值域逐线逐 slab 写 brick。

---

## 2. build-stream 实测指标（20 线合并大体，cellXY=0.2，cellZ=0.05，levels=2）

| 指标 | 值 |
|------|-----|
| 合并测线数 | **20** |
| 合并体维度（nx×ny×nz） | **156544 × 8 × 82** |
| 体素数 | **102,692,864**（≈1.03 亿） |
| 原始体积（int16，进显存判据） | **195.871 MB** |
| 落盘 data.bin（含金字塔各级） | **105.422 MB** |
| 压缩比（原始/落盘） | **1.858×** |
| 扫全局量化区间耗时 | **181,288 ms**（一次性读全 14 GB 原始道） |
| 建体（流式 slab→写 brick）耗时 | **89,927 ms** |
| 流式金字塔耗时 | **6,972 ms** |
| build-stream 端到端墙钟 | **278,788 ms（≈4.6 min）** |
| **峰值内存** | **246.164 MB** |

### 峰值内存全程稳定（核心结论证据）

20 线全程峰值内存稳在 **≈246 MB**（245.973 MB → 246.164 MB），**不随合并线数增长**：

| 阶段 | 峰值内存 |
|------|----------|
| 扫全局量化 / 起始线 | 245.973 MB |
| 第 20 线写入完成 | 246.164 MB |

即流式建体的峰值内存**有界**——只随单个 slab + 一行 brick 的工作集，与合并总量（线数/体素数）无关。
对比旧 double-survey 非流式方案 20 线需 ≈84 GB，本方案以 246 MB 建出 1 亿体素的合并大体，**无 OOM**。

---

## 3. load 实测指标 —— 产物可读 ✓

命令：`gpr_poc load <storeDir>`

| 指标 | 值 |
|------|-----|
| 加载耗时 | **1,756 ms** |
| 整卷维度 | **156544 × 8 × 82** |
| 峰值内存 | **214.55 MB** |

流式产出的合并大体 store 可被 `WholeVolumeSource` 完整加载、维度一致、**产物可读**。

---

## 4. Track B 总验收结论

- ✅ **峰值内存有界、与总量无关**：20 线合并大体建体全程峰值稳在 ≈246 MB
  （245.973→246.164），不随线数增长。这是 Track B 的核心目标，达成。
- ✅ **无 OOM**：旧非流式方案 20 线 ≈84 GB 必 OOM；流式方案 246 MB 即建出 1 亿体素合并体。
- ✅ **产物可读**：`load` 在 1,756 ms 内读回，维度一致（156544×8×82），峰值 214.55 MB。
- ✅ **压缩与落盘正常**：原始 195.871 MB → data.bin 105.422 MB（含金字塔各级），压缩比 1.858×。

### 已知约束 / 留待后续

1. **扫全局量化 181 s 是「读全 14 GB 原始道」的 I/O 开销**——为保证量化 scale/offset
   全局一致必须先全扫一遍 min/max。可后续优化（如复用建体阶段的单遍读、或用头估值域），本次不做。
2. **合并几何用退路近似（沿 X 顺序排列，brick 对齐）**——非真实路网平面几何。
   真实 RTK 几何拼接（按各线实际平面坐标拼成路网大体）留 **Track D**。
3. **最低配未验**：仅在本机（RTX 3060 Laptop 开发机）实测；最低配机器内存/磁盘表现待补测。

### 与 Track C 的衔接

Track B 已证「大体能建（246 MB 有界）+ 能读（1.76 s 加载）」。Track C 在此大 store 上做
视野自适应 LOD 体绘制（视锥裁剪+视距选层 → 视野区域单纹理重组 → 平滑切换+后台预取），
解决 POC-B §4 记录的「整卷 X 维超 GL 单轴纹理上限（16384）」问题。