133 lines
8.7 KiB
Markdown
133 lines
8.7 KiB
Markdown
# ⚠️ 本 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. 数据层（通道插值密体）零改动复用。
|