导出器与场景文件格式

一套数据，两种文件

C# 导出器遍历场景后产出两类文件，按”文本/二进制”分家：

• JSON：相机、光源、物体列表、材质、贴图路径、环境光系数、雾参数。描述”场景里有什么”，体积小、可读、便于人眼对照。
• mesh 二进制文件：每个网格单独存一份，装顶点位置、法线、切线、UV、三角形索引。描述”每个东西长什么样”，体量大、按字节读写。

这种拆分在图形数据交换里很常见——和 glTF 把 .gltf（JSON 描述）与 .bin（二进制几何）分开是同一个思路。

mesh 文件为什么不能塞进 JSON

JSON 是文本格式，一个 float 写成字符串平均占 8-10 字节；几十万顶点的网格直接膨胀成几十 MB 的纯文本，既慢又没法直接喂给 C++ 的顶点缓冲。改成二进制后，一个 vec3 就是固定 12 字节，加载器能 memcpy 整块读入内存，省去解析与转换。

二进制布局的代价是字节序和对齐必须写死。本项目跑在 x86/ARM 小端机上，导出器和加载器都按小端、紧凑排列（无 padding）约定，二者必须一致，否则顶点位置会乱掉。

顶点属性全齐

每个顶点带的属性决定了后续管线能算什么：

属性	用途
position（vec3）	顶点变换、光栅化、深度
normal（vec3）	光照（Lambert 余弦、PBR）
tangent（vec4，xyz+手性）	法线贴图变换到世界空间（TBN 矩阵）
uv（vec2）	贴图采样

少一项对应的渲染特性就跑不起来——例如没有 tangent 就没法用切线空间法线贴图。导出时必须把 URP 顶点流的完整集合都抓出来。

易错点

• JSON 里只放路径，不放像素。贴图本身不进 JSON，JSON 里只记 albedo.png 这种相对路径，加载器按路径去磁盘读 PNG。把图片 base64 进 JSON 是反模式。
• 三角形索引的绕序必须和 Unity 一致。Unity 在左手系下，正面三角形顶点按顺时针绕序（从相机看过去）。绕序反了，背面剔除会把正面误剔除，模型变成”空壳”。

参考

• glTF 规范（一 种类似的 文本+二进制 分离设计）
• Unity Mesh（顶点属性集合）

场景 JSON 的结构

场景描述文件是一份纯文本 JSON，记录”场景里有什么”。它的字段对应 Unity 场景的关键对象，是 CPU 渲染器的全部输入。

顶层结构

一份典型的场景 JSON：

{
  "camera": {
    "position": [0.0, 2.0, -5.0],
    "rotation": [0.0, 0.0, 0.0],
    "fov": 60.0,
    "near": 0.3,
    "far": 1000.0
  },
  "lights": [
    { "type": "directional", "direction": [...], "color": [...], "intensity": 3.0 },
    { "type": "spot", "position": [...], "direction": [...], "color": [...], "intensity": 8.0, "range": 15.0, "spotAngle": 60.0 }
  ],
  "ambient": {
    "shCoefficients": [ /* 27 个数 = 9 个 RGB */ ]
  },
  "fog": {
    "mode": "exponential",
    "color": [0.5, 0.6, 0.7],
    "density": 0.02
  },
  "objects": [
    { "mesh": "assets/workbench.mesh", "transform": { "position": [...], "rotation": [...], "scale": [...] }, "material": { "albedo": "albedo.png", "normal": "normal.png", "metallic": 0.0, "roughness": 0.7 } }
  ]
}

每个字段对应什么渲染量

字段	喂给渲染器的什么
camera	视图矩阵 $\mathbf{V}$、投影矩阵 $\mathbf{P}$（见 urp1 B11）
lights.directional	直接光的 $\mathbf{l}$、颜色、强度（urp2 B04）
lights.spot	锥形阴影的透视投影（urp2 B13）
ambient.shCoefficients	27 个 SH 系数，喂 SampleSH(n)（urp2 B06）
fog	雾公式参数（urp2 B16）
objects[].transform	每个物体的模型矩阵 $\mathbf{M}$
objects[].material	基础色贴图、法线贴图、PBR 参数

