# ⚠️ 本 spec 已被实测推翻，勿照此实现

> **结论（见 `2026-06-26-gpr-3d-render-perf-ANALYSIS-for-review.md` §10）：ESS/OSPRay/多后端【不做】。**
> 实测：ESS 对本数据 ~2× 且不解决重叠；passcost 确诊"多线卡"的真因是【没用视野 LOD、渲整卷大贴图】，
> 不是固定开销。**正解 = LOD 中心（各线独立 mapper + 视野 LOD + 停手重建），见下方实现计划。**
> 本文余下"多后端/ESS"内容仅作历史记录。

---

## 实现计划（LOD 中心多线总览 — 已确诊、可执行）

**目标**：把 `cmdViewAll` 从"multi-volume 单遍 + 固定整卷大贴图"改为"各线独立 mapper + 视野 LOD +
停手才重建"，使单帧渲染量随视野走、与 20 条总量解耦。

**改动步骤（`tools/gpr_poc/main.cpp::cmdViewAll`）**：
1. `PlacedSource` 加回**每线自己的 `vtkSmartVolumeMapper`**（GPU 模式）；删 multi-volume 用法
   （multiMapper/multiVol/port 不再需要，但可暂留不碍）。
2. **装配**：删 `buildBundles` + 退避（无 multi-volume 即无纹理单元上限）；改为逐线
   `mapper->SetInputData(baseImage)` → `volume->SetMapper(mapper)` → `ren->AddVolume(volume)`，
   各线 mapper 收进 `mappers` 向量（供质量控制）。
3. **开 LOD**：`gViewAllBaseOnly = false`（启用引擎选区换图）；引擎换的是"改包围盒的子区域"，
   各线独立 mapper 下**安全**（无 multi-volume 可破坏）。
4. **关 channel LOD**：`gChanLod = false`——引擎金字塔已逐级降 Y，无需单独抽 Y 平面。
5. `viewAllPickOneLine`：`ps.mapper->SetInputData(ps.currentImg); ps.mapper->Update();`（非 multiMapper 端口）。
6. **停手才重建（已有，确认接线）**：拖动中(`viewAllOnInteracting`)只降质+重置裁剪、**不提交引擎目标**；
   松手(`viewAllOnInteract`)/定时器 idle 才 `viewAllSubmitTargets`（提交 LOD 目标）+ `viewAllPickOneLine`
   （拉就绪区域换上）。避免 P11/P12"每帧 20 条重建上传"thrash。
7. **质量旋钮保留**：`--sampleDist`/`--maxImgSample`/`--dragSampleMul` 作 LOD 框架内的交互降质兜底。
8. **总览级别**：引擎 `selectLod` 按屏幕像素选层——拉远时全路映射到少量像素 → 自动选粗层（小贴图）→
   20 条小贴图即可用；拉近 → 小区域细层。**确认 selectLod 多线下确实选到粗层**（若没有，调
   selectLod 的屏幕像素阈值——这是 §7.5 嫌疑①的修复点）。

**验收**：离屏看各线底图 level 随相机距离变（远→粗/小、近→细/小区）；真窗口测 20 条总览交互级 fps、
拖动跟手、松手清晰、过档位无明显卡顿（外部专家提示重点盯"停手重建过渡手感"）。

---

# GPR 三维体渲染：多后端 + 空体素跳过(ESS) 加速架构 — Spec（2026-06-26，已废）

> 解决"20 个重叠密体在 VTK 库存 OpenGL mapper 上又卡又只能降质"的根本性方案。
> 关联：`docs/superpowers/specs/2026-06-25-gpr-line-channel-interpolation-and-multivolume.md`（数据/插值口径）。

---

## 0. 一句话目标
用**空体素跳过(ESS)** 这一不损可见质量的业界技术，把"逐线分开的多个密体合并渲染"做到**不卡**；
并以**多渲染后端 + 自动适配**覆盖客户侧未知/多厂商硬件（含无显卡）。

---

## 1. 问题与根因
- 现状渲染 = VTK `vtkGPUVolumeRayCastMapper`（OpenGL）。**任意 GPU 可跑（最通用），但无 ESS**。
- 20 个重叠半透明密体：每条光线每步在 20 体各采一次、光线又长 → 几十亿次纹理查找/帧 → 1.7fps、交互更卡。
- 通道插值后 Y 加密到 2.5cm，使自动沿光线步长更细 → 更卡。
- **已尝试的"交互降质"（屏幕降采样 + 沿光线步长加粗）是治标**，损可见质量。

## 2. 根本方案：ESS（不损质量）
GPR 体 ~90% 是近零背景（反射层之间空）。ESS 用 min/max 加速结构**跳过"在传函里全透明"的块**，
对稀疏数据常 5–50× 提速、**零质量损失**。但 **VTK 库存 GPU mapper 不做自动 ESS**（仅有受限的
`UseDepthPass` 等高线跳过）。→ 真 ESS 必须**换专业体渲染后端**（其底层自带 ESS + 正确合成多重叠体）。

## 3. 关键事实：跨厂商 GPU 加速不存在单一方案
GPU 体光追渲染器全是**厂商锁定**：

