Windows渲染引擎开发入门教学（5）: 光线追踪基础
Sorry拖了这么久才更新，在先前的学习里我们已经学会了写出基础的光栅程序，而笔者认为，光线追踪与GPGPU现在是，且未来更是与光栅化同级，甚至更加重要的基础三角形求交方式，因此我们才与其他教程不同在这么早的时候就引入了光线追踪的理论。由于龙书编写时间早于Direct-X RayTracing的推出时间，因此直接编写DX12的学习门槛可能非常高，我们未来的实践文章可能会尽可能避免让读者直接编写底层的Direct-X就能完成学习和生产。我们将在本文学习光线追踪的基础理论。首先，是一些初学者常见的问题。为什么近几年才有了光线追踪的API标准？
其实光线追踪是十分古老的算法，甚至比光栅算法还要古老，但由于以前硬件条件限制，使用光栅化绘制少量三角的计算量和内存占用又远低于光线追踪，因此一直到近几年，GPU厂家才有余力提供光线追踪的硬件支持，因此面向硬件的相关API。
既然如此，光线追踪真的比光栅化慢吗？它真的是游戏必需品吗？
毫无疑问，这个问题的回答是肯定的。之所以说光线追踪在未来可能会逐步取代光栅化的位置，我们可以从效率和场景能见度两方面讲解。首先是效率问题，毕竟对实时渲染来说，“跑得起来”永远在最重要的位置，任何其他条件都要让步。我们做了一个简单的小实验，在这台RTX 3080 GPU上，首先导出一个面数极高的场景，约1.55亿三角面，虽没有LOD，但大多数模型都是重复的。可以看到，在3840 * 2160分辨率下，光栅化性能表现很差：
约1.55亿个三角面，光栅性能低下（光栅管线占13.5ms以上）
然后我们再以同样的分辨率，角度，使用纯粹的光线追踪渲染这个场景：
渲染法线
渲染三角形ID
相比前者，光线追踪场景的开销仅有1.1 - 1.5ms，而即使是Unreal Engine 5推出的Nanite Virtualized Geometry技术（以下简称Nanite），也只能将光栅的效率提高到硬件的2 - 3倍左右（Nanite除基础的三角求交外还有大量其他工程类功能，如自动生成LOD以及遮挡剔除等，这里仅讨论三角求交问题）。那么后者为何能做到在实打实的渲染1.55亿个三角面时，拥有每秒直逼上千帧的计算效率，以及这种碾压级的效率，代价是什么，我们稍后随着原理部分进行讲解。功能方面，常玩游戏的玩家都知道，有光追就有反射，有间接光照。而对于我们开发者来说，需要学习其原理才能知道为什么。
射线与场景求交的理论：
我们常见的射线与场景求交分两部分，加速结构和射线与三角面相交，前者顾名思义，是为了提升效率而设计，主要思路为快速剔除不可能求交的其他三角面，而后者则是在已经得到“可能相交的三角面”后进行精确的判断，这一部分理论由于前人已经写的非常完善，我们就仅贴一下链接：
加速结构：
射线与三角面相交：
光线追踪与光栅化：
通过原理部分可以看到，光栅化是先知道有某个三角面的存在，然后再根据其投影位置绘制到屏幕上，而光线追踪则是先知道有一条射线，再判断这条射线与哪些三角面相交。因此，对光栅化来说，由于必须提前知晓所有三角面，因此场景中三角面数量与其计算时间的复杂度为O(N)，而光线追踪则不需要知晓场景内所有的三角面，而是预先通过加速结构就能精确锁定到需要求交的那极少的一小部分三角面，由于加速结构的遍历通常是级联的，因此后者的时间复杂度为O(logN），而实际应用中，加速结构本身的构建和遍历也是不容小觑的一笔开销，比如在RTX 3080这台机器上，约每100万面就要消耗1ms时间构建，当然，实时渲染中，构建并不是需要每帧都做并且当前帧必须做完的任务，我们在日后的文章中，会讲解如何使用异步计算让构建的耗时尽可能少的影响帧数。但遍历则是每个像素都必须执行的任务。因此，当三角面数量较少时，光线追踪仍然很难表现的求交性能比光栅化更优秀。
光线追踪的前景：
对于目前市面常见的游戏来说，仍大多数是以光栅化为主，光线追踪作为辅料的渲染方式，这是因为主流玩家的设备需要时间才能追上来，而显然，受限于算法的时间复杂度以及硬件光栅并行性的限制，光栅化的硬件发展已然逼近尽头。而对光线追踪来说，构建，遍历加速结构以及三角面相交计算，并行度几乎可以无限细分，毫无疑问未来光栅化将逐步退出其主流的位置。尽管如此，光栅化在渲染管线的某些部分依然不可替代，如面片粒子，GUI等，因此在接下来的教程中我们会保证两者的学习同时进行。 卧槽，我还以为断更了！麦佬辛苦了 动物派对还没做好吗 这篇感觉水了点 水么，光是光追和光栅效率比较这一点，我被问到很多次了。 我之前也想问的，看了你回答，算是解惑了 [赞同][赞同][赞同] 好好好
页:
[1]