1. 为什么第四章“变换”值得单独写一篇笔记
《Real-Time Rendering》第四版（简称RTR4）的第四章叫Transforms，中文一般译作“变换”。很多人翻这本书的时候，前三章还能耐着性子看，到了第四章就开始加速——因为公式多、矩阵多、符号多，看着像线性代数复习课。但我自己的体会恰恰相反：第四章是整本书里性价比最高的一章。原因很简单，渲染管线里几乎所有“东西为什么会出现在屏幕上那个位置”的问题，答案都落在这一章。
举个最日常的例子。你在引擎里把一个模型从原点挪到(3, 0, 5)，旋转45度，再放大两倍。引擎内部到底发生了什么？它并不是依次对模型的每个顶点做三次独立操作，而是把这三个操作“压”成一个4×4矩阵，然后一次性乘到顶点上。这个“压”的过程，就是第四章讲的核心：变换的复合（composition）。理解了它，你才能明白为什么变换的顺序不能随便换、为什么法线不能直接用模型矩阵变换、为什么有些旋转会出现“万向节死锁”这种听起来很玄的问题。
这篇笔记我打算按“从业者视角”来写，不是逐页翻译，而是把第四章里真正会在实际开发中反复用到的部分拎出来，配上我自己的理解、踩过的坑和能直接抄的代码。适合两类人看：一类是正在啃RTR4、被矩阵绕晕的读者；另一类是做图形/引擎/游戏开发，想把这章的知识真正落到代码里的人。如果你只是想应付考试，那这篇可能不太适合；但如果你想搞明白“变换到底在管线里怎么流动”，往下看就对了。
需要先说明一点：RTR4第四章的内容其实相当完整，从基础的仿射变换、矩阵表示，到欧拉角、四元数、法线变换、逆变换，再到更偏理论的变换分类，都有覆盖。我这篇不会面面俱到，而是挑出实际开发中出现频率最高的几个主题深入展开，其余部分点到为止。这也是我读技术书的一贯做法——第一遍通读建立地图，第二遍只精读会用到的那几条路。
2. 仿射变换的矩阵表示：4×4到底多出来的那一行是干嘛的
2.1 从3×3到4×4：平移为什么塞不进去
线性代数里，3×3矩阵能表示旋转和缩放，但表示不了平移。原因很直白：矩阵乘法本质上是线性组合，而线性变换一定把原点映射到原点。你拿一个3×3矩阵去乘零向量，结果永远是零向量，可平移偏偏要把原点挪走。所以纯3×3矩阵天生做不了平移。
解决办法是升维。把三维点写成四维齐次坐标(x, y, z, 1)，把三维向量写成(x, y, z, 0)，然后用4×4矩阵统一处理。多出来的那一维就是“翻译官”，专门负责把平移这件事塞进矩阵乘法里。RTR4里把这个结构写得很清楚：
[ m00 m01 m02 tx ] [ m10 m11 m12 ty ] [ m20 m21 m22 tz ] [ 0 0 0 1 ]左上角3×3负责旋转和缩放，最右一列(tx, ty, tz)负责平移，最下面一行固定是(0, 0, 0, 1)。这个结构就是**仿射变换（affine transform）**的标准形式。仿射的意思是：变换后直线还是直线，平行线还是平行线，但角度和长度可能变。旋转、缩放、平移、错切（shear）都属于仿射变换。
这里有个特别容易被忽略的点：齐次坐标里w分量的取值决定了这个四维量是“点”还是“向量”。w=1是点，w=0是向量。为什么？因为向量没有位置概念，平移不应该影响它。你拿上面那个矩阵去乘(x, y, z, 0)，最右一列的tx、ty、tz乘的是0，平移自然就被“吃掉”了。这个设计非常优雅，我第一次真正理解它的时候有种“原来如此”的感觉。
2.2 行向量还是列向量：一个必须一开始就定死的约定
RTR4在这一章专门提醒过：矩阵表示有两种约定，行向量约定和列向量约定，两者互为转置。DirectX传统上偏行向量（向量在左，矩阵在右，v·M），OpenGL和大多数数学库偏列向量（矩阵在左，向量在右，M·v）。这不是谁对谁错的问题，纯粹是历史习惯。
但这件事在实际开发里会要命。如果你从网上抄了一段矩阵代码，没注意它是行向量约定，直接塞进列向量约定的引擎里，结果就是模型要么消失、要么扭曲、要么旋转方向反了。我早期就干过这种事：一个旋转矩阵抄过来，模型转是转了，但转的方向和预期相反，排查了半天才发现是转置问题。
我的建议是：项目一开始就统一约定，并且写进团队规范。如果你用列向量，那么复合变换的顺序是从右往左读，M = T · R · S 表示先缩放、再旋转、最后平移。如果你用行向量，顺序反过来，M = S · R · T。两种写法数学上等价，但混用必出bug。判断一个库用哪种约定，最简单的办法是看它的平移矩阵：平移量出现在最后一列就是列向量约定，出现在最后一行就是行向量约定。
2.3 变换复合：顺序为什么不能随便换
这是第四章最核心、也最容易出错的知识点。变换复合（concatenation / composition）指的是把多个变换矩阵相乘成一个矩阵。关键在于：矩阵乘法不满足交换律，所以顺序至关重要。
拿一个具体场景说。你想把一个模型先绕Z轴旋转90度，再沿X轴平移5个单位。用列向量约定：
- 先旋转后平移：M = T · R
- 先平移后旋转：M = R · T
这两个结果完全不同。第一种情况下，模型先转好，然后整体挪到X=5的位置；第二种情况下，模型先挪到X=5，然后绕原点旋转90度，结果它会被甩到Y=5的位置去。这就是为什么很多人调模型位置时发现“我明明设了平移，怎么模型跑到别的地方了”——大概率是复合顺序搞反了。
RTR4里给了一个很实用的记忆法：从右往左读复合矩阵，就是变换的应用顺序（列向量约定下）。M = T · R · S，读作“先S，再R，最后T”。这个读法我用了很多年，几乎没再出过错。
再补一个实际经验：在层级骨骼动画里，子节点的世界变换是父节点世界变换乘以子节点局部变换，即 M_world = M_parent · M_local。这个式子看起来简单，但如果你把顺序写反，骨骼就会以完全错误的方式运动。我见过不少新手在这里卡住，其实只要记住“父变换作用在子变换的结果之上”，顺序就不会错。
3. 旋转的三种表达：欧拉角、矩阵、四元数到底怎么选
3.1 欧拉角：最直观，也最容易出事
欧拉角用三个角度（比如绕X、Y、Z的pitch、yaw、roll）表示旋转，人读起来最直观，所以在编辑器UI、动画关键帧、调试面板里几乎无处不在。但它的坑也是最多的。
第一个坑是旋转顺序。绕X、Y、Z三个轴旋转，先转哪个后转哪个，结果完全不同。常见的顺序有XYZ、ZYX、YXZ等，不同软件默认顺序可能不一样。你在A软件里调好的角度，导到B软件里可能就歪了，很多时候就是顺序不一致。
第二个坑是万向节死锁（gimbal lock）。当中间那个旋转轴转到±90度时，另外两个轴会重合，导致失去一个自由度。表现就是：你怎么调其中一个角度，模型都不按预期转。RTR4里对这个问题有专门讨论。死锁不是数学bug，而是欧拉角这种表示方式固有的缺陷。
第三个坑是插值不自然。两个欧拉角之间做线性插值，得到的旋转路径往往不是最短路径，转起来会“绕远路”甚至抖动。做相机平滑、角色转向时这个问题特别明显。
所以我的经验是：欧拉角只用来做输入和显示，不用来做内部计算和插值。编辑器里让美术用欧拉角调，存到运行时立刻转成四元数或矩阵。
3.2 旋转矩阵：计算友好，但会累积误差
旋转矩阵用3×3（或4×4左上角）表示旋转，优点是直接能参与矩阵乘法，和缩放、平移复合起来很自然，GPU也喜欢。渲染管线里最终用的基本都是矩阵。
但它有两个问题。一是存储冗余：一个旋转只有3个自由度，矩阵却用了9个数，而且这9个数还必须满足正交性（每列单位长度、两两垂直）。二是数值漂移：经过大量矩阵连乘后，浮点误差会让矩阵慢慢偏离正交，表现为模型被轻微拉伸或扭曲。做长时间运行的物理模拟或骨骼动画时，这个漂移会累积。
解决办法是定期正交化（orthonormalization）。常用的是Gram-Schmidt过程，或者用四元数转矩阵来“重置”。我在做长时间骨骼动画时，会每隔若干帧把累积的旋转矩阵重新正交化一次，效果立竿见影。
3.3 四元数：插值和复合的最优解
四元数（quaternion）用四个数(qx, qy, qz, qw)表示旋转，是RTR4第四章的重点之一。它的核心优势有三个：
- 紧凑：4个数，比矩阵省。
- 复合高效：两个四元数相乘就能复合旋转，比矩阵乘法快。
- 插值平滑：球面线性插值（slerp）能沿最短弧插值，转向自然。
四元数最反直觉的地方是它没有直观的几何意义，你没法“想象”一个四元数长什么样。但用起来其实不难，记住几个操作就够了：单位四元数(0,0,0,1)表示无旋转；四元数乘法复合旋转；共轭（或逆）表示反向旋转；转矩阵有一套固定公式。
实际开发里，我的标准做法是：内部旋转状态一律用四元数存，需要参与矩阵复合时转成矩阵，需要给UI显示时转成欧拉角。这样既避免了欧拉角的死锁和插值问题，又避免了矩阵的漂移。RTR4里也推荐在需要插值的场合优先用四元数。
这里补一个容易踩的坑：四元数乘法不满足交换律，q1·q2和q2·q1表示不同的复合顺序。而且四元数有“双倍覆盖”特性，q和-q表示同一个旋转。做插值时如果不处理这个，可能会让物体转一大圈而不是走短路径。标准做法是在slerp前检查点积，如果为负就把其中一个取反。
4. 法线变换：为什么不能直接用模型矩阵
4.1 一个让很多人栽跟头的问题
这是第四章里我认为最实用、也最容易被忽视的一个知识点。假设你有一个模型矩阵M，用来变换顶点位置。那法线是不是也直接乘M就行了？答案是：大多数情况下不行。
原因在于法线的定义。法线是垂直于表面的向量，它描述的是“朝向”，不是“位置”。当你对模型做非均匀缩放（比如X方向拉长2倍、Y方向不变）时，表面的几何形状变了，法线的方向也跟着变，但它变化的方式和顶点位置不一样。如果你直接用M变换法线，得到的方向可能不再垂直于变换后的表面，光照就会出错——表现为高光位置偏移、明暗过渡怪异。
RTR4里给出的正确做法是：法线应该用模型矩阵的逆转置矩阵（inverse transpose）来变换，即 n' = (M⁻¹)ᵀ · n。这个结论的推导不复杂：因为法线和切线始终垂直，而切线用M变换，要让n'·t' = 0成立，n'就必须用(M⁻¹)ᵀ变换。书里有完整推导，我这里只强调结论和实操。
4.2 什么时候可以偷懒，什么时候不能
逆转置矩阵虽然正确，但计算有成本（要求逆）。所以实际开发里有个常见的优化判断：
- 如果模型矩阵只包含旋转和平移（没有缩放，或只有均匀缩放），那么逆转置矩阵和原矩阵的旋转部分只差一个缩放因子，归一化后可以直接用M变换法线。
- 如果包含非均匀缩放，就必须老老实实用逆转置。
我自己的做法是：在材质/着色器里统一用逆转置，除非性能分析明确显示这里是瓶颈。因为“忘记处理非均匀缩放”导致的bug非常隐蔽，往往要等到美术把某个模型拉扁之后才暴露，排查成本远高于那点矩阵求逆的开销。
还有一个相关细节：法线变换后要重新归一化。因为逆转置可能改变法线长度，不归一化的话光照强度会不对。这个在片元着色器里通常顺手就做了，但如果你在顶点着色器里传法线，别忘了在插值后归一化。
4.3 切线空间与法线贴图场景下的连锁影响
现在法线贴图几乎是标配，这就把法线变换的问题又推进了一层。法线贴图里的法线是定义在**切线空间（tangent space）**里的，要把它转到世界空间，需要构造TBN矩阵（切线、副切线、法线）。而TBN的构造又依赖于正确的法线和切线变换。
如果模型矩阵有非均匀缩放，切线也要用M变换（切线是切向量，和顶点一样用M），法线用逆转置，然后重新正交化构造TBN。这一串操作里任何一步用错矩阵，法线贴图的效果就会整体偏掉。我见过最典型的表现是：模型被非均匀缩放后，法线贴图的高光“粘”在错误的位置，看起来像贴图本身画错了，其实是变换矩阵用错了。
所以我的建议是：在导入管线里就把非均匀缩放烘焙进顶点数据，让运行时矩阵尽量只含旋转、平移和均匀缩放。这样能规避掉一大类法线相关的诡异问题。这个做法在RTR4里没有明说，但属于工程上的常见实践。
5. 逆变换与变换分解：从矩阵里“读”出参数
5.1 逆变换：撤销一个变换
逆变换（inverse transform）在实际开发里用得非常多。比如：
- 鼠标点击屏幕，要把屏幕坐标反投影回世界空间，做拾取（picking）。
- 把世界空间的点转到模型的局部空间，做碰撞检测或局部效果。
- 撤销一个变换，回到变换前的状态。
对于仿射变换，逆矩阵有解析解，不需要通用求逆。RTR4里给了公式：如果M由旋转R、平移T、缩放S组成，那么M⁻¹可以按相反顺序、用各自的逆来构造。具体来说，旋转的逆是转置（正交矩阵的逆等于转置），平移的逆是反向平移，缩放的逆是倒数缩放。
这里有个实操技巧：能用解析逆就别用通用求逆。通用4×4求逆涉及大量除法和行列式计算，数值稳定性也差。而仿射矩阵的解析逆又快又稳。我在做屏幕拾取时，就是先构造视图投影矩阵的解析逆，把屏幕点反投影回世界，比通用求逆快不少，而且不会在矩阵接近奇异时炸掉。
5.2 变换分解：从矩阵反推T、R、S
有时候你拿到一个矩阵，想知道它到底包含了什么平移、旋转、缩放。这就是变换分解（decomposition）。常见于：
- 从物理引擎拿到一个变换矩阵，想取出其中的旋转做插值。
- 调试时想看看某个矩阵的缩放是不是(1,1,1)。
- 把矩阵形式的动画数据转成四元数形式。
分解的基本思路是：平移直接从最后一列（列向量约定）读出来；缩放是各列向量的长度；旋转是各列归一化后组成的矩阵。但这里有个陷阱：如果存在错切（shear），分解就不唯一，而且简单的“取列长度”方法会出错。RTR4里也提到了这一点。
我的经验是：分解前先确认矩阵是纯仿射且不含错切。如果确实含错切，要么用更复杂的极分解（polar decomposition），要么干脆避免在管线里产生错切。错切通常来自非均匀缩放和旋转的复合，所以前面说的“把非均匀缩放烘焙进顶点”也能顺带避免错切问题。
5.3 一个实际案例：从世界矩阵反推局部朝向
说个具体场景。做角色朝向时，我拿到角色的世界变换矩阵，想让它“面朝”某个目标点。做法是：从世界矩阵里分解出当前位置（平移部分），然后构造一个从当前位置指向目标的旋转，再重新复合出新的世界矩阵。
这里的关键是分解出的旋转要保证正交。如果原矩阵因为长时间累积有漂移，分解出的旋转就不准，角色朝向会偏。所以我在分解前会先对旋转部分做一次正交化。这个细节RTR4没有专门强调，但在实际项目里非常有用。
6. 投影变换：从三维到二维的那一步
6.1 正交投影与透视投影的本质区别
投影变换（projection transform）严格说属于第四章变换的延伸，也是渲染管线里最关键的一步。它把视锥体内的三维点映射到一个标准立方体（NDC，标准化设备坐标）里，之后GPU再做视口变换映射到屏幕。
两种投影：
- 正交投影（orthographic）：平行线投影后仍平行，没有近大远小。用于CAD、2D游戏、阴影贴图等。
- 透视投影（perspective）：近大远小，符合人眼。用于绝大多数3D场景。
透视投影矩阵里那个“除以w”的操作（透视除法）是精髓。矩阵本身不直接做除法，而是把“距离”信息编码进w分量，让GPU在后续步骤里自动除以w。这就是为什么齐次坐标的w分量这么重要——它承载了透视信息。
6.2 投影矩阵参数怎么算
透视投影矩阵通常由四个参数决定：垂直视场角（fovY）、宽高比（aspect）、近裁剪面（near）、远裁剪面（far）。矩阵元素有标准公式，RTR4里有完整推导。我这里只强调几个实操要点：
- near不能设成0。near=0会导致矩阵奇异，深度精度也会崩。一般设0.1或0.01，看场景尺度。
- far/near比值影响深度精度。比值越大，远处深度精度越差，容易出现Z-fighting（深度冲突）。所以far不要设得离谱地大。
- 反转Z（reverse-Z）是现在很多引擎的做法，把near映射到1、far映射到0，配合浮点深度缓冲能显著提升精度分布。这个技巧RTR4成书时还没那么流行，但值得知道。
6.3 投影变换在管线里的位置
完整的顶点变换链是：局部空间 →（模型矩阵）→ 世界空间 →（视图矩阵）→ 视图空间 →（投影矩阵）→ 裁剪空间 →（透视除法）→ NDC →（视口变换）→ 屏幕空间。
这个链条里，模型、视图、投影三个矩阵经常被预先乘成一个MVP矩阵，一次乘到顶点上，省两次矩阵乘法。但要注意：法线不能用MVP变换，原因前面说过。另外，如果要在视图空间做光照，就得保留视图矩阵单独作用，不能全压成MVP。
我在实际项目里会准备两套：一套MVP给顶点位置用，一套模型矩阵（或它的逆转置）给法线用。这样既高效又正确。
7. 读这一章时我踩过的坑和总结出的方法
7.1 符号约定不统一导致的“玄学bug”
前面提过行向量和列向量的坑，这里再展开说一个更隐蔽的：RTR4书里的公式和某些引擎的实际实现可能不一致。书里为了通用性，有时会用行向量约定，有时用列向量，读者如果不注意就会对不上。我的做法是：读的时候拿一张纸，把书里的矩阵按自己项目的约定重新写一遍，确认每个公式的转置关系。这个“翻译”过程虽然费时，但能避免大量后期调试。
7.2 不要跳过推导，但也不要死磕推导
第四章有不少推导，比如四元数转矩阵、法线变换的逆转置证明。我的建议是：第一遍读结论和用途，第二遍再补推导。因为很多推导在你没实际用过之前是“空转”的，等你在代码里遇到具体问题再回头看，理解会快得多。比如法线变换的逆转置，我第一遍看推导没感觉，直到有一次非均匀缩放导致光照出错，回头再看那段推导，一下就通了。
7.3 把每个变换都写成可运行的小例子
纯看公式很容易“以为自己懂了”。我的方法是：每学一个变换，就用代码写一个最小例子验证。比如学四元数slerp，就写一个让物体在两个朝向间平滑转动的demo；学投影矩阵，就写一个把已知点投影到屏幕、再反投影回世界的验证。这种“可运行的理解”比看十遍公式都管用。RTR4是理论书，但它的知识必须落到代码里才算真正掌握。
7.4 建立自己的“变换速查表”
第四章信息密度大，我最后整理了一张自己的速查表，贴在工位上。内容包括：各种变换的矩阵形式、复合顺序的记忆法、法线变换规则、四元数常用操作、投影矩阵参数含义。这张表后来成了我排查变换问题的第一参考。建议每个读这章的人都整理一份，形式不限，关键是用自己的话写，而不是抄书。
8. 这些变换知识在实际项目里怎么落地
8.1 引擎里的变换层级管理
任何稍微像样的引擎都有一套变换层级（transform hierarchy）。每个节点存局部变换（通常是T、R、S分开存，R用四元数），世界变换由父节点递归乘出来。这样设计的好处是：改一个父节点的变换，所有子节点自动跟着动，而且局部变换的存储和插值都很方便。
实现时要注意两点。一是脏标记（dirty flag）：只有变换变了才重算世界矩阵，否则每帧全量重算很浪费。二是矩阵缓存：世界矩阵算一次存起来，给渲染和物理共用，避免重复计算。这两点在RTR4里没细讲，但属于工程必备。
8.2 动画与插值中的变换选择
做动画时，旋转插值几乎一定用四元数slerp，位置插值用线性或样条，缩放插值用线性。如果动画数据是矩阵形式，导入时就要分解成T、R、S分别存，运行时再复合。这个流程现在基本是行业标准。
有个细节：slerp在角度很小时可以退化成nlerp（归一化线性插值），因为两者结果几乎一样但nlerp更快。很多引擎会在点积接近1时走nlerp分支。这个优化RTR4里提过，实际用起来确实能省一点。
8.3 调试变换问题的通用思路
最后分享一套我排查变换问题的流程，几乎每次都能定位到原因：
- 确认约定：先确认当前代码用的是行向量还是列向量，矩阵是左乘还是右乘。
- 打印矩阵：把可疑的矩阵打印出来，看平移量在不在预期位置，缩放是不是(1,1,1)。
- 单步验证：用几个已知点（比如原点、单位向量）过一遍变换，看结果对不对。
- 隔离变量：把复合矩阵拆开，逐个应用，看是哪一步开始出错。
- 检查法线：如果问题只出现在光照上，优先怀疑法线变换。
这套流程看起来笨，但比盲目改代码高效得多。变换问题的特点是“一个符号错，结果全错”，所以系统化排查比试错靠谱。
读RTR4第四章，最大的收获不是记住了一堆公式，而是建立了一套“变换思维”：看到任何位置、朝向、投影相关的问题，都能顺着变换链一路追下去，找到出问题的那一环。这种思维方式，比任何单个知识点都值钱。