JSON 一份纯文本就把 URP 那一帧需要的全部”可调参数”描述完了。任何一项对不齐 Unity，画面就和 Unity 对不上。

transform 的旋转怎么存

Unity 的 Transform 用欧拉角（度）+ 固定旋转顺序（ZXY）。JSON 里直接存这三个角，加载时按 Unity 的约定转成旋转矩阵或四元数。如果旋转顺序错了，同样的三个角会产生不同朝向——所以”旋转顺序”是隐性约定，必须在加载器里写死与 Unity 一致（见 urp1 B09）。

易错点

• 角度 vs 弧度：Unity Inspector 显示度，但 Mathf.Sin 等要弧度。JSON 存度数时加载器要乘 $\pi/180$ 转弧度，常是”相机视角对不上”的根因。
• intensity 单位：URP 平行光的 lux、spot 的 candela 都不是裸 RGB 倍数。直接当 RGB 乘子会让画面整体偏亮或偏暗几倍，要按 URP 的单位换算（见 urp2 B07）。
• 颜色是 linear 还是 sRGB：JSON 里写的颜色值要明确空间——基础色是 sRGB（要转 linear 参与光照），光源颜色是 linear。混了会让整体色温错。

参考

• Unity Transform（旋转顺序）
• Unity Camera（fov/near/far）

mesh 二进制文件的字节布局

每个网格存成一个二进制 mesh 文件，里面是顶点位置、法线、切线、UV、三角形索引。加载器按字节读进来就是渲染器要的顶点缓冲。

为什么二进制不是 JSON

顶点数据量大（几万到几十万顶点 × 多个属性），文本 JSON 里一个 float 平均 8-10 字节、还要解析；二进制里一个 vec3 固定 12 字节，加载器 fread 一整块、memcpy 进顶点缓冲，零解析开销。这是图形数据交换的标准做法（glTF 的 .bin 同理）。

典型字节布局

文件头 + 顶点数组 + 索引数组：

+---------------------------+
| Header (固定大小)          |
|   magic, version          |
|   vertexCount, indexCount |
|   (各属性 offset/stride)  |
+---------------------------+
| Vertex Array              |
|   for each vertex:        |
|     position : float[3]   |  12B
|     normal   : float[3]   |  12B
|     tangent  : float[4]   |  16B  (xyz + 手性 w)
|     uv       : float[2]   |   8B
|   小计 stride = 48 字节    |
+---------------------------+
| Index Array               |
|   uint32[indexCount]      |  4B × indexCount
+---------------------------+

具体偏移和 stride 由 header 描述，加载器按 vertexStride * vertexCount 一次性读入顶点缓冲。

tangent 为什么是 vec4

切线存 vec4 不是浪费——第 4 个分量 $w$ 是手性符号（+1 或 -1），表示副法线（bitangent）该用 $\mathbf{n}\times\mathbf{t}$ 还是它的反方向。这是为了支持镜像 UV（左右对称的模型用同一张贴图、UV 翻转），副法线方向需要翻转。TBN 矩阵构造时：

$\mathbf{bitangent} = w \cdot (\mathbf{n} \times \mathbf{t})$

漏掉 $w$，镜像模型的法线贴图光照会反（凹变凸）。

索引数组的绕序

uint32 索引每 3 个一组表示一个三角形，三个索引指向顶点数组里的位置。绕序（顺/逆时针）决定正反面——Unity 左手系下正面是顺时针（见 urp1 B06）。绕序反了，背面剔除会把正面误剔除，模型看起来是”空壳”。

易错点

