Whitted-Style光线追踪这个名字，在我刚学图形学的时候，属于那种"听起来很高端、看公式想摔键盘、但一旦跑通就再也回不去光栅化"的技术。现在回头想，它之所以值得花一整篇博客去拆解，不是因为算法本身多难——真正的难点在于，它把"看世界"的方式彻底换了一套逻辑，而且实现细节里塞满了各种会让画面崩掉的暗坑。
这篇我把从零手写软渲染器时踩过的所有坑、验证过的优化手段，连同原理一起讲清楚。适合刚学完光栅化、开始接触全局光照的读者，也适合那些能用OpenGL画个三角形、但还没尝试过从相机出发"逆着光找答案"的朋友。
1. 核心思路：为什么光栅化不够，还得有Whitted
1.1 逆着光的路径去看世界
光栅化处理一个三维场景的方式，是"从物体到屏幕"：把三角形顶点经过一系列变换映射到屏幕像素，用深度缓冲（z-buffer）决定谁在前面，再逐像素着色。它解决的是"这个三角形盖住了哪个像素"的问题。
光线追踪的思路恰恰相反，它是"从屏幕到物体"：对每个像素，生成一条从相机出发的射线，沿着方向射向场景，找出这条射线打在哪个物体上，再根据交点材质、光源位置、反射与折射路径，算出这个像素该是什么颜色。这个"逆行"的过程，叫做逆向光线追踪。
Whitted-Style多出来的那个后缀，指的是1980年Turner Whitted提出的递归思想：当光线击中物体表面时，不只看直接光照，还要从这个交点继续向外发射反射光线和折射光线，递归追踪下去。对每个交点还要向每个光源发射一条"阴影光线"来判断自己是否被遮挡。这套方案把反射、折射、阴影三个全局效果统一进了同一个递归框架里，是80年代最具影响力的渲染模型之一。
1.2 它解决了什么问题
光栅化如果想做镜面反射，常见手段是渲染场景两次，先把场景渲染到环境贴图里，再采样贴图模拟反射。这种做法有天然上限：反射里套反射怎么办？物体的背面怎么办？曲面反射变形怎么办？
Whitted-Style的答案很直接：不做近似，去追踪。镜面反射就是沿着反射方向再发一条光线，等它打到别的物体上，把那边的光照贡献加回来。折射同理。这层"递归"把理论上无限弹射的全局光照路径，变成了一个可以控制深度的递归过程，代价是计算量成倍上涨，但画面里那些透明球、镜面地板带来的质感，是光栅化很难模拟的。
1.3 这篇博客围绕什么展开
我会按一条完整的手写实现链路来组织内容：先补数学基础（光线方程、三角形求交），再拆整体流程（相机光线生成、递归反射折射、阴影判断），然后过一遍比公式讲课更有价值的实现细节（递归深度取多少、菲涅尔怎么近似、那个让无数人抓狂的epsilon），最后用实际调试案例讲讲我写这个渲染器时遇到的典型问题。全程会贴关键代码和算法伪代码，你可以照着一步步复现，也可以直接拿来排查自己项目里莫名的黑色噪点。
2. 光线求交：一切渲染的基础
2.1 光线方程与"最近交点"概念
一条三维光线可以表示为：
r(t) = o + t * d, t > 0其中o是光线的起点，d是方向向量（通常归一化），t是沿方向的参数距离。光线求交的核心，就是在给定几何体描述的前提下，求解出使光线与几何体表面重合的t值，取所有交点中最小的那个正数t，作为这条光线命中的最近表面。
这里有个关键认知：光线追踪里的"深度测试"不是逐像素比较深度值，而是逐光线取最小t。场景里可能有几千个三角形，一条光线要与每个可见候选求交，从中选最近的那个，再做后续着色操作。这也是光线追踪慢的根本原因——每个像素都要做大量几何求交计算。
2.2 三角形求交：Möller-Trumbore算法
游戏和渲染器里最常用的显式几何表示就是三角形网格。一条光线与三角形求交，最经典、最容易在代码里实现的方案是Möller-Trumbore算法。它把光线方程与三角形重心坐标联立，一步解出t和重心坐标u, v。
三角形面上任意一点可以写成：
P = (1 - u - v) * P0 + u * P1 + v * P2把光线方程代入，整理成：
-t * d + u * (P1 - P0) + v * (P2 - P0) = o - P0这是一个3x3线性方程组，用克拉默法则可以直接解。整个算法的推导过程，本质上是三个向量混合积（行列式）的化简。最终实现的C++版本长这样：
bool rayTriangleIntersect( const vec3& o, const vec3& d, const vec3& P0, const vec3& P1, const vec3& P2, float& t, float& u, float& v) { vec3 E1 = P1 - P0; vec3 E2 = P2 - P0; vec3 S = o - P0; vec3 S1 = cross(d, E2); vec3 S2 = cross(S, E1); float invDet = 1.0f / dot(S1, E1); t = dot(S2, E2) * invDet; u = dot(S1, S) * invDet; v = dot(S2, d) * invDet; return (t > 0.0f) && (u >= 0.0f) && (v >= 0.0f) && (u + v <= 1.0f); }写到这里必须提醒一个我实际踩过的坑：代码里的t是光线参数距离，不是绝对距离。在CPU软渲染里，我习惯用一个HitRecord结构把t、重心坐标、三角形索引、法线一起存下来，等整条光线遍历完所有候选三角形后，统一比较t的大小。千万不要在求交函数里直接写入全局最近值，那样会因为递归调用时的状态冲突导致各种诡异结果。
2.3 隐式曲面求交：以球体为例
手写渲染器里，球体是最常用的测试几何体，也是理解隐式曲面求交的敲门砖。球体满足方程：
(p - c)^2 - R^2 = 0直接代入光线方程：
(o + t*d - c)^2 - R^2 = 0展开后就是一个一元二次方程：
vec3 oc = o - center; float a = dot(d, d); float b = 2.0f * dot(oc, d); float c = dot(oc, oc) - radius * radius; float discriminant = b * b - 4.0f * a * c; if (discriminant < 0.0f) return false; // 光线与球无交点 float sqrtD = sqrt(discriminant); float t1 = (-b - sqrtD) / (2.0f * a); float t2 = (-b + sqrtD) / (2.0f * a); // 取正向范围内较小的t如果你把d做了归一化，那么a = 1，这个公式能省一次点积。不过我的建议是保留完整的a系数，因为后续如果引入运动模糊或者非归一化方向向量，公式就不会出错。判别的核心思想很简单：判别式小于零没有交点，等于零相切，大于零两个交点。
法线的计算也很直观：球面上任意一点的法线方向就是(hitPoint - center) / radius。这个法线是标准的几何法线，后续做反射、折射都需要它。
2.4 加速结构：没有BVH的光线追踪走不远
朴素的光线追踪就是对场景里每个三角形都做求交，假设场景有一万个三角形，一帧画面有百万像素，哪怕是只追踪一条主光线，这就是百亿次求交运算，在单线程CPU上跑起来非常痛苦。
所以我们通常会把场景组织成层次加速结构，最常用的就是BVH（Bounding Volume Hierarchy，包围体层次结构）。核心思想是：先用AABB（轴对齐包围盒）把三角形包起来，构建一颗二叉树。遍历时先检测光线是否与包围盒相交，不相交就整棵子树跳过。
光线与AABB求交可以用"三次 slabs 检测"实现。对每个轴，计算光线进入和离开盒子那一对平面的t值，然后对三组区间取交集。如果最终区间合法（t_near < t_far），说明光线穿过了盒子。
BVH构建我用的策略是：以当前节点所有三角形的AABB中心为划分依据，按最长轴排序后分成两半，递归构建左子树和右子树。终止条件是三角形数量小于16个，此时直接线性求交。这个阈值不是拍脑袋定的，我在几个场景里对比过，16个左右对现代CPU的缓存预取比较友好。
3. 一条光线的一生：递归追踪流程
3.1 相机光线与透视投影
光线追踪的第一步，是为屏幕上的每个像素生成一条从相机出发的光线。最简单的模型是针孔相机：所有光线都从同一个点（眼睛位置）出发，穿过虚拟的成像平面。
已知相机的position、lookAt目标点、up向量，首先算出相机的三个基向量：
vec3 forward = normalize(lookAt - position); vec3 right = normalize(cross(forward, up)); vec3 realUp = cross(right, forward);然后，对像素坐标(i, j)，先换算到标准设备坐标（NDC）：
// 映射到 [-1, 1] 范围 float x = (2.0f * (i + 0.5f) / imageWidth - 1.0f) * aspectRatio; float y = 1.0f - (2.0f * (j + 0.5f) / imageHeight);这个(x, y)就是在成像平面上的偏移。最终光线方向是：
vec3 direction = normalize(forward + x * right * tanHalfFov + y * realUp * tanHalfFov);加0.5f是为了让光线穿过像素中心，否则画面会有严重的锯齿。这里有个经验点：记得在x上乘aspectRatio，否则画面会横向拉伸变形。我刚开始写的时候漏了这一步，球体全变成了椭圆，排查了半天才意识到是宽高比的问题。
3.2 最近交点与着色
有了光线后，对场景里所有几何体做求交，找到最近的可见交点。这一步得到的信息包括交点坐标、表面法线、材质属性（颜色、反射率、折射率等）。在最近交点处，我们先计算局部光照，通常用Blinn-Phong模型：环境光分量、漫反射、高光。这部分和光栅化里的着色逻辑几乎一样，区别在于这里我们已经有了精确的几何位置和法线，不需要依赖深度缓冲的插值。
局部着色只是"地基"，Whitted-Style真正的精髓在后面三步：反射、折射、阴影。
3.3 反射：顺着镜面思路递归下去
如果物体表面具有反射属性（比如镜子、光滑金属），就在交点处沿反射方向生成一条新的光线，继续追踪场景。反射方向的计算公式是：
r = d - 2 * dot(d, n) * n这段几何关系可以从向量分解推导出来：把入射方向分解为平行于法线和垂直于法线的两个分量，反射后的垂直分量反向。代码实现起来就一行，我通常封装成一个工具函数，因为会在递归和菲涅尔计算中反复调用。
反射光线的起点不能直接用交点，而要沿法线方向偏移一小段距离epsilon，否则会跟自己所在的表面再次求交。这个偏移量如果大了，反射物体会产生明显的"漂浮"感；小了，又会自我相交产生黑色噪声点。我后面专门用一节讲这个参数的调节。
3.4 折射：斯涅尔定律与全反射
折射的计算比反射复杂。方向向量的变化遵循斯涅尔定律：
n_i * sin(theta_i) = n_t * sin(theta_t)实际的折射方向向量推导可以表示为：
t = (n_i / n_t) * (d - dot(d, n) * n) - n * sqrt(1 - (n_i/n_t)^2 * (1 - dot(d, n)^2))这里有一个必须处理的特殊情况：当光线从高折射率介质传入低折射率介质时，如果入射角超过临界角，折射项里的平方根会变成负数，物理上意味着发生全反射，此时应该返回反射方向而不是折射方向。
我写过一版忽略全反射判断的代码，结果透明球变成了一个诡异的"黑洞"，边缘还闪烁着乱七八糟的颜色。排查后发现就是这里的问题。所以在实现折射时，请务必先判断平方根参数是否小于零。
一个容易忽略的细节：光是穿过透明物体，会经历两次折射——进入时一次，离开时一次。对球体来说，入射光线与球面相交，用第一次交点的法线计算折射向量，然后继续追踪一条直线，可能会在后面再次与球体相交。这个二次交点可能落在球体外面，也可能在内部。标准Whitted模型里，我们不做光线在物体内部传播的复杂路径追踪，而是直接把折射光线当成一条新光线继续递归，让它在下一次求交中自然处理"离开"的过程。
这里的法线方向非常值得注意：如果光从内部射向表面，法线应该取反，否则折射方向会完全错掉。我用一个统一约定：交点处的法线永远指向光线来源的那一侧。返回的折射光线方向如果与法线方向接近，说明光线正在离开物体，此时要通过材质来区分，到底该继续折射还是返回。很多初学实现里，透明物体渲染出来是"实心"的，就是这个细节没处理好。
3.5 阴影光线：判断可见性
对每个最近交点，要向场景中每个光源发射一条"阴影光线"：从交点沿着指向光源的方向发射，检测在到达光源之前是否被其他物体挡住。如果被挡住，说明这个点就在阴影里，需要把对应光源对该点的贡献去掉。
阴影光线的起点同样需要加epsilon偏移，否则会跟自身表面求交，导致本该被照亮的地方出现了随机的小黑点，这就是典型的"阴影粉刺"（shadow acne）。这个效果我在后面的常见问题里详细讲。
3.6 递归与终止：把颜色一层层带回来
整个过程可以打包成一个递归函数，伪代码如下：
color trace(ray, depth) { if (depth > maxDepth) return backgroundColor; if (!scene.intersect(ray, hit)) return backgroundColor; color result = shade(hit); // 局部光照 result += hit.material.reflectance * trace(reflectionRay, depth + 1); result += hit.material.transmittance * trace(refractionRay, depth + 1); return result; }这个递归函数写起来清爽，但有不少性能坑。递归深度每增加一层，意味着每条像素光线要额外追踪好几条子光线，整体计算量是指数增长的。深度设到8基本就够用了，深度超过12之后的画面差异肉眼几乎看不出来，徒增计算量。
另一个经验：不同材质的反射率和透射率最好在材质定义里给成0到1之间的值，并且确保reflectance + transmittance <= 1。否则能量不守恒，物体会越追越亮。我调试时出现过镜面球表面白花花一片的，就是因为反射率设置成1的同时，局部光照模型又叠加了满额的漫反射和高光。
4. 实现细节与参数调节心得
4.1 递归深度：到底设多少层才够
递归深度和场景复杂度直接相关。简单场景（一个地面、两个球）深度3层，画面质量已经相当不错。如果是多个镜面球互相反射，深度5层以上能明显看到多次反弹的细节。我自己的调试惯例是：先把深度设成10，渲染一个低分辨率图像，观察画面是否还有明显的"未追踪到"的区域，然后逐步降低深度，找到一个视觉上无差别的临界值。
有个比深度更影响效果的细节：对反射和折射的光线，最终颜色需要乘上材质对应的系数。很多教程里直接累加，忘了乘反射率，结果镜面表面比真实场景亮很多。这个系数不是随便给的，它是一种物理意义上的"能量分配"，要保证所有通道加起来不超过1。
4.2 菲涅尔效应：让反射和折射更真实
我以前写的纯Whitted追踪有个视觉问题：玻璃球边缘的反光总是不对。后来发现是缺少了菲涅尔效应。菲涅尔效应描述的是：光线入射角越大（越接近掠过表面），反射越强。现实中，窗户从正面看是透的，从侧面看反射却很强。
菲涅尔项可以用Schlick近似来计算：
R(theta) = R0 + (1 - R0) * (1 - cos(theta))^5其中R0是垂直入射时的反射率，用两侧介质的折射率计算：
R0 = ((n1 - n2) / (n1 + n2))^2用这个计算结果去混合反射颜色和折射颜色，透明物体的质感立刻就不一样了。注意，这里的theta是入射方向与法线的夹角，不是折射角。代码实现时，我通常会把反射率和透射率按菲涅尔比例动态分配，再分别递归对应的光线。
4.3 那个让人抓狂的epsilon
epsilon偏移是Whitted-Style实现里最烦人的参数。它对三处影响最大：反射光线的起点、折射光线的起点、阴影光线的起点。取值的大小取决于场景的尺度。
如果场景用米作为单位，物体尺寸在1到10之间，1e-3这个量级通常比较稳。如果场景是微缩模型，物体尺寸只有0.01，1e-3就太大了，物体会明显偏移。我的做法是：在场景加载时，计算所有物体的包围盒，取包围盒对角线的万分之一作为全局epsilon值。这样至少不会出现灾难性的错误。
还有一种更稳的处理方式：不直接使用offset，而是在求交时排除掉"自己"所在的几何体。相交判断会传一个ignoreId，如果求交对象的ID和起点所在的几何体ID相同，就跳过。这个方案能彻底根治阴影粉刺问题，代价是实现时要维护每个光线的"来源几何体"信息。
4.4 性能瓶颈与多线程加速
光线追踪天然适合并行化：每个像素的光线彼此独立，不存在数据竞争。我用C++实现时，把图像分成若干个水平条带，每个线程处理一条带，再最后合图。实测四核八线程能有接近7倍的加速比。
另一个常用手段是提前计算场景的BVH并缓存，不要在递归内部重复构建。我见过有的实现把BVH构建放在递归函数里，那画面太美不敢看——每根光线都要重新建一遍树，性能直接崩掉。
如果追求实时性，可以先把光线计算改成单指令流多数据流并行，或者用GPU做光栅化后再用光线追踪做屏幕空间反射。不过这些就超出了手写软渲染的范畴，是后面经验积累的方向了。
5. 常见问题排查与调试实录
5.1 画面全是黑色噪点
这是我调光线追踪时遇到最多的现象。黑色噪点通常来自两个原因：一是阴影光线起点偏移不够，导致自我相交，随机产生黑色小点；二是反射光线或折射光线在穿过几何体边缘时，因为浮点误差击中了物体的背面或者缝隙，返回了接近0的颜色。
排查方法是：先禁用阴影光线，看噪点是否消失。如果还存在，再分别禁用反射和折射，定位到是哪一类光线引入的噪声。然后打印出事发像素的最近交点坐标、法线方向、光线方向，检查它们是否符合预期。这个"二分法定位"思路适用于绝大多数渲染器调试场景。
5.2 阴影区有奇怪的条纹
这种条纹通常是偏移太小导致自遮挡，或者偏移太大导致光源方向判断错误。当阴影光线从交点出发，如果偏移小于表面的浮点误差，光线会打到自己的另一面，产生一种"接缝处反而没阴影"的现象，看起来像条纹。
解决方式：把epsilon调到当前尺度下合理值，或者改用"排除自身几何体"的方案。我强烈推荐后者，因为epsilon总归是经验值，改来改去很麻烦，而排除自身几何体在逻辑上是干净的。
5.3 透明物体的折射效果显得"实心"
前面提到的法线方向问题。检查逻辑很简单：从外部看透明球时，第一次交点的法线背对相机（指向球心），折射向量由斯涅尔定律计算。当折射光线在球内部继续前进时，第二次与球面相交，此时法线指向球外（即指向球心反方向）。如果此时不做法线翻转，斯涅尔定律会把方向算反，光线就好像被"困"在球里出不来。
另外还要注意全反射判断。当光线从玻璃进入空气时，临界角约为42度，超过这个角度会反射，而不会折射。如果忽略全反射，透明球边缘就会出现明显的错误透光区域。
5.4 递归栈溢出
栈溢出很少是因为逻辑深了，常见原因是无限递归：反射光线和折射光线因为浮点误差，一直在贴近表面的位置来回反弹。解决思路是设置最小距离阈值：如果一条光线的起始点到最近交点的距离小于某个阈值，就不再继续递归追踪，直接返回颜色0或者背景色。
另一个办法是把递归改写成循环加显式栈，虽然代码复杂一点，但对调试和维护更友好。渲染器毕竟有深度上限，栈溢出通常意味着逻辑上出了问题，仅仅加大递归深度是治标不治本。
6. 个人实操体会：一个能跑通的Whitted渲染器需要什么
我在自己写这个项目时，踩的最深的坑，不是算法原理，而是参数之间的互相影响。epsilon调好了阴影，结果折射物边缘出现了亮线；递归深度调低了，镜面里的第二层反射竟然变成了纯色；把反射率调成0.95，结果和菲涅尔计算混在一起，画面比原场景亮了一大截。
后来我把渲染器改成"配置驱动"的方式：所有材质、相机参数、递归深度、偏移量全部从配置文件加载。每次调试只改参数，渲染出的图文件名里带参数哈希，方便对比。这个习惯极大提高了调试效率。
如果你打算从零手写一个Whitted-Style光线追踪器，我的建议是先别着急做完整的反射折射阴影，第一步只做"相机光线+球体求交+环境光"，把整个像素循环跑通，看到渐变背景和一个红色球，再逐步加BVM、加反射、加折射、加阴影。每加一个特性，就渲染一张参考图，确认它对已有结果没有产生回归性破坏。
这条路走完，你对"离屏渲染""全局光照"这些字眼会建立起真正扎实的直觉。后续再去碰路径追踪、光子映射这类更复杂的算法，也只是在Whitted的骨架上加"概率采样"和"能量归一化"这两层皮而已。
