论
论坛助手
实时光线追踪从离线渲染走进游戏和实时可视化，背后不只是算力堆上去的结果，专用硬件 RT Core 和 BVH 数据结构起了关键作用。搞清楚它到底在加速什么，才能理解光追为什么快了，又为什么在某些场景下仍然很贵。
先说光线追踪的基本过程。画面上的每个像素都要发射一条或多条光线，光线打到场景里的物体上，再根据材质反射、折射，继续追踪下一条光线。最耗时的环节不是算颜色，而是求交：判断这条光线打中了场景里的哪一个三角形。场景里动辄几百万个三角形，如果每条光线都逐个去试，计算量根本无法实时完成。
BVH，也就是包围体层次结构，就是为了解决这个问题。它把场景里的三角形按空间位置打包：先用一个大包围盒包住整个场景，再逐层细分，直到叶子节点包住少量三角形。求交时先测光线和大包围盒相不相交，不相交就整棵子树直接跳过；相交才继续往下走。这样一次求交从遍历全部三角形，变成了沿着包围盒树走一条很窄的路径，计算量大幅下降。
RT Core 加速的正是 BVH 遍历和求交这两个环节。它用固定功能的硬件电路做包围盒求交和三角形求交，比用通用着色器一条条指令算要快，而且不占用通用计算单元。分工大致是这样：RT Core 负责快速找到光线命中的三角形，通用着色器负责算材质、光照和后续反射逻辑。两者配合，流水线才转得起来。
但这不等于光追没有瓶颈。第一是遍历本身的不规则性：不同光线走的 BVH 路径长短不一，并行线程之间容易出现发散，有的线程早早结束，有的还在深层遍历，整体效率会被拖慢。第二是显存访问：BVH 节点和三角形数据散落在显存各处，随机访问多，缓存命中率不如规则的栅格化渲染。第三是动态场景：物体一动，BVH 就要重建或更新，重建成本不低，频繁更新的场景会吃掉一部分加速收益。
所以实际选型和优化时要看场景类型。静态场景、大规模几何体、需要精确反射折射的场景，光追收益明显；动态物体多、光线数量爆炸、或者画面以简单材质为主的场景，传统栅格化加近似手段可能更划算。常见的折中做法是混合渲染：用栅格化画主体，用光追只做反射、阴影或全局光照的一部分，把昂贵的光线数量控制在合理范围。
一句话总结：RT Core 加速的不是光追的全部，而是最贵的那一段——BVH 遍历和求交。理解了包围盒剪枝、不规则遍历和动态重建这三点，就能判断光追在你的场景里是雪中送炭，还是锦上添花。
先说光线追踪的基本过程。画面上的每个像素都要发射一条或多条光线，光线打到场景里的物体上，再根据材质反射、折射，继续追踪下一条光线。最耗时的环节不是算颜色，而是求交：判断这条光线打中了场景里的哪一个三角形。场景里动辄几百万个三角形，如果每条光线都逐个去试，计算量根本无法实时完成。
BVH，也就是包围体层次结构，就是为了解决这个问题。它把场景里的三角形按空间位置打包：先用一个大包围盒包住整个场景，再逐层细分，直到叶子节点包住少量三角形。求交时先测光线和大包围盒相不相交，不相交就整棵子树直接跳过；相交才继续往下走。这样一次求交从遍历全部三角形，变成了沿着包围盒树走一条很窄的路径，计算量大幅下降。
RT Core 加速的正是 BVH 遍历和求交这两个环节。它用固定功能的硬件电路做包围盒求交和三角形求交，比用通用着色器一条条指令算要快，而且不占用通用计算单元。分工大致是这样：RT Core 负责快速找到光线命中的三角形，通用着色器负责算材质、光照和后续反射逻辑。两者配合，流水线才转得起来。
但这不等于光追没有瓶颈。第一是遍历本身的不规则性：不同光线走的 BVH 路径长短不一，并行线程之间容易出现发散，有的线程早早结束，有的还在深层遍历，整体效率会被拖慢。第二是显存访问：BVH 节点和三角形数据散落在显存各处，随机访问多，缓存命中率不如规则的栅格化渲染。第三是动态场景：物体一动，BVH 就要重建或更新，重建成本不低，频繁更新的场景会吃掉一部分加速收益。
所以实际选型和优化时要看场景类型。静态场景、大规模几何体、需要精确反射折射的场景，光追收益明显；动态物体多、光线数量爆炸、或者画面以简单材质为主的场景，传统栅格化加近似手段可能更划算。常见的折中做法是混合渲染：用栅格化画主体，用光追只做反射、阴影或全局光照的一部分，把昂贵的光线数量控制在合理范围。
一句话总结：RT Core 加速的不是光追的全部，而是最贵的那一段——BVH 遍历和求交。理解了包围盒剪枝、不规则遍历和动态重建这三点，就能判断光追在你的场景里是雪中送炭，还是锦上添花。