• 字节序（endianness）：小端机器（x86/ARM）写、小端机器读没问题；跨字节序平台（罕见）要显式转换。导出器和加载器约定一致即可。
• 对齐（alignment）：紧凑布局无 padding。如果加载器用 struct { vec3; vec3; vec4; vec2; } 直接强转，编译器可能在字段间插 padding 让 vec4 对齐 16 字节——结果 stride 和文件不匹配，顶点乱掉。要么 #pragma pack(1)，要么手动按 offset 读。
• float 精度：模型在世界原点附近时 float 精度够，远离原点（如坐标几万）会出现抖动。UE 用双精度/相机相对（origin rebasing）解决，本项目场景小够用。
• indexCount 必须是 3 的倍数，否则最后半个三角形无意义。

参考

• glTF 二进制缓冲区（类似的布局设计）
• Unity Mesh 顶点属性
• TBN 矩阵与切线手性

三处对齐：让 Unity 当标准答案

要把 CPU 复刻的画面逐像素和 URP 截图比，三处约定必须逐位一致——错一处整个对照就失去意义。

一、坐标系：左手系

Unity 是 左手坐标系（DirectX 风格）：$+x$ 向右、$+y$ 向上、$+z$ 向前（远离观察者）。这与 OpenGL / smallpt 的右手系相反。

左手系 vs 叉乘：叉乘 $\vec{a}\times\vec{b}$ 在左手系里遵循左手定则。这意味着法线、切线叉乘出来的副法线方向，和右手系教程里的符号相反。直接照搬网上右手系的代码会得到翻转的切线空间。

判断手系最稳的方法不是记”哪个轴向前”，而是看叉乘：在 Unity 里 $\hat{x}\times\hat{y}=\hat{z}$（因为 $+x$ 右、$+y$ 上、$+z$ 前），按左手定则成立。

二、矩阵约定

Unity 用 列主序（column-major）矩阵存储，即 Matrix4x4.m[row][col] 中第一维是行、第二维是列，但内存里按列连续存储。

变换一个点 $p$ 写成 $\mathbf{M}\cdot p$，即矩阵左乘列向量；多重变换按 $\mathbf{P}\mathbf{V}\mathbf{M}\,p$ 从右往左作用：先模型、再视图、最后投影。这套顺序与 DirectX HLSL 的 mul(M, v) 约定一致，和 GLSL 的 mul(v, M) 相反。

NDC 范围是另一个易错点：

API	裁剪空间 $z$ 范围（NDC）
OpenGL	$[-1, +1]$
Direct3D / Unity	$[0, +1]$

Unity（含 URP）在 Shader 里输出 clip-space 坐标，硬件做透视除后 $z \in [0,1]$，0 是近裁剪面、1 是远裁剪面。深度缓冲比较、自定义光栅化的深度插值都得用这个范围，否则深度测试反向、近远颠倒。

三、光照单位

URP 的直接光亮度单位是辐射度（radiance），整个光照在线性空间算，最后才做 sRGB 编码输出。三处必须对齐：

1. 贴图 sRGB 标志：基础色贴图是 sRGB 编码，采样时硬件自动 gamma→linear；法线/掩码贴图是 linear，不做转换。导出时必须把”这张贴图是不是 sRGB”记进 JSON，否则颜色会偏亮或偏暗 2.2 倍。
2. 平行光强度单位：URP 用 lux（勒克斯），渲染时换算成辐射度参与 BRDF，不是裸 RGB。
3. BRDF 归一化：漫反射项要除以 $\pi$（见 urp2 B07），高光项配相应的归一化因子。归一化常数错一个因子，亮度就整体偏。

参考

• Unity 矩阵约定（手册）
• Unity URP 光照单位与线性空间
• 左手/右手坐标系（维基百科）

顶点变换：模型到屏幕

每个顶点要经过三次矩阵乘法、四次”身份”切换：模型空间 → 世界空间 → 视图（相机）空间 → 裁剪空间 → 屏幕空间。

三个核心矩阵

矩阵	作用	由什么决定
$\mathbf{M}$（Model）	模型空间 → 世界空间	物体的位置、旋转、缩放（Transform）
$\mathbf{V}$（View）	世界空间 → 视图空间	相机的位置、朝向
$\mathbf{P}$（Projection）	视图空间 → 裁剪空间	透视/正交 + 视野角、宽高比、near/far

