SIGGRAPH 2026 技术分享解读：A Hybrid BVH Structure for Interactive GPU Ray Tracing
作者：Andrew Bauer、Yining Karl Li｜Walt Disney Animation Studios
摘要
实时光线追踪里的 BVH 往往面临一个两难：拆成大量 BLAS，局部更新和实例化很方便，却会增加遍历开销；把全场景合成一个 Mega-BLAS，光线遍历更快，但任何局部修改都可能触发整棵结构重建。SIGGRAPH 2026 上，迪士尼动画公开了一套用于 DCC 视口的 Hybrid BVH：实例对象继续使用两级 BVH，非实例对象则按历史变化模式分进三个 Mega-BLAS，分别采用复用、refit 和 rebuild。它没有发明一种新的 BVH 构建算法，而是把场景分类、更新策略与 GPU 加速结构组织成一个更适合制作流程的系统。
关键词： SIGGRAPH 2026、BVH、GPU 光线追踪、OptiX、实时渲染、DCC、WebGPU
动画师调一个角色动作时，最怕的可能不是画面不够精细，而是每拖动一下时间轴，视口就停顿一下。
离线渲染器可以花几分钟甚至几小时生成一帧，但 DCC 视口面对的是另一种问题：场景已经复杂到需要光线追踪才能提供足够有参考价值的预览，同时几何体、动画和拓扑又在不断变化。渲染器不仅要"追得快"，还必须"改得快"。
迪士尼动画在 SIGGRAPH 2026 分享的 A Hybrid BVH Structure for Interactive GPU Ray Tracing ，解决的正是这个生产问题。它服务于迪士尼内部的交互式 GPU 光线追踪器，用来在 DCC 视口中提供比传统光栅化更高质量的预览；目标不是完全复刻最终帧，而是在动画播放和几何编辑时保持流畅反馈。项目页｜论文 PDF
图 1：左侧为唯一 BLAS 可视化，中间为交互式光追画面，右侧为唯一场景对象可视化。来源：Bauer 与 Li，SIGGRAPH 2026。
为什么 BVH 会成为交互式光追的瓶颈
BVH（Bounding Volume Hierarchy，层次包围盒）本质上是在回答一个问题：一条光线射入场景后，怎样尽可能少地检查三角形？
渲染器用包围盒把几何体逐层组织成树。光线如果连父节点的包围盒都没有碰到，就可以跳过其下的整片几何。问题在于，BVH 的"树长什么样"不仅决定光线遍历速度，也决定场景变化后要付出多少更新成本，而两者经常互相冲突。
方案一：两级 BVH
常见硬件光追结构会为每个对象建立一个底层加速结构 BLAS，再由场景级的顶层结构 TLAS 或 IAS 引用这些 BLAS。
它的优势很明确：
- 一个角色的网格发生变形，只需要 refit 或重建这个角色自己的 BLAS，再更新顶层 IAS；
- 同一棵树、同一把椅子出现几百次时，可以共享一份几何和 BLAS，仅保存不同实例变换；
- 局部编辑不会牵连整个场景。
但生产场景可能被拆成海量小对象。每个 BLAS 都有固定管理和遍历成本；不同对象的包围盒还可能严重重叠，让一条光线进入多个 BLAS 后才能发现其中大部分并不真正相交。论文指出，Hyperion 的离线渲染器可通过 partial re-braiding 缓解重叠问题，但这又会让交互式构建和更新流程变得更复杂。
方案二：Mega-BLAS
另一种极端做法，是把场景几何合并到一个巨大的 BLAS 中。
这样做消除了大量小 BLAS 的固定开销，也让构建器可以直接从全局空间关系出发组织几何，因此遍历性能非常好。论文还指出，配合 HLBVH 一类 GPU 构建算法，大型结构的构建并不一定慢得不可接受。
代价也同样极端：
- 只改一个对象，也可能要重建整个 Mega-BLAS；
- 添加、删除、移动对象都会扩大更新范围；
- 实例必须复制几何，实例越多，显存成本越高；
- 构建大 BLAS 需要大块临时 scratch memory，显存峰值可能远高于构建完成后的常驻占用。
于是问题变成：能否让适合实例化的对象继续走两级结构，同时让剩余对象享受 Mega-BLAS 的遍历优势？
迪士尼的答案：不是一种 BVH，而是一套分类策略
Hybrid BVH 的第一条规则非常直接：
只要一个场景对象拥有两个或更多实例，就继续使用两级 BVH；其余非实例对象才进入 Mega-BLAS。
场景级 IAS 最终同时引用两类内容：一类是普通实例对象的 BLAS，另一类是若干 Mega-BLAS 的单一实例。这样，重复出现的资产仍能共享几何，非实例对象则不再承担海量小 BLAS 的遍历开销。
真正关键的是第二条规则：非实例对象不会被粗暴地塞进同一个 Mega-BLAS，而是按照当前会话中的变化历史，分进三个桶。
| 变化类别 | 判断方式 | 典型操作 | OptiX 构建偏好 |
|---|---|---|---|
| Fully-Static | 创建后几何从未变化；新对象默认进入此类 | 尽量复用，不允许更新 | PREFER_FAST_TRACE、允许压缩 |
| Dynamic-Vertex | 顶点位置或球体半径等非拓扑数据曾发生变化 | refit 或必要时 rebuild | 允许更新、允许压缩，并偏向快速遍历 |
| Dynamic-Topology | 索引、三角形数量等拓扑曾发生变化 | rebuild | PREFER_FAST_BUILD，不允许更新和压缩 |
这里有一个很实用的工程判断：渲染器不要求资产作者提前标注"这个对象将来会怎么变"，也不完全依赖场景格式里可能缺失的 hint，而是根据本次会话已经发生过的变化做预测。
一个对象如果至今没有变化，大概率还会保持静态；一个蒙皮角色如果已经发生过顶点变形，之后大概率仍然是顶点变化；真正改过拓扑的对象，则需要为后续 rebuild 做好准备。分类不是完美预测，但在动画制作流程中足够稳定。
图 2：演示视频中的实时动画播放。作者说明每帧都会重新渲染，并使用前一帧重投影，而不是预先缓存多帧做 flipbook。来源：作者项目页演示视频。
一帧更新时，系统具体做什么
当时间轴移动到新的一帧：
- 发生变化的实例对象，只更新自己的 BLAS；顶点变化可以 refit，拓扑变化需要 rebuild。
- 非实例对象若改变了历史类别，会被移动到相应 Mega-BLAS。
- Fully-Static Mega-BLAS 若未受影响就直接复用。
- Dynamic-Vertex Mega-BLAS 执行 refit。
- Dynamic-Topology Mega-BLAS 执行 rebuild。
- 最后 refit 场景级 IAS。
这套结构的价值不只是"把三棵大树并排放着"，而是让不同变化频率和变化性质的几何体不再互相拖累：静态场景不必跟着角色每帧更新，只有顶点变形的对象也不必承担拓扑重建成本。
图 3：灰色为 Fully-Static，蓝色为 Dynamic-Vertex，红色为 Dynamic-Topology。来源：作者项目页演示视频。
实测结果：收益主要来自"更新更快"
论文选取了三个《疯狂动物城 2》的制作视口场景，在 2283×1215 分辨率下比较传统两级 BVH 与 Hybrid BVH。这里的 frame integration time 只包含单帧路径追踪，不含 BVH 更新和降噪；frame update time 则是 DCC 切到新帧后的场景处理时间。
| 场景 | 路径追踪：两级 → Hybrid | 帧更新：两级 → Hybrid | BVH 常驻显存：两级 → Hybrid | 显存峰值：两级 → Hybrid |
|---|---|---|---|---|
| Office | 5.73 → 5.35 ms | 46.16 → 15.45 ms | 99.87 → 93.31 MiB | 99.87 → 196.51 MiB |
| Can Throw | 7.80 → 6.75 ms | 33.31 → 22.36 ms | 124.84 → 95.62 MiB | 152.65 → 231.97 MiB |
| Marsh Market | 3.29 → 3.25 ms | 39.17 → 11.68 ms | 3282.59 → 1938.81 MiB | 3285.61 → 7131.22 MiB |
根据论文数据计算：
- 路径追踪部分提升约 1.2%～13.5%；
- 帧更新耗时下降约 32.9%～70.2% ，相当于约 1.49～3.35 倍的更新速度；
- 三个场景的 BVH 常驻显存都下降了；
- 但构建期显存峰值上升约 52%～117%。
这组数据非常能说明问题：Hybrid BVH 最大的价值不是把单帧光追时间砍掉一半，而是显著减少动画切帧和场景编辑造成的停顿。
对于 DCC 工作流来说，15 ms 和 46 ms 的区别不只是一个 benchmark 数字。后者叠加求值、材质更新、降噪和界面开销后，很容易变成动画师能感觉到的卡顿；前者则给其他环节留下更多帧预算。
不过，显存峰值是必须正视的代价。Marsh Market 场景的 BVH 常驻显存从约 3.28 GiB 降到约 1.94 GiB，但构建期峰值从约 3.29 GiB 升到约 7.13 GiB。Mega-BLAS 构建所需的临时内存，可能成为支持更大场景时真正的上限。
为什么这个方案很"生产级"
从算法论文的角度看，它并没有提出一种全新的 BVH 节点编码或构建器。它更像一次系统工程上的重新切分：
- 用"是否真正存在重复实例"决定是否保留 BLAS；
- 用运行时变化历史代替不可靠的资产标注；
- 用固定数量的变化类别控制复杂度；
- 让 reuse、refit、rebuild 与 OptiX 构建 flags 对齐；
- 接受偶发的一帧延迟，换取绝大多数时间里的平滑交互。
这也提醒我们：GPU-Driven 不等于"把更多代码搬进 Compute Shader"。真正决定性能的，往往是上层怎样描述数据、怎样划分生命周期，以及怎样缩小每次变化需要触碰的集合。
它的局限也很明确
论文没有把 Hybrid BVH 描述成适用于所有实时应用的银弹。
首先，对象第一次从 Fully-Static 转入 Dynamic-Vertex 或 Dynamic-Topology 时，需要重建迁出和迁入的两个 Mega-BLAS，可能产生短暂的一帧延迟。动画制作可以接受偶发停顿，但游戏或虚拟拍摄这类严格实时系统未必能接受。
其次，Mega-BLAS 会提高构建期显存峰值，也可能逼近 OptiX 的 primitive 数量限制。作者计划探索空间分区，把全局 Mega-BLAS 进一步拆成局部 Mega-BLAS，以降低 scratch memory、缩短类别迁移延迟，并控制单棵结构规模。
再次，目前 Mega-BLAS 仅处理 mesh。毛发、曲线服装和曲线植被仍回退到标准两级 BVH。对《疯狂动物城》这类毛发密集的制作来说，这不是一个小问题，而是作者明确列出的后续重点。
最后，论文测试的是面向动画师的 DCC 视口数据，并非最终帧拥有的完整生产数据；三页 Talk 论文也没有公开具体 GPU、primitive 数量和完整帧耗时。因此，我们不能把这些毫秒数直接外推到游戏、Web 或其他渲染器。
结语
Hybrid BVH 最值得关注的地方，不是"迪士尼又造了一棵更快的树"，而是它承认不同几何体有完全不同的变化规律。
重复资产需要实例化；静态唯一对象适合追求最佳遍历；持续变形对象适合 refit；拓扑变化对象必须为 rebuild 付费。把它们强行塞进同一种结构，才是性能问题的根源。
对现代渲染引擎而言，这也是一个很好的设计范本：数据驱动不只是把数据放进数组，而是让数据的使用方式、变化历史和生命周期直接决定执行路径。
参考资料
- Andrew Bauer, Yining Karl Li. A Hybrid BVH Structure for Interactive GPU Ray Tracing. SIGGRAPH Talks 2026, Article 57.
- 作者项目页：A Hybrid BVH Structure for Interactive GPU Ray Tracing
- Yining Karl Li：Hyperion Publications
- NVIDIA：Best Practices for Using NVIDIA RTX Ray Tracing
- NVIDIA OptiX：OptixBuildFlags