臭鼠标光栅化这个词，很多刚接触计算机图形学（计图）的朋友第一反应是“听起来好高级”，但说白了，它就是回答一个问题：怎么把三维世界里一堆顶点组成的三角形，画到你屏幕上对应的像素点上？ 我当年学图形学的时候，啃完一大堆数学推导，回头发现最核心的领悟就是——光栅化是渲染管线里最“实在”的一步，它把连续的几何变成了离散的像素，所有你能看到的画面，都绕不过它。这篇博文就打算用最直白的方式，把这个过程彻底拆开，从坐标变换到像素填充，从深度测试到抗锯齿，再配上一个能跑起来的软光栅化代码骨架。适合所有想自己动手写一个渲染器、或者刚学图形学被各种概念绕晕的读者。
别嫌它基础，光栅化里面的门道一点都不少。很多人以为会用OpenGL/DirectX画个三角形就算会了，但一旦要自己实现、调试、优化，就会发现里面全是细节。这篇文章我尽量把“为什么”讲透，而不只是给结论。目标很简单：看完之后，你能用自己的代码，把一个三角形——以及一个有颜色变化、有遮挡关系的立方体——画到屏幕上。
1. 整体思路：光栅化在整个渲染流程中的位置
1.1 渲染管线的一站式理解
先说清楚光栅化在哪儿。一条典型的实时渲染管线，大致是这样一个流水线：
- 应用程序阶段：CPU准备好顶点数据、变换矩阵、材质参数。
- 几何处理阶段：顶点着色器（或固定管线的变换）把顶点从模型空间一路变换到屏幕空间。
- 光栅化阶段：把屏幕空间里的三角形，转换成屏幕上的像素覆盖集合。
- 片元处理阶段：对每个被覆盖的像素计算颜色，做深度测试、混合，最终写入帧缓冲。
光栅化就是中间那道“从几何到像素”的桥。它输入的是三个屏幕坐标顶点（还有它们的属性，比如颜色、法线、纹理坐标），输出的是哪些像素点被这个三角形“盖住”了，以及每个像素点上插值出来的各种属性（比如深度值、颜色、UV坐标）。
很多人会问：这一步有必要单独讲吗？直接一个个像素判断“这个点在不在三角形内”不就完了？你还真说对了——光栅化本质上就是一个“点在三角形内”的测试，只不过直接暴力测的话速度太慢，所以才衍生了各种高效算法，比如扫描线、增量法、半平面法，以及GPU里那一堆并行优化。理解了这个本质，后面所有算法都能串起来。
1.2 为什么选择三角形作为基本图元
为什么图形学里绝大多数渲染都基于三角形，而不是四边形或者五边形？这不是拍脑袋定的，有三个非常实际的理由：
第一，三角形一定是凸的。 凹多边形在光栅化时需要额外处理凹陷处的像素归属，非常麻烦。三角形天然是凸的，任何三个点构成的三角形，内部可以被一组半平面的交集精确描述，这让“点在三角形内”的判断变得极其简单。
第二，三角形可以拼出任何形状。 现实中不管是汽车曲面还是人物脸部，建模师都是用大量三角形拼接出来的。GPU硬件也对三角形做了深度优化，三角形越多，模型越精细，但性能压力也越大，这个后面会聊到。
第三，插值结果唯一且稳定。 三角形有一个特别好的数学性质——重心坐标。一个点在三角形内部，可以用三个顶点加权唯一表示，而权重本身就是天然的插值系数。这让我们可以把顶点的颜色、法线、纹理坐标平滑地插值到三角形内部的每一个像素上。四边形就没有这种唯一性，同一像素在不同划分下可能得到不同的插值结果。
1.3 一个光栅化器的完整输入输出
为了让后续讨论有抓手，我先把一个软光栅化器的“接口”定义清楚。输入是什么？可以概括为：
- 一组顶点数据：每个顶点有位置（通常三维）、颜色、法线、纹理坐标等属性。
- 一组索引数据：哪些顶点构成一个三角形，比如
(v0, v1, v2)。 - 一组变换矩阵：模型矩阵、视图矩阵、投影矩阵、视口矩阵。
- 渲染状态：比如是否开启深度测试、是否开启混合、清屏颜色等。
输出是什么？一张二维图像，通常是一个颜色缓冲区（color buffer）和一个深度缓冲区（depth buffer）。颜色缓冲区里存的就是每个像素最终的颜色，深度缓冲区里存的是每个像素当前可见片元的深度值。
这个定义非常重要。因为很多初学者会把“光栅化”和“渲染”混为一谈。实际上光栅化只是产生“候选像素”的阶段，真正决定像素最终颜色的是后面的片元处理和混合。写自己的渲染器时，把这两个阶段分开，调试起来会轻松很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心前置：从三维坐标到屏幕坐标的完整推导
2.1 坐标变换的四个阶段
任何一个顶点最终在屏幕上显示出来，都要经过四次变换：模型变换、视图变换、投影变换、视口变换。很多教材把这四次变换写成矩阵相乘的形式，最后得到一个MVP矩阵。但我建议你千万理解每一步在干什么，而不是背矩阵。
模型变换把顶点从模型自身坐标系挪到世界坐标系。模型可能被平移、旋转、缩放，这步就是把这些变换叠加起来。视图变换把世界坐标系变成以相机为中心的坐标系，本质上是把相机摆到原点、让它的朝向对准某个方向。有时候也叫“相机变换”。投影变换是这四步里最有意思的，它决定我们怎么看这个世界——正交还是透视。视口变换则简单粗暴，把规范化设备坐标（NDC，范围在[-1,1]或[0,1]之间）映射到像素坐标。
我初学的时候最容易搞混的是投影变换。正交投影很简单，平行线投影后还是平行线，适合工程制图、CAD那些场景，没有近大远小的效果。透视投影不一样，它模拟人眼和真实相机，近处的物体看起来大，远处的物体看起来小，因为投影中心是相机所在的一个点。这个“近大远小”的视觉差异，靠的是齐次坐标里的w分量实现的。
透视投影矩阵长这样（常见的FOV和宽高比版本）：
code复制| f/aspect 0 0 0 |
| 0 f 0 0 |
| 0 0 (zFar+zNear)/(zNear-zFar) (2*zFar*zNear)/(zNear-zFar) |
| 0 0 -1 0 |
其中f = 1.0 / tan(fov/2)，aspect是屏幕宽高比。注意到最后一行有个-1，这意味着变换后的w分量不再是1，而是等于原顶点的-z值（在右手坐标系下，相机看向-z方向）。这一步太关键了——它把深度信息编码进了w，为后续的透视除法埋下伏笔。
顶点经过投影矩阵变换后，我们习惯保留齐次坐标形式（x, y, z, w），然后做透视除法，即把x、y、z都除以w。这个过程把视锥体压成NDC空间里的一个立方体。然后视口变换把NDC坐标映射到屏幕像素坐标，公式大致是：
code复制screenX = (ndcX * 0.5 + 0.5) * width
screenY = (1 - (ndcY * 0.5 + 0.5)) * height
注意第二行的1 - ...，因为屏幕y轴是向下增长的，而NDC里y轴向上。这个细节不处理好，你渲染出来的画面会上下颠倒。
2.2 透视校正插值：为什么不能直接线性插值
这一步很多人会踩坑。假设一个三角形在屏幕上看起来非常大，但它的顶点深度有远有近。当你在屏幕空间里线性插值这个三角形内部的纹理坐标时，会产生“纹理飘移”的视觉错误——因为屏幕空间的线性距离并不等价于三维空间里的线性距离。透视投影下，三维空间里的等距线段，投影到屏幕上会出现“近大远小”，也就是说屏幕空间里的均匀步长，对应三维空间里是不均匀的。
解决办法是“透视校正插值”（perspective-correct interpolation）。核心思想是：先在顶点上计算属性除以w的值，然后在屏幕空间做线性插值，最后再乘以1/w来完成校正。 对每个顶点的属性（比如UV、颜色），我们保存attr/w，在光栅化时线性插值这个值，同时线性插值1/w，最后用lerped(attr/w) / lerped(1/w)得到正确的属性值。
我当年调试一个纹理倾斜问题整整一个下午，最后发现就是少了这一步透视校正。从那以后我养成了一个习惯：所有需要在像素间插值的属性，都走“除以w、插值、再乘回w”的标准流程。写代码时，这一步最好封装成一个函数，不要每次都手写，太容易出错。
2.3 视口变换与像素中心约定
做好坐标变换之后，会有一个非常细小但影响全局的约定问题：像素中心到底是在整数坐标上，还是在半整数坐标上？ 这个约定不一致，会导致边缘出现“锯齿闪烁”或“整幅图偏移半个像素”。
业界最常见的约定是：像素中心的坐标是(x + 0.5, y + 0.5)，其中x、y是整数像素索引。也就是说，像素(0,0)的中心在空间的(0.5, 0.5)处。这样约定有一个好处：在对三角形做边界测试的时候，可以直接用像素中心点来判断它是否落在三角形内部，避免边界上的模糊判定。
我自己写软渲染器时，固定把屏幕坐标定义成float，然后遍历像素时取中心点(px + 0.5, py + 0.5)去做判定。这个细节看起来不起眼，但在做MSAA或者多像素采样的时候，中心点偏移的约定会直接决定采样结果的一致性。
3. 光栅化算法详解：三种常见途径
3.1 扫描线算法：理解光栅化从像素行开始
扫描线算法是光栅化最“原始”的思路，也是很多教材最早讲的。原理很简单：对屏幕的每一行（扫描线），找出这一行和三角形的相交区间，然后只填充区间内的像素。
假设三角形三个顶点屏幕坐标是(x0,y0), (x1,y1), (x2,y2)。对于某一条扫描线y = Y，我们是先找出三角形与这条扫描线的所有交点，然后按x排序，取最小和最大的x（对于凸多边形来说，任意一条水平线最多只会有两个交点），那么从x_min到x_max的像素都填充。由于三角形是凸的，这个“求交”其实可以简化成：每条边的端点按y排序，然后按斜率增量更新x。
这个算法的优点是好理解、好实现，尤其适合CPU单线程环境下按行扫描输出。缺点也很明显：它和“三角形”这个图元绑定得比较紧，扩展性一般，而且像素是按行列顺序生成的，不利于并行化。现代GPU虽然仍保留了一些扫描线思想，但实际光栅化单元早就换成了更统一的“逐像素判定”方式。
3.2 半平面法：现代软光栅化器的主流选择
我建议想自己写渲染器的人，直接学“半平面法”（half-space test），或者叫“边缘函数法”。它的思路是：对于三角形的每一条边，计算一个符号，用来判断某个点在这条边的哪一侧。如果某个点同时满足“在三条边同一侧”（通常是都在左侧或者都在右侧），它就落在三角形内部。
具体来说，对于边(v0, v1)，定义边缘函数：
code复制edge = (x - x0) * (y1 - y0) - (y - y0) * (x1 - x0)
这个式子的几何意义是：点(x, y)相对边(v0, v1)的“有向面积”。如果edge > 0，点在边的一侧；edge < 0，在另一侧；edge == 0，恰好在边上。把三条边的符号统一了，一个像素点才算在三角形内。
这里有个坑：三角形的顶点顺序决定了符号方向。如果你的三角形顶点是逆时针排列（CCW），那么像素点应该满足三条edge都大于等于0；如果是顺时针排列（CW），则是都小于等于0。很多工程实现里，会预先做一步“顶点重排”，保证算法内部始终处理逆时针三角形。
半平面法最大的好处是完全并行友好——每个像素的判定只依赖三角形顶点的坐标，不依赖其他像素的结果。这意味着你可以肆无忌惮地用GPU并行处理，或者用CPU的多线程把屏幕切成块同时计算。我做软渲染器时就是用这个算法配合并行循环，性能提升非常可观。
3.3 重心坐标：从“是否在内”到“插值属性”
判断像素点是否在三角形里只是第一步，我们还要给像素填充颜色、深度、UV等属性。这就是重心坐标出场的地方。
重心坐标的本质是：任何一个位于三角形内部的点，都可以写成三个顶点的加权平均：
code复制P = alpha * A + beta * B + gamma * C
其中alpha + beta + gamma = 1，且三个值都非负。如果有一个值小于0，那P就在三角形外。这三个权重正好可以用来插值顶点属性。有意思的是，半平面法里算出的三个edge值，只要归一化一下，就能直接得到重心坐标。这太方便了：判断和插值用同一套计算，省掉大量重复运算。
写代码时，我通常这样处理：
- 先算三个edge：
e0 = edge(B, C, P),e1 = edge(C, A, P),e2 = edge(A, B, P)。 - 标准化：
alpha = e0 / area，beta = e1 / area，gamma = e2 / area。这里的area就是三角形总面积，可以用任意一条edge代入计算得到。 - 插值属性：
attr = alpha * attrA + beta * attrB + gamma * attrC。
如果属性是颜色，直接插值就行；如果属性是纹理坐标或带透视的性质，记得用前面说的透视校正。
4. 深度测试与遮挡关系：光栅化流程里的“定海神针”
4.1 为什么需要深度缓冲
想象一下：你画一个不透明的立方体，它后面的面应该被前面的面挡住。如果按画家算法（从远到近画）来做，排序错误的时候就会出现可怕的“穿插”现象。更麻烦的是，物体之间可能互相穿插，根本无法给出一个完整的前后排序。
深度缓冲（Z-Buffer）是解决这个问题最实用的方案。基本原理非常简单：为每个像素维护一个深度值，在写入像素颜色之前，先比较这个片元的深度和当前缓冲区的深度。如果更近（深度值更小，或者更大，取决于坐标系约定），就写入颜色并更新深度；否则丢弃。
这个算法由Edwin Catmull在1974年提出，至今仍是实时渲染里遮挡处理的主流方案。它的优点是O(1)空间复杂度（只需要一个和缓冲区一样大的浮点数组），对物体的绘制顺序没有要求，支持任意复杂的几何遮挡关系。缺点是需要额外内存，而且深度精度有限，太远或太近的物体可能出现“深度冲突”（z-fighting），画面上表现为闪烁的噪点。
4.2 非线性深度与精度陷阱
在透视投影下，深度缓冲里的值并不是线性分布的。透视投影矩阵把z映射成a/z + b的形式，也就是说，靠近近裁剪面的深度值变化幅度很大，远离近裁剪面的深度值变化很平缓。这导致深度缓冲在近处精度高、远处精度低。很多初学者不理解为什么“远处的模型会闪烁”，其实就是因为远处的大片深度值挤在一个很小的数值区间里，任何微小的浮点误差都可能改变比较结果。
解决思路有几个方向。最简单的，把深度缓冲改成反向Z（reversed-Z）——因为现代深度缓冲是0到1，离相机越近越接近0，越远越接近1。但如果把映射反过来，让近处接近1、远处接近0，反而能让精度分布更合理。另一个方案是增加深度位的位数，比如从24位变成32位浮点。还有一个思路是“深度压缩”或“对数深度缓冲”，但实现复杂度高，一般只有引擎底层才会做。
我在自己的软渲染器里用的是反向Z，因为代码里控制起来最直接，效果立竿见影。测试下来确实比正向Z的闪烁少很多。如果你有大量远景物体，强烈建议试试这个改动。
4.3 深度写入的开关与时机
光栅化流程中，深度测试不是每时每刻都该开的。我遇到过好几次“透明物体显示错误”的bug，最后定位到问题是“半透明物体的深度写入没有关闭”。半透明物体需要和后面的物体做颜色混合，如果它也往深度缓冲里写值，后面的物体会被它遮挡，混合效果就全错了。
所以深度缓冲的管理有一条经验法则：
- 不透明物体：正常开启深度测试和深度写入。
- 半透明物体：开启深度测试，但关闭深度写入，按照从远到近的顺序渲染。
这条法则不是绝对的，但能解决90%的常见渲染错误。其他的深度相关技巧，比如反向Z、深度偏移（depth bias）、多边形偏移（Polygon Offset），都是在这个基础上做的微调。
5. 光栅化中的抗锯齿：让边缘不再闪烁
5.1 锯齿的来源：离散采样
用“像素中心点是否在三角形内”来做判定，边缘一定是锯齿状的。这和三角形本身的形状无关，纯粹是因为我们对连续空间做了离散采样。屏幕上每英寸的像素数再高，也改变不了离散的本质。边缘上斜的线条会呈现出“阶梯状”，这就是所谓的“锯齿”（aliasing）。
这个问题的物理根源叫“混叠”——高频的几何信息（比如锐利的边缘）在采样率不足的情况下，被“伪装”成了低频的图案。要彻底消除，只能提高采样率，或者对信号做低通滤波。实时渲染里最常用的方法是多重采样抗锯齿（MSAA）。
5.2 MSAA的工作原理与实现思路
MSAA的思路是：不提高渲染分辨率，而是对每个像素多采样几个子点，看这个像素被三角形覆盖了多少个子点。如果覆盖了1个子点，颜色贡献就是1/覆盖数；覆盖了2个，就是2/覆盖数，以此类推。这样边缘像素会得到一个介于“三角形颜色”和“背景颜色”之间的混合值，视觉上就会显得平滑很多。
在软光栅化器里实现MSAA，一个直接的办法是：把每个像素当成一个2x2或4x4的子采样网格，对每个子采样点做覆盖判定和深度测试，最后把子采样点的颜色平均作为像素颜色。代价是计算量和内存都会成倍增加，但效果立竿见影。
我一开始用的是4x MSAA，网格均匀分布，效果已经非常好了。后来试过8x，画质提升肉眼几乎看不出来，但性能下降了将近一倍。所以个人心得是：4x MSAA是性价比最高的甜点位，如果你的三角形很小很密集，可以考虑8x，否则4x足矣。
除了MSAA，还有FXAA（快速近似抗锯齿）和TAA（时间抗锯齿）等后处理方案。FXAA不依赖几何信息，直接在最终图像上找边缘并模糊，速度快但会损失一些细节；TAA则是把多个帧的采样信息叠加起来，兼顾了质量和性能，但会引入拖影。从基础学习的角度，MSAA是最值得先吃透的，因为它的原理直接和光栅化的采样行为挂钩。
5.3 超采样抗锯齿的取舍
还有一种极端的抗锯齿方式叫超采样抗锯齿（SSAA），做法是把整幅画面用更高分辨率渲染，再缩小到目标分辨率。这相当于对整个屏幕做暴力采样，效果很好，但计算量按分辨率平方增长，4K分辨率再SSAA 4x，渲染量直接爆炸。所以SSAA在现代实时渲染里已经很少用了。
我自己在软渲染器里做性能对比时，顺便记录过不同抗锯齿方式的开销，结论是：对于普通的教学场景，MSAA 4x是“效果/代价比”的最优解。不管你是想学原理还是做实际项目，都建议从MSAA入手，先看效果，再调性能。
6. 实战：手写一个完整的软光栅化器
6.1 坐标系与数学库的封装
动手之前，先准备一个轻量的数学库。不需要引入庞大的第三方库，我自己习惯用简单结构体封装vec3、mat4这些基础类型。核心操作就几个：向量加减、点乘叉乘、矩阵乘向量、矩阵乘矩阵。用C++写的话，注意运算符重载会让代码更清晰。
以下是一个精简版数学库的代码骨架：
cpp复制#include <cmath>
#include <vector>
struct Vec3 {
float x, y, z;
Vec3 operator+(const Vec3& o) const { return {x+o.x, y+o.y, z+o.z}; }
Vec3 operator-(const Vec3& o) const { return {x-o.x, y-o.y, z-o.z}; }
Vec3 operator*(float s) const { return {x*s, y*s, z*s}; }
float dot(const Vec3& o) const { return x*o.x + y*o.y + z*o.z; }
Vec3 cross(const Vec3& o) const {
return {y*o.z - z*o.y, z*o.x - x*o.z, x*o.y - y*o.x};
}
};
struct Mat4 {
float m[4][4] = {};
float& operator()(int i, int j) { return m[i][j]; }
Vec3 transformPoint(const Vec3& p) const {
float w = m[3][0]*p.x + m[3][1]*p.y + m[3][2]*p.z + m[3][3];
return {
(m[0][0]*p.x + m[0][1]*p.y + m[0][2]*p.z + m[0][3]) / w,
(m[1][0]*p.x + m[1][1]*p.y + m[1][2]*p.z + m[1][3]) / w,
(m[2][0]*p.x + m[2][1]*p.y + m[2][2]*p.z + m[2][3]) / w
};
}
};
transformPoint里除以w那步，就是前面说的透视除法。注意这个函数假设输入的向量是三维点，且矩阵是已经包含平移信息的4x4矩阵。实际项目里还要区分点（w=1）和方向（w=0），否则方向向量会被平移影响。
6.2 顶点变换与视口映射
渲染一个三角形的第一步，是把三个顶点从模型空间变换到屏幕空间。完整流程是：模型矩阵 -> 视图矩阵 -> 投影矩阵 -> 透视除法 -> 视口矩阵。我习惯把这几个矩阵先乘成一个MVP矩阵，再分别处理。
伪代码大致如下：
cpp复制Mat4 model = getModelMatrix(translation, rotation, scale);
Mat4 view = getViewMatrix(cameraPos, lookAt, up);
Mat4 proj = getPerspectiveMatrix(fov, aspect, near, far);
Mat4 mvp = proj * view * model; // 注意矩阵乘法顺序
for (auto& v : vertices) {
Vec4 clip = mvp * v; // 齐次坐标
Vec3 ndc = {clip.x / clip.w, clip.y / clip.w, clip.z / clip.w};
Vec3 screen = {
(ndc.x * 0.5f + 0.5f) * width,
(1.0f - (ndc.y * 0.5f + 0.5f)) * height,
ndc.z // 或者 (ndc.z + 1) / 2
};
// 保存screen坐标用于光栅化
}
这里有个值得注意的细节：很多教材把深度值也映射到[0,1]区间，即(ndc.z + 1) / 2。如果深度缓冲是浮点型，在OpenGL默认的深度范围就是[0,1]。但是如果使用反向Z，你可能希望直接保存ndc.z而不做线性映射，具体取决于你的约定。我的建议是：在代码注释里写清楚你用的是哪个约定，不然调试两天后自己都会忘。
6.3 核心光栅化循环：一步步填像素
现在到了最关键的部分——软件光栅化循环。我用半平面法来实现，因为它最适合并行化，而且代码直观。整体的算法流程是：
- 计算三角形的屏幕包围盒（bounding box）。这个方法虽然叫“光栅化”，但没必要全屏幕扫描，直接找三角形的最小/最大x和y，只遍历这几块区域就行。
- 遍历包围盒里的每个像素，取像素中心点。
- 用半平面法判断中心点是否在三角形内。
- 如果在，计算重心坐标，插值深度值和颜色。
- 做深度测试，通过则写入颜色缓冲区和深度缓冲区。
核心伪代码如下：
cpp复制// 三角形三个屏幕坐标顶点
Vec2f v0, v1, v2;
// 包围盒计算
int minX = floor(min(v0.x, min(v1.x, v2.x)));
int maxX = ceil(max(v0.x, max(v1.x, v2.x)));
int minY = floor(min(v0.y, min(v1.y, v2.y)));
int maxY = ceil(max(v0.y, max(v1.y, v2.y)));
// 三角形面积（有符号面积的2倍是2*area）
float area = edge(v0, v1, v2);
for (int py = minY; py <= maxY; py++) {
for (int px = minX; px <= maxX; px++) {
Vec2f p = {px + 0.5f, py + 0.5f}; // 像素中心
float e0 = edge(v0, v1, p);
float e1 = edge(v1, v2, p);
float e2 = edge(v2, v0, p);
// 半平面测试：三个同号说明在三角形内
if ((e0 >= 0 && e1 >= 0 && e2 >= 0) ||
(e0 <= 0 && e1 <= 0 && e2 <= 0)) {
// 重心坐标
float alpha = e0 / area;
float beta = e1 / area;
float gamma = e2 / area;
// 插值深度
float depth = alpha * depth0 + beta * depth1 + gamma * depth2;
// 深度测试
if (depth < depthBuffer[py * width + px]) {
// 插值颜色
Color color = alpha * c0 + beta * c1 + gamma * c2;
colorBuffer[py * width + px] = color;
depthBuffer[py * width + px] = depth;
}
}
}
}
这个例子里的area是有符号面积，如果你用逆时针三角形，它为正。所以半平面判定的条件是e0 >= 0 && e1 >= 0 && e2 >= 0。但如果你的顶点顺序不统一，需要根据area的符号决定方向，或者干脆在预处理阶段把三角形顶点统一成逆时针。
6.4 性能优化：从包围盒到增量算法
上面这个朴素实现能跑通，但性能一般。每渲染一个像素都要算三次完整的边缘函数。包围盒本身已经砍掉了很多无用像素，但如果三角形很小，你仍然可能在大量空像素上做计算。针对这个，可以引入增量算法：由于边缘函数是线性的，沿着同一行扫描时，x每增加1，边缘函数的变化量是固定的，完全可以预先算出dEdge/dx，然后用加法代替乘法。
另外一个更实用的优化方式：提前用包围盒与三角形大小做筛选。如果三角形的包围盒非常小，比如只覆盖一两个像素，就开辟一条专用路径直接处理，减少循环开销。这个“小三角形优化”在游戏引擎的软件光栅化里很常见。
还有一个容易犯的坑：当三角形某条边是水平或垂直时，边缘函数可能会出现浮点误差导致某些边界像素被漏掉。解决办法是给边缘函数加一个极小的阈值（比如1e-6），或者把所有浮点比较改成带容差的版本。这些细节不处理，就会出现“三角形边缘漏半个像素”的怪异现象。
7. 经典问题与排查心得：软光栅化器的“Debug实录”
7.1 画面全黑是怎么回事
全黑是软光栅化器最常见的故障，原因也比较集中。我通常按下面顺序排查：
- 检查MVP矩阵是否把物体变换到了视锥体内。最容易错的是相机方向和投影矩阵的参数，fov太大或太小、near设置成0或负数，都会导致物体被裁剪掉。
- 检查深度测试的方向。如果深度比较方向写反了，比如把
<写成了>，结果就是离相机远的物体反而覆盖近的物体，看起来像“透过物体看到后面”，严重时整个画面被背面物体填满。 - 检查颜色缓冲区初始化和写入。有些实现忘了把颜色缓冲区填成背景色，结果画面是黑色的，但三角形其实已经画上了，只是颜色混合写错了。
全黑时，第一个Debug技巧是关掉深度测试，看看三角形是否还能显示。如果能，说明问题多半在深度比较或深度初始化上。
7.2 三角形显示成“纸片”或者“穿插”
这通常是因为深度数据没被正确插值。尤其是用重心坐标插值时，忘了做透视校正的话，深度值在屏幕空间里是线性插值的，但深度在透视投影下本来就不是线性的，所以会看到三角形内部出现“穿透”或“扭曲”。
解决办法：确保插值深度时使用透视校正。如果你只是画没有纹理、单色的三角形，可能视觉上不明显，但一旦多个三角形有远近交叉，问题就暴露了。我的经验是先画两个简单三角形，一个在前一个在后，测试遮挡关系，然后再扩展到复杂模型。
7.3 纹理/颜色出现“拉扯”
这几乎是透视校正插值缺失的经典症状。屏幕空间的线性插值导致三角形内部纹理被拉伸，尤其在靠近一个顶点时特别明显，像一块被拉扯的橡皮泥。
处理思路很简单：把每个顶点的UV和颜色都先除以它们各自的w（在裁剪空间里的w），在屏幕空间线性插值时同时插值1/w，最后再乘回去。这一步虽然看起来多了一些运算，但对画质的影响是决定性的。
7.4 边缘“闪烁”和“锯齿”
锯齿是正常现象，不必担心。如果你看到的是“闪烁”——同一个边缘时隐时现、或者颜色一跳一跳的，那就要怀疑深度精度了。常见诱因有两个：
- 深度缓冲区使用的是
float，但深度比较时没有考虑浮点误差，导致两个深度值非常接近的片元反复竞争。 - 投影矩阵的
near值设得太大，把深度值压缩在一个很窄的范围里，深度区分度下降。
遇到深度闪烁，我通常先试试“反向Z”，再不行就把near调小一点。如果还不行，那就是渲染距离太远，需要做深度偏移或者在几何阶段对深度做预处理。
7.5 数据可视化：把深度缓冲“画”出来
最后一个调试技巧，是我强烈推荐的：运行中把深度缓冲保存成一张灰度图。很多时候光看颜色缓冲区，你很难判断深度问题出在哪。但如果你把depth buffer渲染成灰阶图像，一下子就能看出哪些像素的深度值是错的、哪里发生了“深度反转”。
方法很简单：遍历depth buffer，把每个深度值映射到0~255的灰度，写成一个.ppm或.bmp，或者直接用你熟悉的图像库输出。这是我排查光栅化问题最依赖的工具之一。
8. 延展与应用：从软光栅化到GPU管线
写一个软光栅化器的最大价值，不是“能用”，而是“能理解”。当你亲手用半平面法把三角形变成像素、亲手处理深度缓冲和透视校正之后，再去学习GPU的渲染管线，很多概念会瞬间变得具象。
GPU上的光栅化器其实是硬件的黑盒子，但它的核心行为和软件光栅化器一致：遍历三角形、生成片元、做深度测试。区别主要在于GPU有成千上万个小核心，可以同时处理几百个三角形和几百万个像素。因此GPU光栅化器在算法设计上会更强调数据并行和局部性，比如把屏幕分成tile，每个tile内的像素共享一部分数据，提高缓存命中率。
如果你以后想深入研究，可以沿着几个方向延伸：
- 延迟渲染：光栅化阶段只输出深度和几何信息到G-Buffer，光照在后续阶段统一计算，大幅提高多光源渲染效率。
- 可见性裁剪：在光栅化之前先做背面剔除、视锥剔除、遮挡剔除，减少进入光栅化阶段的三角形数量。
- GPU硬件光栅化细节：比如多边形的像素覆盖率计算、三角形的细分与LOD、光栅化中的负载均衡策略。
我个人在实际操作中的体会是：光栅化是图形学里数学和工程交叉得最紧密的一个环节。 你既需要扎实的线性代数和几何直觉，又需要耐心去排查那些浮点精度、边缘判定、像素中心的细节。做好了这个阶段，后面学光照、纹理、阴影都会顺利很多。如果第一次跑出来的三角形就完美显示，那恭喜你天赋异禀；如果你是跟我一样调了半天才发现是忘记除以w，那也别灰心——这种坑踩过一次，以后真的会刻骨铭心。