完整变换：

$v_{clip} = \mathbf{P}\,\mathbf{V}\,\mathbf{M}\, v_{model}$

由于矩阵左乘列向量，作用顺序从右往左：先模型、再视图、最后投影。CPU 实现里通常预先把 $\mathbf{MVP}=\mathbf{P}\mathbf{V}\mathbf{M}$ 算好，每个顶点只乘一次。

透视投影矩阵的形状

Unity（左手系、NDC $z\in[0,1]$、列主序）的透视投影矩阵，对垂直视野角 fov、宽高比 aspect、近远面 $n,f$：

$$\mathbf{P} = \begin{bmatrix} \frac{1}{\text{aspect}\cdot\tan(\text{fov}/2)} & 0 & 0 & 0 \\ 0 & \frac{1}{\tan(\text{fov}/2)} & 0 & 0 \\ 0 & 0 & \frac{f}{f-n} & 1 \\ 0 & 0 & -\frac{fn}{f-n} & 0 \end{bmatrix}$$

注意两个细节：

1. $z$ 行的 $+1$ 平移到 $w$：投影后 $w_{clip}=z_{view}$（视图空间的深度，正值因为 $+z$ 朝前）。这正是后面做透视除法和透视校正插值的依据。
2. $z_{ndc}=\frac{f\cdot z_{view}-fn}{(f-n)\cdot z_{view}}$：是非线性的，近处精度高、远处精度低。这就是为什么 depth fighting 和阴影 acne 多发生在远处。

视图矩阵从相机三向量构造

视图矩阵是把”世界变到相机眼里”，等价于把相机搬到原点、朝 $-z$ 看（Unity 相机本地空间 $+z$ 朝前，视图空间约定则视实现而定）。设相机右、上、前三个单位向量为 $\mathbf{r},\mathbf{u},\mathbf{f}$，位置 $\mathbf{c}$：

\mathbf{r}^T & -\mathbf{r}\cdot\mathbf{c} \\ \mathbf{u}^T & -\mathbf{u}\cdot\mathbf{c} \\ \mathbf{f}^T & -\mathbf{f}\cdot\mathbf{c} \\ 0 & 1 \end{bmatrix}

旋转部分（上 $3\times3$）是相机三个轴的转置，因为”把世界变到相机本地”是相机本地变到世界的逆变换；平移部分先把相机挪到原点。

透视除法与到屏幕

裁剪空间是齐次坐标 $(x,y,z,w)$。透视除法把前三项除以 $w$：

$v_{ndc} = \left(\frac{x}{w}, \frac{y}{w}, \frac{z}{w}\right), \quad w = z_{view} > 0$

NDC 范围 $x,y\in[-1,1]$，$z\in[0,1]$（Unity）。最后映射到屏幕像素：

$$x_{screen} = \frac{x_{ndc}+1}{2}\cdot W,\qquad y_{screen} = \frac{1-y_{ndc}}{2}\cdot H$$

注意 $y$ 要翻转：NDC 的 $+y$ 朝上，而图像像素的行号朝下。这一步漏掉，画面会上下颠倒。

易错点

• $\mathbf{M}$ 里要带缩放：物体有非均匀缩放时，法线不能直接用 $\mathbf{M}$ 变换，要用 $\mathbf{M}^{-1}$ 的转置（即逆转置矩阵），否则法线方向会被拉斜。光照因此全错。
• fov 是垂直角：URP Camera.fieldOfView 是垂直 FOV，水平 FOV 由 aspect = W/H 推出。混淆水平和垂直会把画面横向压扁或拉伸。
• 裁剪在透视除法之前做：必须用裁剪空间坐标（带 $w$）裁剪，不能拿 NDC 裁——除以 $w=0$ 或接近 0 的顶点会爆。

参考

• 变换矩阵与渲染管线（维基百科）
• Unity Camera.fieldOfView（垂直 FOV）
• 透视投影矩阵推导