| 后端 | 硬件 | ESS | 跨厂商 | 角色 |
|---|---|---|---|---|
| OpenGL（vtkGPUVolumeRayCastMapper，现状）| 任意 GPU(N/A/Intel) | ❌ | ✅ | **终极兜底** |
| OSPRay（CPU，Embree/ISPC）| 任意 x86 CPU（免显卡）| ✅ | ✅ | **通用基线** |
| OSPRay-GPU（SYCL/oneAPI）| 仅 Intel Arc/数据中心卡 | ✅ | ❌ | Intel 独显 |
| ANARI + VisRTX（OptiX）| 仅 NVIDIA | ✅ | ❌ | N 卡 |
| AMD GPU 体渲染+ESS | — | — | ❌ 无成熟方案 | — |

**结论**：没有"同时 N/A 卡的 GPU-ESS"。**面向未知客户机，OSPRay-CPU 是最稳通用选择**（免显卡、ESS、质量不降）。

## 4. 渲染后端架构（多后端 + 自动适配 + 手动覆盖 + 兼容灰掉）

### 4.1 用户可见选项（按硬件/结果命名，不暴露库名）
| 用户看到 | 背后实现 | 适配硬件 |
|---|---|---|
| **自动（推荐）** | 探测后选下面之一 | — |
| GPU 加速（N卡）| ANARI + VisRTX | NVIDIA 独显 |
| GPU 加速（Intel）| OSPRay-GPU | Intel Arc 独显 |
| CPU（通用，免显卡）| OSPRay-CPU | 任意 CPU |
| 通用 GPU（兼容）| OpenGL（现状 mapper）| 任意 GPU（兜底）|

### 4.2 自动探测逻辑
```
if NVIDIA 独显:           → VisRTX(GPU)
elif Intel Arc 独显:       → OSPRay-GPU
elif AMD(独显/核显) 或 Intel 核显 或 无显卡 或 探测失败:
                           → OSPRay-CPU（默认）  // 核显一律走 CPU：弱+共享内存+多不被GPU后端支持
// 强力 A 卡可手动选"通用 OpenGL"用其 GPU(无 ESS)，但不作默认
```
- **手动覆盖**：用户可自选，但**只列出与当前硬件兼容的项**（不兼容灰掉，如 A 卡上禁 VisRTX）。
- **集显建议**：一律 OSPRay-CPU（CPU+ESS 比让弱核显硬渲更稳更快）。

### 4.3 部署策略（一句话）
**OSPRay-CPU 保底通用；探测到 N卡/Intel Arc 时升对应 GPU 后端；A 卡/核显吃 CPU 基线；OpenGL 终极兜底。**

## 5. 上 ESS 后端后，废弃哪些
- ❌ **装箱单体(binning)**：当初为绕 OpenGL 无 ESS 才提（代价=丢"逐线分开"）。ESS 后端让**逐线分开
  的多体也快** → 不需要装箱。**逐线分开 + 不造假 + 不卡，三者兼得。**
- ❌ **交互降质权宜**（屏幕/沿光线步长加粗）：ESS 后端有自带的自适应/渐进式细化，基本不用；保留作任何后端的兜底。
- ❌ 自写 ESS shader / 预积分 / UseDepthPass：后端自带，无需自行实现。
- ✅ **保留**："选几条 ds(≤7)" 是使用方式（非技术），永远有效。

## 6. 实现要点（工程）
- VTK 需**重编**带：`RenderingRayTracing`(OSPRay)、`RenderingAnari`(ANARI/VisRTX) 模块 + 依赖
  （OSPRay/Embree/ISPC/OpenVKL；ANARI-SDK/VisRTX）。用户已确认工程量无所谓。
- 渲染层抽象一个 `IVolumeRenderBackend`，运行时按 §4 选具体 mapper：
  `vtkGPUVolumeRayCastMapper`(OpenGL) / `vtkOSPRayPass`+volume / `vtkAnariPass`+volume。
- **数据不变**：逐线密体（含通道插值，spec 前一份）原样喂各后端；多体合成由后端负责（无 K=7 分包）。
- 硬件探测：GL_VENDOR / 平台 API（DXGI 枚举适配器）判 N/A/Intel + 独显/核显。

## 7. POC 计划（先验"CPU+ESS 够不够快"——最通用、风险最低）
1. **POC-1（先做）**：最小程序，用 **OSPRay-CPU** 渲一个 GPR 密体（tmp/lines_all_dense 里一条/几条），
   **实测普通 CPU 上对多体/密体的 fps + ESS 提速比**，对照现状 OpenGL。先确认 OSPRay 在本环境
   可编可跑、CPU+ESS 实际够快——这是整套方案值不值得上的关键闸门。
2. **POC-2**：若有 N 卡，ANARI+VisRTX 渲同一体，对照 GPU 提速。
3. POC 通过 → 才动手重编 VTK + 接后端抽象层。

## 8. 风险 / 待定
- OSPRay-GPU（Intel）较新、不如 CPU 路成熟；ANARI/VisRTX 需 NVIDIA 驱动 + VisRTX 库。
- 各后端传函/外观与 OpenGL 有差异，需重新调一致。
- 本环境能否编出带光追/ANARI 的 VTK（vcpkg/手动依赖）待 POC-1 验证。
- CPU+ESS 在低核机上的实际帧率待实测。

## 9. 验收
1. 客户机无论有无显卡/何种显卡，自动选到可跑的后端并出图（OSPRay-CPU 永远兜底）。
2. 20 条密体总览：逐线分开、不造假、**ESS 后端下不卡**（目标交互 ≥ 可用帧率，质量不降）。
3. 手动选项只列兼容项；集显默认 CPU。
4. 数据层（通道插值密体）零改动复用。