8.7 KiB
⚠️ 本 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）：
PlacedSource加回每线自己的vtkSmartVolumeMapper（GPU 模式）；删 multi-volume 用法 （multiMapper/multiVol/port 不再需要，但可暂留不碍）。- 装配：删
buildBundles+ 退避（无 multi-volume 即无纹理单元上限）；改为逐线mapper->SetInputData(baseImage)→volume->SetMapper(mapper)→ren->AddVolume(volume)， 各线 mapper 收进mappers向量（供质量控制）。 - 开 LOD：
gViewAllBaseOnly = false（启用引擎选区换图）；引擎换的是"改包围盒的子区域"， 各线独立 mapper 下安全（无 multi-volume 可破坏）。 - 关 channel LOD：
gChanLod = false——引擎金字塔已逐级降 Y，无需单独抽 Y 平面。 viewAllPickOneLine：ps.mapper->SetInputData(ps.currentImg); ps.mapper->Update();（非 multiMapper 端口）。- 停手才重建（已有，确认接线）：拖动中(
viewAllOnInteracting)只降质+重置裁剪、不提交引擎目标； 松手(viewAllOnInteract)/定时器 idle 才viewAllSubmitTargets（提交 LOD 目标）+viewAllPickOneLine（拉就绪区域换上）。避免 P11/P12"每帧 20 条重建上传"thrash。 - 质量旋钮保留：
--sampleDist/--maxImgSample/--dragSampleMul作 LOD 框架内的交互降质兜底。 - 总览级别：引擎
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 够不够快"——最通用、风险最低）
- POC-1（先做）：最小程序，用 OSPRay-CPU 渲一个 GPR 密体（tmp/lines_all_dense 里一条/几条）， 实测普通 CPU 上对多体/密体的 fps + ESS 提速比，对照现状 OpenGL。先确认 OSPRay 在本环境 可编可跑、CPU+ESS 实际够快——这是整套方案值不值得上的关键闸门。
- POC-2：若有 N 卡，ANARI+VisRTX 渲同一体，对照 GPU 提速。
- POC 通过 → 才动手重编 VTK + 接后端抽象层。
8. 风险 / 待定
- OSPRay-GPU（Intel）较新、不如 CPU 路成熟；ANARI/VisRTX 需 NVIDIA 驱动 + VisRTX 库。
- 各后端传函/外观与 OpenGL 有差异，需重新调一致。
- 本环境能否编出带光追/ANARI 的 VTK（vcpkg/手动依赖）待 POC-1 验证。
- CPU+ESS 在低核机上的实际帧率待实测。
9. 验收
- 客户机无论有无显卡/何种显卡，自动选到可跑的后端并出图（OSPRay-CPU 永远兜底）。
- 20 条密体总览：逐线分开、不造假、ESS 后端下不卡（目标交互 ≥ 可用帧率，质量不降）。
- 手动选项只列兼容项；集显默认 CPU。
- 数据层（通道插值密体）零改动复用。