裁剪：切掉画面外

裁剪（clipping）发生在裁剪空间、透视除法之前。目的是把伸出视锥体的三角形切干净，避免后面光栅化时除以 $w\le0$ 爆炸，也省掉看不见的像素。

六个裁剪平面

视锥体在裁剪空间是个立方体，由六个不等式界定：

平面	条件
左 / 右	$-w \le x \le +w$
下 / 上	$-w \le y \le +w$
近 / 远	$0 \le z \le w$（Unity NDC $z\in[0,1]$）

注意 $w = z_{view}$，所以这些边界是”距相机远近”的边界，不是固定数值——这正是用齐次坐标裁剪的精妙：远近裁剪面、视野张角都自动并入到 $w$ 比较里。

Sutherland–Hodgman 多边形裁剪

对每个三角形，逐个用六个平面切一遍。经典算法是 Sutherland–Hodgman：对当前多边形的每条边，按”起点在内/外、终点在内/外”四种情况输出顶点：

for each 平面 P:
    对当前多边形每条边 (S, E):
        if E 在内:
            if S 在外: 输出交点(S→P)
            输出 E
        elif S 在内:
            输出交点(S→P)        # 只在跨过边界时补一个点

一个三角形被某个平面切到，输出最多变成四边形，再三角化成两个三角形——切出来的缺口就是这样被补成几个小三角形的。逐平面迭代，三角形最多被切成七边形。

交点用线性插值求

边上从 $S$ 到 $E$ 的交点参数 $t$，以左平面 $x=-w$ 为例：

$\frac{x_S + t(x_E-x_S)}{w_S + t(w_E-w_S)} = -1$

解出 $t$，再线性插值位置、UV、颜色等所有顶点属性——属性必须和位置同步插值，否则贴图在裁剪边界处错位。硬件管线里这一步是免费的（硬件裁剪单元自动做），CPU 实现要自己写。

整块丢弃

如果三角形三个顶点全在某个平面外，整个三角形不可见，直接丢弃，不进光栅化——这是裁剪的核心收益：避免对画面外的像素白做一遍覆盖测试和深度测试。

部分顶点在外的才走 Sutherland–Hodgman；全部在内的（最常见情况）原样通过。

易错点

• 必须裁剪空间裁，不能 NDC 裁。先除 $w$ 再裁剪，跨过 $w=0$ 的三角形会算出无穷大坐标。标准做法保留齐次坐标裁剪。
• 属性插值要带 $w$。后面光栅化要做透视校正插值（见 B14），裁剪阶段产生的交点顶点也必须带上正确的 $w$，否则边界处 UV 跳变。
• 背面剔除不等于裁剪。背面剔除按绕序判断三角形的”朝向”，与裁剪是两件事，常在裁剪前做以减少工作量，但不能替代裁剪。

参考

• Sutherland–Hodgman 算法（维基百科）
• 齐次坐标裁剪

光栅化：三角形铺成像素

光栅化（rasterization）回答一个问题：屏幕上的哪些像素中心点落在某个三角形内部？把这些像素找出来，就完成了”连续三角形 → 离散像素”的转换。

包围盒加速

暴力遍历屏幕所有像素、逐个判断在不在三角形里，太慢。先算三角形的轴对齐包围盒（AABB）：

$$x_{min}=\min(x_0,x_1,x_2),\quad x_{max}=\max(x_0,x_1,x_2)\\ y_{min}=\min(y_0,y_1,x_2),\quad y_{max}=\max(y_0,y_1,x_2)$$

只对 $[x_{min},x_{max}]\times[y_{min},y_{max}]$ 里的像素做覆盖测试。窄长条/小三角形的实际像素数远少于全屏，这一步通常省掉 95% 以上的判断。

像素中心采样约定

判断”像素在不在三角形里”用的是像素中心点 $(x+0.5, y+0.5)$，不是像素左上角。这是硬件光栅化的标准约定（D3D/GL 都是）。漏掉 $+0.5$ 会让画面整体偏移半个像素、纹理对不齐。

