每年到了校招季，图形渲染算法岗的笔试题总会引发不少讨论。做渲染方向的同学应该对“酷家乐”这个名字不陌生——家装设计领域的云设计工具，核心能力是让设计师在浏览器里实时预览和渲染高质量效果图。这就要求它的内核团队对渲染引擎、几何算法、GPU 优化这一套吃得非常透。今天想借这份“2020校园招聘-图形渲染算法（EGS）B卷”，把图形渲染算法校招笔试里最常出现的考点、底层原理和实战技巧从头到尾捋一遍。
这是一篇面向准备图形学/渲染算法方向校招、或者刚入门想搞明白渲染核心知识体系的同学的内容。我会结合这份 B 卷的题型方向，拆解每一类题背后的考察意图，补全关键推导过程，同时分享一些在真实渲染引擎开发中才会踩到的细节问题。文章信息密度比较大，建议收藏后配合手写推导慢慢看。如果你已经对 OpenGL/DirectX 管线有基本了解，读起来会顺畅很多；如果还没接触过渲染管线，我也会用通俗的类比帮你建立起整体认知。
1. 从岗位视角看这份卷子的考察逻辑
1.1 EGS 团队到底在解决什么问题
要理解一份笔试卷为什么这样出，先得理解这个团队在做什么。EGS 这个名字在渲染领域一般指引擎图形系统（Engine Graphics System），放在酷家乐的场景里，就是支撑云设计平台的那套渲染核心。
家装云设计软件和游戏渲染有个本质区别：游戏要的是“每秒 60 帧的实时感”，而酷家乐要的是“普通家用电脑浏览器里也能跑得动的室内场景实时渲染”。这意味着它的渲染引擎必须同时做好三件事：高效的场景组织、低延迟的光栅化管线、以及在不牺牲画质的前提下尽可能节省显存和带宽。更麻烦的是，一个户型场景里包含几十万个家具模型，这些模型的来源是不同设计师上传的极不规范的三维数据——网格有洞、法线翻转、模型重叠、比例失调，什么情况都有。
这套业务背景直接决定了笔试的出题方向。你不会看到纯理论的光线追踪推导，也不会看到过于偏门的分形渲染。试卷更倾向于考察：空间变换是否扎实、几何求交是否熟练、光栅化流程是否清晰、加速结构是否理解本质、对着色模型是否有直觉。这些都是真实工作中每天都在用的基本功。
1.2 B 卷题型的合理推测与整体应对思路
虽然我手里没有 2020 年那份 B 卷的原始题目，但从图形渲染算法岗历年的出题风格和这份卷子的定位来看，题型结构基本可以归纳为四类：数学基础题、几何求交题、渲染管线题、性能优化题。
数学基础题主要考向量运算、矩阵变换、坐标系转换，偶尔穿插一点数值计算；几何求交题集中在光线与三角形、球、AABB（轴对齐包围盒）的求交推导；渲染管线题涵盖 MVP 变换、光栅化流程、深度缓冲、着色模型；性能优化题则偏向加速结构、批量绘制、LOD 这些工程手段。
应对这批题目，一个核心原则是“不要只记结论，要会推导”。笔试现场没有搜索引擎，更不能查资料，所有的公式都得靠在脑子里现场推演。比如 Möller–Trumbore 光线三角形求交公式，如果你只是背下了最终代码却不知道怎么来的，换个参数形式就很容易写出 bug。我后面会带着大家从零推一遍，确保你们真的理解。
2. 数学基础与空间计算的必拿分点
2.1 线性代数三大高频考点：点乘、叉乘、矩阵变换
渲染算法里几乎所有的计算都建立在线性代数之上。笔试中数学题不会考你“什么是向量点积”这种概念题，而是会把它揉到实际场景里，让你算“已知光源方向和平面法线，求该平面上的光照强度”，或者“给定两个向量，判断它们之间是锐角还是钝角”。
点积的几何意义要形成肌肉记忆：a · b = |a||b|cosθ。它最常见的三个用途是：判断方向一致性（cos 正负）、投影长度计算、以及光照模型中的衰减因子。叉乘的几何意义同样重要：a × b的结果是一个同时垂直于 a 和 b 的向量，模长等于 a、b 构成的平行四边形面积。在渲染中叉乘主要用于求法线方向和构造正交基。注意叉乘不满足交换律，a × b和b × a方向正好相反，这个错误在求法线时特别容易犯——法线方向反了，光照就全错了。
矩阵变换的核心是理解齐次坐标。为什么三维坐标要写成四维向量？因为这样可以统一表示平移和旋转缩放：一个 4x4 矩阵既能旋转缩放又能平移，而 3x3 矩阵做不到平移。齐次坐标的w分量表示缩放因子，当w=1时就是普通空间点，w=0时可以理解为“方向向量”。
这里有一个笔试中反复出现的经典陷阱：法线方向向量的变换不能用模型矩阵直接做。如果模型矩阵包含非均匀缩放，直接乘会导致法线不再垂直于表面。正确做法是使用模型矩阵的逆转置矩阵(M^{-1})^T。原理是：切线 t 经过 M 变换后仍然是表面切线，而法线 n 需要满足变换后仍与切线垂直，即(M t) · (M^{-T} n) = 0，所以法线要用逆转置矩阵来变换。这个考点几乎每年都会出现，一定要吃透。
2.2 典型计算题演练：从向量投影到透视投影矩阵推导
笔试中大概率会有一道“求向量 a 到向量 b 上的投影”的计算题。投影公式是proj_b(a) = (a·b / |b|²) * b。这个看起来简单，但面试官往往会在后面加一个小问：如何把投影分解为平行分量和垂直分量？拆解思路是：平行分量为上面求的 proj，垂直分量为a - proj。这两个分量在后续推导反射向量、构建正交基时都要用到，属于必须滚瓜烂熟的内容。
透视投影矩阵的推导也值得手动推一遍。正交投影相对简单，直接线性映射即可；透视投影的关键是让远处的物体看起来更小，本质是把视锥体变换为一个立方体。推导思路分三步：先通过相似三角形得到x' = x * (near / -z)；然后引入齐次坐标，把除以 -z 的操作交给 w 分量；最后计算矩阵系数。
一个常见笔试问题是：为什么透视除法要在裁剪之后做？答案是裁剪需要比较顶点在裁剪空间中的坐标是否在[-w, w]范围内，如果先除以 w，就失去了线性的深度关系，插值也不正确。这个问题直接关系到管线流水线的理解深度。
3. 光线求交：渲染算法的核心题
3.1 光线与三角形求交的 Möller–Trumbore 解法
图形渲染算法笔试里，光线与三角形求交是出现频率最高的一道题，因为三角形是网格渲染的基本图元。最经典的算法是 Möller–Trumbore（下称 MT 算法），它能直接解出重心坐标，且不需要预先计算平面方程。
MT 算法的核心思路：把光线方程O + tD和三角形重心坐标表示(1-u-v)V0 + uV1 + vV2建立等式，把 u、v、t 三个未知数集中到一个 3x3 线性方程组里。利用克莱姆法则化简后，代码实现非常紧凑。我在实际工程中大量使用这个算法，性能非常稳定。
关键代码实现（右手坐标系、逆时针朝向为正面）：
bool rayTriangleIntersect( const glm::vec3& orig, const glm::vec3& dir, const glm::vec3& v0, const glm::vec3& v1, const glm::vec3& v2, float& t, float& u, float& v) { glm::vec3 e1 = v1 - v0; glm::vec3 e2 = v2 - v0; glm::vec3 pvec = glm::cross(dir, e2); float det = glm::dot(e1, pvec); // 当 det 接近 0 时，光线与三角形共面或平行，判为不相交 if (fabs(det) < 1e-8f) return false; float invDet = 1.0f / det; glm::vec3 tvec = orig - v0; u = glm::dot(tvec, pvec) * invDet; if (u < 0.0f || u > 1.0f) return false; glm::vec3 qvec = glm::cross(tvec, e1); v = glm::dot(dir, qvec) * invDet; if (v < 0.0f || u + v > 1.0f) return false; t = glm::dot(e2, qvec) * invDet; return true; }这里有个笔试高频追问：det的含义是什么？det的本质是 e1、e2、dir 三个向量构成的平行六面体体积。如果它接近 0，说明三条向量几乎共面，光线和三角形平行，此时不可能相交。用手掌做类比：手掌平放，光线从侧面平行扫过，永远不会穿入掌心，就是这个道理。
3.2 光线与 AABB 求交的 SLAB 法
AABB（轴对齐包围盒）求交在加速结构里无处不在，BVH 遍历时每个节点都要做一次。笔试中常考的是 SLAB 法（也叫平移平面法）。
SLAB 法的思想非常直观：把 AABB 看作三组平行平面（x 平面的两个面、y 平面的两个面、z 平面的两个面）的交集。光线进入包围盒的时间，等于光线在三组平面中“最晚进入”的那个时间；光线离开包围盒的时间，等于“最早离开”的那个时间。如果进入时间小于离开时间，并且离开时间大于 0，就说明光线穿过包围盒。
实现要点：
bool rayAABBIntersect(const glm::vec3& orig, const glm::vec3& invDir, const glm::vec3& bboxMin, const glm::vec3& bboxMax) { float tmin = 0.0f, tmax = FLT_MAX; for (int axis = 0; axis < 3; ++axis) { float t1 = (bboxMin[axis] - orig[axis]) * invDir[axis]; float t2 = (bboxMax[axis] - orig[axis]) * invDir[axis]; if (t1 > t2) std::swap(t1, t2); tmin = std::max(tmin, t1); tmax = std::min(tmax, t2); if (tmin > tmax) return false; } return true; }这里传入的是invDir，即光线方向分量的倒数。之所以预计算倒数，是因为浮点除法比乘法慢得多，而加速结构遍历中的 AABB 求交次数极多，预计算倒数能省下大量运算。这种细节也经常作为加分项在笔试现场提问。
3.3 实操心得：坐标系、精度与代码细节
关于光线求交题，除了算法本身，还有几个细节是阅卷时容易给分的点。
第一，注意坐标系的一致性。你推公式时默认光线方向是归一化的，但实际代码里光线的 direction 不一定归一化。在 MT 算法中，若方向未归一化，求出的 t 就不是真实的距离，而是“以方向向量的长度为单位”的距离。因此，必须在求交前统一约定：要么保证方向归一化，要么明确 t 的含义。
第二，浮点精度问题。在判断det是否为 0 时，不能直接写if (det == 0)，而要用阈值判断。工程上常用if (fabs(det) < 1e-8f)或者更高精度场景下用1e-12f。阈值太大容易漏掉小三角形，太小又无法过滤共面情况。需要根据场景尺度调节，这是一个典型的数值稳定性问题。
第三，t 值的范围判断。射线求交时通常要限制 t 的最小值和最大值。最小值可以避免从物体内部出发时误交自身，最大值用于渲染中的遮挡范围限制。很多新手只判断t > 0，但实际场景中需要t > t_min，这个细节在阴影渲染和反射渲染时尤为重要。
4. 光栅化与管线：从数学到像素
4.1 MVP 矩阵变换的逻辑拆解
光栅化渲染的核心是把三维场景变成屏幕上的二维像素。这个过程中最绕但最关键的环节就是 MVP 变换：模型矩阵（Model）、视图矩阵（View）、投影矩阵（Projection）。
模型矩阵负责把物体从局部坐标系变换到世界坐标系。模型有自己的尺寸、位置、旋转和缩放，模型矩阵就是把它的所有顶点都摆到世界对应的位置。视图矩阵负责把世界坐标系变换到摄像机坐标系——本质上是把摄像机移回原点，并把它的朝向对准 -z 方向。投影矩阵则负责把摄像机坐标系下的视锥体变换到裁剪空间。
很多初学者容易混淆视图矩阵和投影矩阵。我习惯用一个类比：模型矩阵是“把演员搬到舞台上”，视图矩阵是“选一个机位架好摄像机”，投影矩阵是“调整镜头焦距和成像平面”。三者是串联关系，顺序不能换：finalPosition = P * V * M * localPosition。
笔试中常考的一个点：顶点着色器输出的坐标是裁剪坐标，片段着色器输入的坐标是窗口坐标，中间的透视除法谁来做？答案是由硬件在光栅化阶段自动完成。顶点着色器只需输出裁剪坐标，硬件会拿 xyz 除以 w，得到 NDC 坐标，再通过视口变换映射到屏幕坐标。
4.2 视口变换与深度缓冲的考察重点
视口变换的意义在于把 NDC 坐标映射到实际的像素坐标。假设视口宽为 width、高为 height，那么屏幕坐标的计算公式为：
screen_x = (ndc_x + 1) * 0.5 * width screen_y = (1 - ndc_y) * 0.5 * height注意 y 轴要翻转，因为渲染窗口的原点通常在左上角，而 NDC 的 y 轴向上。这个细节点很多人会忘，一旦出错，整个画面上下颠倒。
深度缓冲是光栅化中的经典概念。每个像素存储当前绘制片元的深度值，绘制新片元时对比深度，深度小的覆盖深度大的，从而实现遮挡关系。笔试经常问：为什么深度缓冲通常用非线性分布？
原因是近处的深度需要更高的精度。透视投影下，深度缓冲精度被分配到近裁剪面附近更密集，远裁剪面附近更稀疏。这就是为什么近处物体遮挡关系准确，远处物体容易出现深度冲突（z-fighting）。理解这一点对排查渲染瑕疵很有帮助。
关于深度冲突有一个实用建议：在需要绘制大尺度场景时，把近裁剪面尽量调大到能接受的最小值，而不是设成 0.001 这种极小的值。近裁剪面太小会严重浪费深度精度，导致几万米外的物体出现边缘闪烁。实际项目里我经常用“logarithmic depth buffer”或把远裁剪面限制到实际需要的最小值，效果立竿见影。
4.3 着色模型考点：Phong 与 Blinn-Phong 的区别
着色模型是渲染算法笔试的必考内容。最经典的考题是：简述 Phong 光照模型与 Blinn-Phong 模型的区别。
Phong 模型的高光项计算方法是：先计算光线 L 关于法线 N 的反射向量 R，再计算 R 与视线方向 V 的点积，用高光指数幂来控制光斑大小。公式为spec = pow(max(dot(R, V), 0), shininess)。
Blinn-Phong 模型的改进在于不再计算反射向量，而是引入半程向量H = normalize(L + V)，再用法线 N 与 H 的点积代替 R 与 V 的点积。这个替换的几何意义是：当 N 和 H 方向一致时，微表面反射方向正好指向视线，高光最强。
两种模型的实际表现差异是：Blinn-Phong 的高光区域更柔和，且计算更高效（少一次反射向量计算）。游戏引擎中 Blinn-Phong 更常用，但 Phong 模型在特定材质表现上也有价值。笔试如果要求推导或画图，建议把入射光线、法线、反射光线、视线和半程向量的相对位置画清楚，这比文字更有说服力。
5. 加速结构与性能优化题
5.1 BVH 与 KD-Tree：怎么选、为什么这么选
渲染性能优化题里，BVH（包围体层次结构）和 KD-Tree（K 维树）是两大必考内容，也是光追和小型场景实时渲染中最重要的加速结构。
BVH 的思路是：按照几何对象在空间中的分布，递归地把对象分组，每个节点存储包裹其子节点的包围盒。它的特点是分割的是“对象集合”，叶子节点包含的是图元列表。KD-Tree 的思路则不同：它按空间位置递归切割，分割的是“空间区域”，叶子节点是被切分后的空间子区域中与该区域相交的图元。
笔试常问：为什么现代的渲染引擎更偏向 BVH 而不是 KD-Tree？原因有三个：第一，BVH 的树结构自适应性更强，每个包围盒可以贴合对象形状，而 KD-Tree 的切割轴是固定的轴对齐平面，遇到倾斜细长物体会产生大量无效切分；第二，BVH 构建时不需要存储分裂平面的额外信息，内存占用更小；第三，BVH 对动态场景更友好，物体移动时只需要更新对应节点的包围盒，而 KD-Tree 需要重建空间切分。
我把两者打过一个比方：BVH 的包围盒像快递分拣中心划分片区，每个片区的包裹不跨越片区；KD-Tree 像一块豆腐，用刀不断竖切横切，切出来的每一块都要求恰好跟豆腐里面的物体对齐——物体动了，刀法就得重来。
5.2 从笔试到工程：面片减面、LOD 和 GPU 实例化
笔试的性能优化题往往不满足于“我会用 BVH”这个回答，而是会追问：如果场景中有数十万甚至上百万个三角面片，你的渲染策略是什么？
这时候需要展示你对工程性能优化的全局认知。常用的技巧有三个：面片减面、LOD（多级细节层次）、GPU 实例化。
面片减面是指通过网格简化算法减少模型中的三角面片数量，同时尽量保持视觉特征。经典算法是 QEM（Quadric Error Metrics，二次误差度量），它通过迭代折叠边来减少面数。LOD 则是在运行时根据物体到摄像机的距离自动切换不同精度的网格模型。距离远时用低精度模型，距离近时用高精度模型。
GPU 实例化是处理大量重复物体的关键技巧。一个室内场景里可能有一百把完全相同的椅子，如果逐把提交绘制指令，驱动和 CPU 都会被压垮。实例化技术让 GPU 只加载一份模型数据，但通过一个实例化缓冲区传入每把椅子的变换矩阵，然后一次绘制调用画完所有椅子。这个技巧的核心瓶颈从“顶点数量”转移到了“实例数据的传输”。
一个更进阶的技术是 GPU-Driven Rendering，把剔除逻辑也放到 GPU 上做，CPU 只负责上传场景数据。这已经是现代商业引擎的标配思路。笔试中提到这个层面，能明显拉开与普通候选人的差距。
6. 常见问题与考场技巧实录
6.1 时间分配与答题顺序
图形渲染算法校招卷的题量通常不小，题面又包含大量推导，时间非常紧张。我能给的最重要建议是：先挑有把握的题做，不要死磕一道推导。
我的个人习惯是拿到卷子先花三分钟把所有题目扫一遍，在题号旁边标注难度星级。一星的题（如向量点乘计算）直接做，二星的题（如 MVP 矩阵概念）控制在十分钟内，三星的题（如完整推导 MT 算法）放到最后攻坚。这样保证基础分拿满，再有余力冲刺难题。
另外，推导题千万别只写答案。阅卷老师看重的是你对推导过程的掌控力，一步一步写清楚每一步的变换依据，即使结果错了也能拿大部分步骤分。反而只写结果不给过程，一旦结果算错就是零分。
6.2 高频易错点速查表
我整理了这些年做渲染方向校招辅导和实际项目评审中反复出现的易错点，做成速查表，笔试前过一遍非常有价值。
| 易错点 | 错误认知 | 正确理解 |
|---|---|---|
| 法线变换 | 直接用模型矩阵变换法线 | 使用模型矩阵的逆转置矩阵 |
| 透视除法时机 | 在顶点着色器内手动做除法 | 顶点着色器输出裁剪坐标，光栅化阶段做除法 |
| 叉乘顺序 | a×b与b×a结果相同 | 方向相反，需要根据坐标系和顶点环绕方向统一 |
| 深度缓冲精度 | 远裁剪面设置越大越好 | 过大的远裁剪面会严重浪费深度精度，按场景实际需要设置 |
| Blinn-Phong 的高光 | 高光方向是反射向量 R | 半程向量 H = normalize(L+V) |
| AABB 求交 | 只看 t_max 是否大于 0 | 需要同时检查 t_min、t_max 的范围 |
| 齐次坐标 w | 所有顶点 w 都等于 1 | 透视投影后 w 不等于 1，需要参与后续插值计算 |
这张表里的每一项背后都是我踩过的坑。特别是法线变换那一条，我曾经在做一个非均匀缩放的家具模型时，整面墙的光照全反了，排查了一整个下午，最后发现就是法线直接乘了模型矩阵。
6.3 给非科班同学的一些备考建议
如果你是非科班出身，看到这份卷子可能会觉得心里没底。我想说的是，图形渲染算法的校招考核点相对固定，性价比最高的备考路径就是“搞懂三大块”：数学基础、几何求交、渲染管线。
第一步，把线性代数教材里的向量、矩阵、线性变换部分吃透，尤其要能把抽象矩阵和几何意义对应起来。第二步，自己手写一个简单的 CPU 光线追踪器，渲染一个球体和一个三角形，这个过程能把求交、着色、坐标变换全部过一遍。第三步，学习一个现代图形 API（如 WebGPU 或 Vulkan）的基础入门，跑通一个三角形渲染的示例，把 MVP 变换和光栅化流水线真正落实到代码里。
我见过太多同学把时间花在刷大厂算法题上，结果笔试时基本的向量叉乘都算错。图形渲染算法的核心竞争力永远在于对几何和光照本质的理解，这才是这类岗位笔试真正的考察目标。
最后再分享一个实用的刷题技巧：笔试前把常用的三维数学库源码（比如 glm）翻一遍，重点看lookAt矩阵、透视投影矩阵、normalize函数内部的实现。因为这些代码本质上是图形学通用知识的“标准答案”，看懂了它们，你对矩阵构造、归一化、精度处理这些细节的掌握就会上一个台阶。我当年就是靠这个方法，在笔试的矩阵推导题上省了大量时间。
