Chapter 60: Acceleration Strategy Comparison
空间加速结构的选择，最终回答一个工程问题：给定一帧里的几何、运动、查询类型和执行平台，应该用哪种结构把无关对象尽快排除，把真正需要测试的候选集稳定压小。本章把 BVH、KD-Tree、Octree、regular grid、hierarchical grid 和场景图索引放在同一条判断链上比较，目标是让读者能定位查询瓶颈、判断结构适配度、设计混合结构，并用指标验证选择是否成立。
本章贯穿材料是一帧复杂大场景：城市街区中有静态建筑、可复用窗框和路灯实例、穿行车辆、路边树木、室内房间、烟雾体素、雨滴粒子和少量反射射线查询。这个场景同时包含静态与动态对象、稀疏与密集区域、ray query 与 collision query、CPU 组织与 GPU 执行。单一结构很难覆盖全部需求，比较过程必须从数据分布、查询形态、更新频率和硬件路径一起判断。
加速结构的共同目标是减少候选测试。原始做法会让每条射线、每个碰撞体或每次可见性查询扫描大量对象；加速结构通过包围盒、空间格子、层级节点或索引表把候选范围缩小。Vulkan 的 VK_KHR_acceleration_structure 也把加速结构放在“快速找出可能被射线命中的 primitive”这个语境中描述，说明加速结构本身服务于查询路径，而查询路径最终服务于一帧图像或一次仿真结果。
选择结构时应先问四个问题：对象是否经常移动，空间分布是否均匀，查询是否需要最近命中，执行位置在 CPU 还是 GPU。答案会直接改变数据布局、构建方式、更新策略和调试证据。本章后续每节都回到这帧城市场景，用同一组问题比较结构，而非把每种结构孤立讲成术语表。
60.1 空间加速结构的核心思想对比
空间加速结构的第一层差异，是它按对象组织数据，还是按空间组织数据。对象划分以 primitive、mesh、instance 或物体包围盒为中心；空间划分以坐标范围、切分平面、格子或层级 cell 为中心。两者都在减少候选测试，但它们承担的代价位置不同：对象划分把复杂度放进包围体层级，空间划分把复杂度放进区域切分和对象归属。
对象划分的代表是 BVH。BVH 把对象包围盒递归分组，父节点包住子节点，叶子节点持有一个小范围 primitive 或对象引用。射线、AABB 或 frustum 查询从根节点进入，先测试包围盒，再进入可能命中的子树。它的关键收益来自“包围盒命中才继续向下”，因此在形状不规则、密度变化明显、实例数量大、几何尺寸差异大的场景中表现稳定。城市街区里的建筑、车辆、树木和路灯实例适合进入 BVH 或 TLAS/BLAS 结构，因为这些对象天然有边界，且可以按实例和网格拆分。
空间划分的代表是 KD-Tree、BSP 和规则网格。KD-Tree 用轴对齐平面把空间递归切开，每个节点表示一个空间区域；regular grid 把空间切成同尺寸 cell；hierarchical grid 或 octree 则把 cell 继续分层。空间划分的收益来自“查询路径只穿过有限区域”，因此在对象位置可预测、空间范围明确、查询局部性强时效果好。雨滴粒子的邻域查询适合 hash grid，烟雾体素适合 sparse grid 或 clipmap，室内房间适合 cell/portal 与局部 BVH 配合。
regular grid 的核心变量是 cell size。cell 过大，单个 cell 的候选列表会变长；cell 过小，查询会跨过大量空 cell，内存索引也会变重。它适合粒子、碰撞 broad phase、体素采样、地形局部查询这类“对象数量多、查询半径稳定、分布相对均匀”的工作。城市街区里的雨滴和近地小碎片可以按格子批处理，因为每个粒子只关心附近粒子或附近碰撞体。
hierarchical grid 和 octree 处理尺度差异。层级结构用大 cell 覆盖稀疏远处，用小 cell 覆盖密集局部。它保留 regular grid 的空间定位能力，同时降低单一 cell size 对全场景的约束。城市远景建筑块可以放在粗层级，街边树叶、雨滴、局部体素可以放在细层级；查询从粗层级定位区域，再进入局部细结构。
这些结构的共同输入是对象边界、空间范围、查询类型和更新策略。共同输出是候选集合、最近命中、可见对象列表、碰撞候选对或采样路径。结构选择的差异主要体现在候选集质量、构建成本、更新成本、内存布局和 GPU 并行度。
| 结构类型 | 数据组织中心 | 适合查询 | 主要成本 | 城市场景中的位置 |
|---|---|---|---|---|
| BVH | 对象包围盒和层级分组 | ray query、frustum、碰撞候选 | 构建、refit 退化、节点访问 | 建筑、车辆、树木、实例网格 |
| KD-Tree | 轴对齐空间切分 | 静态 ray query、点查询、最近查询 | 静态构建、跨平面对象处理 | 静态室内模型、离线查询 |
| Regular Grid | 固定 cell | 粒子邻域、局部碰撞、体素采样 | cell size 选择、空 cell、密度失衡 | 雨滴、碎片、近地动态小物体 |
| Octree | 递归空间八分 | 稀疏体素、层级占用、范围查询 | 节点管理、稀疏更新、层级跳转 | 烟雾体素、城市块 streaming |
| Hierarchical Grid | 多尺度 cell | 多尺度动态对象、局部查询 | 多层索引、对象迁移 | 车辆、粒子、远近尺度混合 |
| Scene Graph Index | 逻辑节点、变换和资源引用 | 场景组织、变换更新、提交列表 | 脏标记传播、同步空间索引 | 编辑器、资产层级、渲染队列入口 |
比较这些结构时，要把 scene graph 放在正确位置。场景图负责表达对象关系、变换继承、组件和资源引用；空间加速结构负责查询候选。场景图里的一个建筑节点可以拥有 transform 和 mesh reference，但 ray query 需要进入建筑的 BLAS 或局部 BVH。场景图可以触发空间索引更新，却不直接替代空间索引的查询能力。
贯穿场景中，单一 BVH 可以覆盖大量静态几何，但雨滴粒子使用 BVH 会带来频繁重建；单一 grid 可以处理粒子，却会让高楼、室内和稀疏远景产生大量空 cell 或过长候选列表。核心比较结论是：结构的组织中心必须匹配主要查询路径。对象边界清楚时优先对象层级，空间局部性强时优先空间切分，尺度差异明显时引入层级或混合结构。
60.2 使用场景与选择策略指南
结构选择应按四个维度推进：静态与动态、稀疏与密集、ray query 与 collision query、CPU 与 GPU。每个维度都对应可观察证据。静态与动态看 transform、拓扑和对象集合变化；稀疏与密集看单位空间内对象数和空区域比例；查询类型看是否需要最近命中、是否允许粗候选；执行平台看内存布局、并行批量、分支发散和同步成本。
静态几何优先使用构建质量高的结构。城市建筑主体、地面、桥梁和室内固定墙体几乎不改变拓扑，构建成本可以摊销到多帧或加载阶段。此时 SAH BVH、KD-Tree、portal/cell 加局部 BVH 都有价值，重点指标是 node visits、primitive tests、cache locality 和 memory footprint。只要构建时间不进入每帧预算，高质量结构通常能降低长期查询成本。
动态对象优先使用更新成本可控的结构。车辆、行人替身、树枝风动画、可破坏小物体和粒子每帧移动，完整重建高质量树会占用 CPU 或 GPU 构建时间。常用做法是把动态对象放在 TLAS、dynamic BVH、loose grid、hierarchical grid 或 hash grid 中；底层静态 mesh 保持稳定，外层实例或 cell 索引按帧更新。对 skinned mesh 和变形网格，可以选择 refit BLAS、粗包围盒更新或把精确 ray query 推迟到需要时执行。
稀疏场景优先让空区域低成本通过。城市远景、山地地形、稀疏建筑群和大范围可视化数据中，空间大但对象少。regular grid 如果覆盖完整范围，会产生大量空 cell；BVH、octree、sparse grid、clipmap 或 streaming tile 更适合把有效区域压成稀疏表示。判断证据是空 cell 比例、cell list 长度、节点访问数和 streaming page 命中率。
密集均匀场景优先让局部查询批量化。雨滴粒子、草叶碰撞、布料点邻域、流体粒子和体素块通常数量大、查询半径稳定、数据分布局部连续。hash grid、uniform grid、prefix-sum cell list 或 tiled GPU buffer 可以让邻域查询变成连续内存扫描。此时过深树结构会引入分支和栈操作，GPU warp 或 SIMD lane 容易走不同路径。判断证据是每个 cell 的平均对象数、最大对象数、邻域 cell 扫描次数和内存访问连续性。
ray query 与 collision query 的候选质量要求不同。ray query 常需要最近命中，遍历顺序、包围盒距离排序和 early exit 影响很大；shadow ray 只需要知道是否有遮挡，any-hit 路径可以在第一个有效命中后结束。collision broad phase 通常只要产生候选对，允许 false positive 进入 narrow phase。AABB overlap、sphere overlap 和 sweep test 更适合 grid、dynamic BVH 或 sweep-and-prune；高质量反射射线和 path tracing 查询更偏向 BVH 或硬件 acceleration structure。
CPU 与 GPU 的结构取舍也不同。CPU 能处理复杂指针、递归、动态分配和分支逻辑，但缓存 miss 会迅速放大成本；GPU 偏好结构化 buffer、连续节点数组、批量构建、批量查询和相似控制流。GPU 上的 BVH 遍历通常需要关注节点布局、栈深度、ray coherence 和内存带宽；GPU grid 更关注 prefix sum、cell range、排序键和线程组分配。把 CPU 友好的树原样搬到 GPU，常见结果是分支发散和随机内存访问开销上升。
选择过程可以写成一条可复用判断路径。下面的图只覆盖本章讨论的结构层级，具体 API 对象和 shader 实现由后续渲染管线章节展开。
这条路径的关键点是先固定主要查询。反射射线主导时，最近命中和遍历顺序决定结构；粒子碰撞主导时，邻域 cell 和候选对数量决定结构；streaming 城市主导时，空间分页和对象迁移决定结构。结构名称只在查询目标明确之后才有意义。
在贯穿场景里，静态建筑使用 BLAS 或局部 BVH，城市块使用 TLAS 或 streaming tile 索引，车辆使用动态实例层，雨滴使用 hash grid，烟雾体素使用 sparse grid 或 clipmap，室内可见性使用 cell/portal 与局部 BVH。这个组合来自查询拆分，而非来自对某一种结构的偏好。
60.3 混合结构组合应用技巧
复杂场景的加速策略通常是混合结构。混合结构的目标是把不同更新频率、不同查询类型和不同数据尺度拆到不同层级中处理，再用明确的边界连接起来。边界可以是 instance、tile、room、streaming chunk、LOD group、particle cell 或 volume brick。每个边界都要说明谁负责构建，谁负责更新，查询从哪里进入，命中结果如何映射回原始对象。
TLAS/BLAS 是图形工程中常见的对象层级拆分。BLAS 表示底层几何，例如一栋建筑的三角形、一辆车的车身 mesh、一棵树的枝叶 mesh；TLAS 表示实例层，例如建筑实例、车辆实例、树木实例及其 transform。BLAS 适合随资源加载构建和复用，TLAS 适合随场景实例变化更新。反射射线先遍历 TLAS 找到可能实例，再进入对应 BLAS 找 primitive。这个拆分让静态网格质量和动态实例更新分别优化。
grid within BVH 适合局部密集数据。城市街道整体可以放在 BVH 或 tile index 中，但每个街区内的雨滴、碎片、虫群或粒子喷泉使用局部 grid。查询先用 BVH 找到街区或特效对象，再进入该对象内部的 grid 做邻域查询。这样可以让全局结构保持稀疏，让局部结构处理高密度动态数据。
octree streaming 适合大范围稀疏体数据和分块世界。烟雾、云层、体素建筑预览和地形数据常按 brick 或 chunk 存储。octree 或 sparse voxel hierarchy 负责判断哪些区域存在数据，streaming system 负责加载、卸载和压缩，GPU buffer 只保留当前视野和当前查询需要的 brick。查询路径先从粗层级定位 active brick，再执行 DDA 或 ray marching。性能证据来自 active brick 数量、page miss、上传字节数和采样步数。
scene graph index 适合把逻辑组织和空间查询解耦。编辑器里用户看到的是父子节点、组件、资源和层级 transform；渲染器需要的是 visibility list、render queue、ray tracing instance buffer 和 collision broad phase。稳定设计是让 scene graph 作为源数据，变换脏标记驱动空间索引更新。空间索引保存可查询副本，例如 world bounds、instance id、mesh id、material id 和 layer mask。查询返回 id，再由 scene graph 或 ECS 查回对象语义。
混合结构的难点在同步和所有权。一个对象进入 scene graph 后，通常还会进入可见性结构、碰撞结构、ray tracing structure 和 editor selection index。每份索引都持有不同粒度的数据。稳定做法是定义一个统一的 bounds update 阶段：先更新 local transform 到 world transform，再更新 world AABB，再把脏对象分发到对应索引。这样可以减少索引之间的状态错位。
下面是一帧更新到查询的简化路径。图中每个索引只持有自己需要的数据，最终 draw list 或 hit result 通过对象 id 回到场景对象。
这条路径说明，混合结构需要共享输入事实，各索引无需共享同一棵树。world bounds 是可见性、射线和碰撞都能使用的公共事实；各索引用它生成自己的查询结构。这样可以让 ray query 使用 TLAS/BLAS，让碰撞使用 dynamic BVH 或 grid，让可见性使用 frustum culling、occlusion 和 LOD list。
混合结构还要设置回退路径。TLAS 更新失败或超预算时，可以使用上一帧结构加 expanded bounds，代价是候选集变大；局部 grid 过密时，可以把 cell 拆分到下一层或改用局部 BVH；streaming chunk 未加载时，可以使用粗 LOD bounds 或保守遮挡状态。回退路径要在调试视图中可见，例如显示 expanded bounds、dirty nodes、unloaded brick 和 fallback LOD。
在贯穿场景中，一个可落地组合是：城市 tile 用 streaming index 管理，tile 内静态建筑用 BLAS，场景实例用 TLAS，车辆进入 dynamic TLAS 或 dynamic BVH，粒子进入 hash grid，烟雾进入 sparse volume hierarchy，室内房间进入 portal/cell index。这个组合把“城市大范围定位、静态几何命中、动态实例更新、粒子邻域、体素采样、室内可见性”拆成独立问题，调试时也能分别看指标。
60.4 性能评估指标体系与分析方法
性能评估要把构建、更新、查询、内存、带宽、并行度和调试成本分开记录。只看一帧总耗时会掩盖真实瓶颈：构建慢、查询慢、节点访问多、cell 失衡、GPU 内存带宽高、CPU 同步等待、调试成本高，都会表现为帧时间上升。指标体系的作用是把“结构选错”定位到具体路径。
构建时间衡量结构从输入对象到可查询索引的成本。静态建筑 BVH 的构建时间可以发生在加载阶段；动态 TLAS、particle grid 和 dirty region index 的构建或更新时间会进入每帧预算。记录时应拆成 input bounds 生成、排序或分桶、节点分配、GPU upload、scratch buffer 使用和最终 compact。对于 Vulkan、DXR、Metal 等显式 API，acceleration structure build 还涉及 scratch memory、barrier 和 build flag，工具证据应能指出 build pass 占用哪个队列和哪个时间段。
更新时间衡量结构对变动的响应成本。refit 只更新节点 bounds，rebuild 重新生成结构，partial rebuild 只处理脏区域。refit 便宜，但对象移动过大时树质量会下降，表现为 node visits 增加和 primitive tests 增加。dynamic grid 的更新时间通常是对象重新计算 cell key、排序、prefix sum 和写入 cell range。评估时要同时看 update time 与查询退化，单独记录 update time 会漏掉结构质量下降。
查询次数和单次查询成本要一起看。射线数量少但每条射线遍历很深，瓶颈在结构质量；射线数量巨大但每条很短，瓶颈可能在内存带宽和分支发散；粒子邻域查询中，平均 cell 对象数低但最大 cell 爆炸，瓶颈会集中到少量热点 cell。常用指标包括 rays per frame、node visits per ray、primitive tests per ray、cell steps per ray、candidate pairs、false positive ratio 和 nearest-hit early exit ratio。
内存和带宽决定 GPU 路径是否稳定。BVH 节点通常需要 bounds、child index、primitive range 或 instance id；grid 需要 cell range、object index、sorted keys；octree 需要节点 mask、child pointer 或 compact child index；volume hierarchy 需要 brick metadata 和 texture page。内存占用太大，会压缩其他渲染资源的预算；访问不连续，会增加带宽和 cache miss。GPU 上应关注 node buffer 读取量、index buffer 读取量、cell list 扫描长度、texture page 访问和 compaction 后大小。
并行度衡量结构是否适合批量执行。GPU 查询最怕每个线程走完全不同的路径。相干射线、相邻屏幕像素、同类粒子和同区域碰撞对象有利于批量执行；分布混乱的 secondary rays、极端稀疏 cell、深度差异大的树路径会放大发散。评估时可以把查询按 ray type、screen tile、object type 或 spatial tile 分组，比较分组前后的执行时间和访问模式。
调试成本也是评估指标。一个结构即使平均性能好，如果无法解释错误命中、漏命中、候选爆炸或更新延迟，就很难用于大型工程。调试视图应能显示 bounds、node depth、cell occupancy、dirty regions、streaming pages、LOD selection、candidate pair count 和 query path。RenderDoc、Nsight、Xcode GPU tools 等工具可以观察 draw call、buffer、shader cost 和带宽，但工程还需要自定义 overlay 把空间结构本身画出来。
评估流程可以按固定顺序执行。先固定一帧或一组 benchmark 场景，再冻结相机、对象数量和查询数量；随后记录 build/update/query 三段时间；再记录候选质量指标；最后打开调试视图检查空间分布。若结构 A 比结构 B 快，需要说明它在哪个环节快：build 少、query 少、内存读少、发散低，还是候选质量高。这样得到的结论才可以迁移到同类场景。
下面的指标表可以作为本章最小基线。真实工程可以追加平台相关指标，但这组指标已经能覆盖大部分结构比较。
| 指标 | 回答的问题 | 典型证据 | 结构选择含义 |
|---|---|---|---|
| Build Time | 构建是否进入预算 | ms、scratch size、upload bytes | 静态结构可更高质量，动态结构需轻量 |
| Update Time | 变动是否便宜 | dirty count、refit ms、rebuild ms | 动态对象需要 TLAS、grid 或 partial rebuild |
| Query Cost | 查询是否被有效缩小 | node visits、cell steps、primitive tests | 候选质量决定结构收益 |
| Memory Footprint | 结构是否占用过多资源 | node bytes、cell bytes、metadata bytes | 稀疏场景需要压缩或分页 |
| Bandwidth | GPU 访问是否连续 | buffer reads、cache miss、texture page access | 线性布局和批量排序影响性能 |
| Parallelism | 批量执行是否稳定 | divergence、occupancy、group time | GPU 更偏好相干查询和固定格式 |
| Debug Cost | 错误是否可定位 | overlay、counter、capture marker | 大场景需要可解释结构 |
用这组指标复盘贯穿场景，可以得到清晰判断。建筑 BLAS 的 build time 可接受，query cost 低；车辆 TLAS update time 小，refit quality 需监控；雨滴 hash grid 的 bandwidth 和 cell occupancy 是关键；烟雾 sparse hierarchy 的 page miss 和 upload bytes 是关键；室内 portal/cell 的 debug cost 和漏可见风险需要重点观察。
60.5 复杂大场景中的加速表现对比
复杂大场景的结构选择来自场景类型和主查询。城市、森林、室内、粒子场和体素数据看似都需要“加速”，但它们的数据分布和查询目标完全不同。城市强调 streaming、实例复用和大尺度遮挡；森林强调大量相似实例和风动画；室内强调房间连通、门洞、遮挡和局部可见性；粒子场强调邻域和高并行；体素数据强调稀疏占用、层级采样和分页。
城市场景适合 tile index 加 TLAS/BLAS。城市可以按街区、道路网格或 streaming cell 分块；每个 tile 持有建筑、道路、灯杆、标牌和静态装饰的实例。静态 mesh 构建 BLAS，tile 或全局场景构建 TLAS，动态车辆单独进入动态实例层。可见性查询先按 camera frustum 和 occlusion 过滤 tile，再生成 draw list；ray query 先穿过 TLAS，再进入命中实例的 BLAS。指标重点是 active tile 数、TLAS update time、instance count、ray node visits 和 streaming upload bytes。
森林场景适合实例层级加局部网格或层级 cell。树木数量多、形状复杂、远近尺度差异大，且风动画会改变叶片或枝条的 bounds。稳定做法是树种 mesh 复用 BLAS，单棵树作为 instance 进入 TLAS，森林区域按 grid 或 quadtree 分块，远处用 billboard 或 impostor。碰撞和风场采样可以使用局部 grid，ray query 使用实例层级。指标重点是 instance culling ratio、LOD 切换、叶片 alpha 测试成本、TLAS update 和 per-region occupancy。
室内场景适合 cell/portal 加局部 BVH。房间、走廊和门洞构成强拓扑约束，相机常位于一个房间或相邻少数房间。portal/cell 可以先限制潜在可见房间，局部 BVH 再处理房间内的家具、墙面和装饰。反射、阴影和拾取查询进入局部 BVH 或全局 TLAS；编辑器选择可以沿 scene graph id 回查对象。指标重点是 visible cell 数、portal 递归深度、局部 BVH 查询成本和漏可见测试。
粒子场适合 uniform grid、hash grid 或 tiled cell list。粒子数量大，查询半径通常稳定，目标是快速找到附近候选。GPU 路径常把粒子位置映射到 cell key，排序后生成 cell range，再让每个粒子扫描邻近 cell。这个结构适合碰撞、SPH 流体、雨滴聚合、局部光照采样和屏幕空间交互。指标重点是 cell occupancy、热点 cell、排序时间、prefix sum 时间、neighbor count 和内存带宽。
体素数据适合 sparse voxel、octree、clipmap 或 brick hierarchy。体素云、烟雾、医学数据、地形密度场和破坏体积通常空间大、有效区域稀疏、采样路径长。结构要先快速跳过空区域，再进入 active brick 做采样。ray marching 可以结合 occupancy mip、DDA、空空间跳跃和分辨率层级。指标重点是 active brick 数、empty-space skip ratio、page miss、sample steps、texture bandwidth 和上传字节。
下表把这些场景放在同一组维度中比较，方便迁移到真实项目。
| 场景类型 | 主数据特征 | 主查询 | 推荐组合 | 首要指标 |
|---|---|---|---|---|
| 城市 | 大范围、实例多、静态主体多 | 可见性、ray query、streaming | Tile index + TLAS/BLAS + dynamic layer | active tile、TLAS update、streaming bytes |
| 森林 | 大量相似实例、远近尺度差异 | 可见性、阴影、碰撞 | Region grid + instance TLAS + LOD | culling ratio、LOD cost、instance count |
| 室内 | 房间拓扑强、遮挡明显 | 可见性、拾取、反射 | Cell/portal + local BVH | visible cell、portal depth、local query cost |
| 粒子场 | 数量大、局部邻域稳定 | collision、neighbor、compute | Hash grid + sorted cell list | cell occupancy、sort time、bandwidth |
| 体素数据 | 稀疏体积、采样路径长 | ray marching、volume sampling | Sparse voxel + brick hierarchy + clipmap | skip ratio、page miss、sample steps |
复杂场景里还要区分画面瓶颈和结构瓶颈。一个城市帧的 ray query 变慢，原因可能是 TLAS update 超预算，也可能是 BLAS 质量低、反射射线不相干、材质 shader 成本高或 streaming page 缺失。结构评估只能解释候选生成和遍历路径；最终画面时间还包含 shading、texture sampling、post-processing、sync 和提交成本。排查时先用结构指标确认候选路径，再结合 GPU capture 看 shader 与带宽。
本章最终建立的判断是：加速策略选择是一条从场景事实到查询路径的工程推导。先确定对象是否移动、空间是否均匀、查询是否需要最近命中、执行是否在 GPU；再选择对象划分、空间划分、规则格子或层级结构；最后用 build/update/query/memory/bandwidth/debug 指标验证。结构名称本身不给结论，结构与一帧数据路径的匹配关系才给结论。
最小自检任务
给定一帧场景：一个开放城市街区包含 800 栋静态建筑、120 辆每帧移动的车辆、20 万个雨滴粒子、几段室内空间、一个稀疏烟雾体积。渲染器需要支持相机可见性剔除、鼠标拾取、少量屏幕反射 ray query、车辆碰撞 broad phase、雨滴邻域查询和烟雾 ray marching。请为这个场景设计一套混合加速结构，并说明你会记录哪些指标验证它。
答案要点
静态建筑应构建 BLAS 或局部 BVH，并由城市 tile index 或 TLAS 管理实例；车辆应放入动态实例层、dynamic BVH 或 hierarchical grid，更新指标看 TLAS/update time、dirty count 和 refit quality；雨滴粒子应使用 hash grid 或 uniform grid，指标看 cell occupancy、sort time、neighbor count 和 bandwidth；室内空间应使用 cell/portal 加局部 BVH，指标看 visible cell、portal depth 和局部查询成本；稀疏烟雾应使用 sparse voxel、brick hierarchy 或 clipmap，指标看 active brick、page miss、skip ratio 和 sample steps。整体评估顺序是先冻结场景和查询数量，再拆分 build、update、query 时间，随后检查候选质量、内存占用、GPU 带宽和调试 overlay。
本章知识点总结
- 选择主线：加速策略应从场景数据、查询类型、更新频率和执行平台共同推导。
- 对象划分：BVH 按对象包围盒分组，适合几何边界清楚、形状不规则和 ray query 主导的场景。
- 空间划分：KD-Tree、grid 和 octree 按区域组织数据，适合空间局部性强或体素占用明确的查询。
- 网格粒度：regular grid 的 cell size 决定候选列表长度、空 cell 比例和内存访问形态。
- 层级结构：hierarchical grid 和 octree 用多尺度 cell 处理稀疏空间和对象尺度差异。
- 场景图边界：scene graph 负责逻辑关系和变换来源，空间索引负责候选查询。
- 动态更新：动态对象更适合 TLAS、dynamic BVH、hash grid 或 partial rebuild 路径。
- 查询差异：ray query 重视最近命中和遍历顺序，collision broad phase 重视候选对数量和 false positive ratio。
- GPU 适配：GPU 结构应优先使用连续 buffer、批量查询、相干分组和可预测控制流。
- 混合结构：TLAS/BLAS、grid within BVH、octree streaming 和 scene graph index 可以把不同频率的数据拆开处理。
- 指标体系：build time、update time、query cost、memory footprint、bandwidth、parallelism 和 debug cost 应分开记录。
- 大场景判断：城市、森林、室内、粒子场和体素数据需要按主查询选择不同结构组合。
- 验证顺序：先固定场景和查询，再测构建、更新和查询，最后用候选质量和调试视图解释性能变化。
- 最终结论：结构名称不直接决定性能，结构与一帧数据路径的匹配关系决定加速效果。