边函数（Edge Function）判断

判断点 $P$ 在三角形哪一侧，用叉积的 $z$ 分量。对边 $V_0 \to V_1$：

$E_{01}(P) = (x_1-x_0)(P_y-y_0) - (y_1-y_0)(P_x-x_0)$

三条边算出三个 $E$ 值，同号即在内部（左手系下顺时针绕序的正面三角形，三个 $E\ge0$）。某条边 $E=0$ 表示点恰在边上。

bool inside(float px, float py, Vec2 v0, Vec2 v1, Vec2 v2) {
    auto edge = [](Vec2 a, Vec2 b, Vec2 p){
        return (b.x-a.x)*(p.y-a.y) - (b.y-a.y)*(p.x-a.x);
    };
    float e0 = edge(v0, v1, {px, py});
    float e1 = edge(v1, v2, {px, py});
    float e2 = edge(v2, v0, {px, py});
    // 顺时针正面三角形：三个值同号（都 >=0）
    return (e0>=0 && e1>=0 && e2>=0);
}

三个 $E$ 值还顺便给出了重心坐标（见 B14），不用再算一次——这是边函数法相对其他判断法的隐藏好处。

top-left rule 处理共享边

相邻两个三角形共享一条边，按上面规则会都判定该边上的像素属于自己，导致共享边像素被画两次，混色出错。解决是 top-left rule：

• 边是”水平的且在上”（top edge，两端点 $y$ 相等且 $x$ 增大方向），或
• 边是”左侧”（left edge，$y$ 增大方向）；

满足 top-left 的边用 $E\ge0$，其余边用 $E>0$（严格大于）。这样每条共享边只归属其中一个三角形，像素不重不漏。

易错点

• 绕序决定符号方向。顺时针和逆时针三角形，“内部”对应的 $E$ 符号相反。左手系顺时针为正面，照搬右手系教程的 >=0 会把背面也画进来。
• 像素中心是 $(x+0.5, y+0.5)$，不是整数 $(x,y)$。
• 整数坐标 vs 浮点。生产级光栅化把顶点和边函数都定点化（fixed-point）以保证子像素精度和确定性；纯 float 实现可能在三角形边缘出现缝隙或抖动。

参考

• 光栅化（维基百科）
• 重心坐标 / edge functions（论文）
• Top-left rule（Microsoft 文档）

重心坐标与透视校正插值

三角形只有三个顶点有数据（UV、颜色、法线等），中间成千上万像素的属性靠插值得到。直接线性插值会出错——必须做透视校正。

重心坐标

三角形内任一点 $P$ 可写成三个顶点的仿射组合：

$P = \alpha V_0 + \beta V_1 + \gamma V_2,\qquad \alpha+\beta+\gamma=1$

$(\alpha,\beta,\gamma)$ 就是重心坐标，每个分量对应一个顶点的”权重”。它们和光栅化阶段算出的边函数 $E$ 成正比：

$\alpha : \beta : \gamma = E_{12} : E_{20} : E_{01}$

除以三者之和归一化（和等于三角形面积的两倍）。所以拿到 $E$ 就能直接插值，不用另求。

朴素插值为什么错

如果直接用屏幕空间的 $\alpha,\beta,\gamma$ 去插值顶点的 UV：

$uv = \alpha\, uv_0 + \beta\, uv_1 + \gamma\, uv_2$

近处的东西看起来大、远处小，这种线性平均忽略了透视收缩。直观后果：地面上一排笔直的地砖缝，会扭曲成”中间鼓、两端翘”——这就是地砖直线扭曲变形的根源。

透视校正：除以 $w$ 再插值

正确做法来自齐次坐标的性质。设顶点 $i$ 的属性 $a_i$，视图空间深度 $w_i=z_{view,i}$，则像素的属性应满足：

$\frac{a}{w} = \alpha\frac{a_0}{w_0} + \beta\frac{a_1}{w_1} + \gamma\frac{a_2}{w_2}$

而像素的 $1/w$ 也按同样权重插值：

$\frac{1}{w} = \alpha\frac{1}{w_0} + \beta\frac{1}{w_1} + \gamma\frac{1}{w_2}$

最后相除还原：

$a = \frac{\alpha\,a_0/w_0 + \beta\,a_1/w_1 + \gamma\,a_2/w_2}{\alpha/w_0 + \beta/w_1 + \gamma/w_2}$

也就是”先除以 $w$ 插值，再乘回 $w$“。深度本身也要透视校正插值——否则深度缓冲的数值不是真正的视图深度，深度测试和阴影会错。

// a0,a1,a2 是三个顶点的某属性，w0,w1,w2 是裁剪空间 w (=视图深度)
float invW = alpha/w0 + beta/w1 + gamma/w2;
float a    = (alpha*a0/w0 + beta*a1/w1 + gamma*a2/w2) / invW;
float depth = (1.0f) / invW;   // 像素的视图深度，写进深度缓冲

为什么屏幕线性插值对深度本身也不行

这是初学者最常踩的坑。直觉是”屏幕空间直线插值深度，能行吧？“——不行。透视投影把直线变成仍然直的屏幕线，但沿这条线的深度不是线性变化的：远处 $z$ 变化慢、近处快。直接屏幕线性插值，会让深度缓冲在远处给出错误值，引发 z-fighting 或本该被遮挡的物体浮到前面。深度必须走透视校正公式。

易错点

• 法线插值后要归一化。透视校正后法线长度不再是 1，参与点积前要 normalize，否则光照亮度偏。
• 插值的是视图空间 $w$，不是 NDC 的 $z$。NDC 的 $z$ 已经非线性的，再插值会错上加错。
• 顶点位置本身一般用屏幕坐标（已经透视除过），不需要再校正；但属性（UV、颜色、法线）必须校正。两者别混。

参考

• 透视校正插值（维基百科）
• 重心坐标插值（教材）

深度缓冲：谁挡住谁

同一个像素可能被多个三角形覆盖。决定最终显示哪个，靠一块和帧缓冲等大的深度缓冲（depth buffer / z-buffer）。

一像素一深度

深度缓冲为每个像素存一个”到相机的距离”（严格说是视图空间深度 $z_{view}$，或 NDC 的 $z\in[0,1]$）。流程：

清屏时把整个深度缓冲填成最远值（Unity NDC 是 1）
对每个被光栅化覆盖的像素：
    if 新片元的深度 < 缓冲里的深度:    # "更近"在 Unity 是数值更小
        写入新颜色
        更新深度缓冲为新深度
    else:
        丢弃（被挡住了）

这种”画谁比一次远近、近的覆盖远的”使得绘制顺序无关——先画远处再画近处、或反过来，结果一样。这是 z-buffer 算法相比画家算法（按深度排序绘制）最大的优势：画家算法对相互穿插的三角形无法排序，z-buffer 可以。

比较的是哪个深度

不同实现存的不一样，常见两种：

存的内容	范围	“更近”
NDC 的 $z$	$[0,1]$（Unity）	数值更小
反向 Z（reversed-Z）	$[0,1]$，近=1 远=0	数值更大

URP 现代实现普遍用 reversed-Z：把 near 映射成 1、far 映射成 0。配合浮点深度缓冲（24/32 位），能把浮点精度在 $[0,1]$ 上”近处稠密”的特性抵消掉透视投影”远处稠密”的不均，使整段深度精度更均衡，减少远处 z-fighting。CPU 复刻要和 URP 用同样的方向，否则比较符号反、画面全错。

深度的非线性

经透视投影后 NDC $z$ 与视图空间 $z_{view}$ 关系是：

$z_{ndc} = \frac{f\cdot z_{view} - fn}{(f-n)\cdot z_{view}}$

这是非线性映射，远处 $z_{ndc}$ 变化极慢。后果：

• 远处两块很近的表面，$z_{ndc}$ 几乎相同，浮点精度区分不开，画面出现”两面交替闪烁”的 z-fighting。
• 这也是为什么阴影 acne（urp2 B14）容易在远处发生——深度精度差。

深度测试 vs 透明

深度缓冲只适合不透明物体。透明物体（玻璃、半透明粒子）不能用”近的覆盖远的”粗暴策略，因为要保留后面物体的颜色做 alpha 混合：

1. 不透明阶段：开深度写入、开深度测试，正常 z-buffer。
2. 透明阶段：开深度测试（被不透明物体挡住的不画）、关深度写入，按”从远到近”画家顺序绘制并做 alpha 混合。

URP 的渲染队列（Transparent vs Opaque）和这两阶段对应。

易错点

• 比较方向跟着 reversed-Z 走。默认 < 还是 > 取决于是否反向 Z。从 URP 抓出来的投影矩阵和深度比较函数必须配套。
• 清屏值不是 0。传统是清成最远（1 或 far），reversed-Z 是清成 0。
• 透明物体关深度写，否则它会挡住后面本该看见的物体。
• 深度函数（depth func）和深度写入（zwrite）是两件事。LessEqual 是测试条件，On/Off 是是否更新缓冲，可独立设置。

参考

• 深度缓冲（维基百科）
• Reversed-Z 精度优化
• Unity URP 渲染队列

多线程光栅化

CPU 单线程跑光栅化太慢。本项目按横向条带把帧缓冲切成多块，每个线程负责一块。

为什么按行条带切

图像是逐行存储的（行优先内存布局）。把屏幕按 $y$ 切成若干连续行段，每段内存连续、互不重叠，线程各自读写自己那段不需要加锁：

线程 0: 行 [0,      H/T)
线程 1: 行 [H/T,    2H/T)
...

任务划分就是”哪个线程画哪些行”。三角形遍历时，先算它屏幕 AABB 落在哪几条带的 $y$ 范围内，只把这些条带分给对应的线程。

共享数据 race-free 的关键

• 帧缓冲和深度缓冲按像素独立：每个像素只有一个线程写（光栅化保证同像素不会被两个线程同时覆盖，因为像素按行分配）。无需互斥锁。
• 只读数据共享：场景三角形、贴图、材质、变换矩阵都是只读，所有线程并发读没问题。

只要划分按”像素归属”做、且边界像素明确属于唯一线程，就不会有数据竞争。这是光栅化能高效并行的基础。

负载均衡

朴素等分条带会不均衡：天空区域里几个大三角形早早画完，工具密集区有大量小三角形和深度竞争，慢线程拖累整帧。常见改进：

• 更细的 tile（如 $32\times32$）+ 工作队列：线程从队列抢 tile，谁先空谁领下一个。tile 越小负载越均衡，但每个 tile 的启动开销和 AABB 重算越多。
• 按三角形排序：把大三角形先画（占像素多，早分摊掉）。

硬件 GPU 的瓦片化渲染（tile-based rendering，移动端尤其）走的就是更细 tile 的思路，连片上缓存（tile memory）都用上了。

CPU 多核的现实

CPU 复刻的目标是”靠多核把一帧压到可接受时间”。这里没有 GPU 那种数千核的并行度，CPU 通常几十核，加上每个线程单像素成本远高于 GPU（无硬件插值单元、无硬件深度比较），所以 CPU 复刻是教学用，速度上不可能和 GPU 比。价值在于每一步都能停下来打印、单步、可视化中间量——GPU 调试很难做到。

易错点

• 条带边界像素归属要明确。[y_min, y_max) 半开区间，否则相邻条带的边界行被画两次或漏掉。
• 深度缓冲也按同样的像素归属分。不能让两个线程同时比较并写同一像素的深度。
• 浮点求和的非确定性：多线程下累加顺序不同，浮点结果可能有最后一两位差异，跨线程对照 Unity 时要留容差，不能要求 bit 级一致。

参考

• Tile-based 渲染（维基百科）
• 图形管线并行（GPU 硬件视角）