1. 相机变换到底在解决什么问题
1.1 相机不是“眼睛”，而是一堆矩阵
不少刚接触引擎开发的朋友，一开始都会把相机想象成“放进三维世界里的一只眼睛”。这个直觉没错，但实现上它既不真的去看，也不会像人眼那样自动对焦。在一个自研引擎里，相机最终落地下来的东西，本质上就是几个矩阵，外加一堆用来还原“眼睛姿态”的辅助参数。
我最早在做一个简易渲染器的时候，对相机处理的认知也停留在这个层面：反正就是摆个位置、朝个方向、用透视投影把顶点压扁到屏幕上。可真到动手的时候才发现，光是一个 View 矩阵，就把我在“左手系 vs 右手系”“行主序 vs 列主序”“向量左乘还是右乘”这三个坑里埋了一整天。
所以这篇我不打算只给一个能跑的结果。我要拆开讲清楚：相机变换到底在变换什么、LookAt 矩阵是怎么一步步推出来的、透视投影里的 FOV 和近远裁剪面为什么那么配、以及我在实际写入引擎时踩过的那些只有跑了才知道的坑。适合刚写完模型变换、正准备做渲染管线的朋友看，也适合那些想让自己的小引擎更像“引擎”而不是demo的人参考。
这里需要先统一一个前提：后面所有推导和代码，默认采用右手坐标系、列向量、矩阵按列主序存储，坐标变换顺序是“先缩放，再旋转，再平移”，相机看向 -Z 方向。这套约定和大多数图形学教材一致，也让你往 Vulkan、OpenGL 或者自己的软件渲染器里迁移时少一层心智负担。
1.2 五个坐标空间：从模型顶点到屏幕像素的总路线
一个顶点从模型文件里读出来，到最终出现在屏幕上，中间要经历五个坐标空间：模型空间、世界空间、视图空间（也叫相机空间）、裁剪空间（齐次裁剪空间）、以及 NDC（归一化设备坐标）和屏幕空间。
这五段路里，相机变换真正直接负责的是中间两段：把世界空间里的顶点挪进视图空间，再把视图空间里的顶点通过透视投影压到裁剪空间。后面从裁剪空间到 NDC 到屏幕像素，通常算作渲染管线的固定环节，但如果你在做软件渲染器，这部分也得自己处理。
为什么非要用这么多坐标空间？直接用世界坐标画不行吗？不行。因为你根本没有“画”这个操作，光栅化器只认识一个固定范围内的坐标，超出边界的顶点要裁剪，裁剪之后才能确定哪些像素被覆盖。裁剪空间就是为这个“统一处理”而生的。View 矩阵负责把相机变成新的坐标系原点，Projection 矩阵则把可视范围变成一个盒子，方便做裁剪。二者合起来，才是完整的“相机”。
我自己的体会是，理解相机变换最好的方式就是手算一次，不要只调库。哪怕你最后用的是 glm::lookAt 和 glm::perspective，也建议先亲手把矩阵推一遍，否则遇到画面翻转、远近裁剪面瞎切模型这种问题，你连该怀疑谁都不知道。
2. 关键变换参数与推导过程
2.1 视图矩阵 LookAt：从相机位姿到坐标变换矩阵
视图矩阵的核心任务只有一个：把世界坐标系的顶点，换到以相机为原点的坐标系里。这个变换等价于“让相机回到原点，并让它的三个基向量对齐世界坐标轴”。
设相机的三个正交基向量为右向量 R、上向量 U、前向量 F（注意这里我用的是相机自身的局部坐标），相机位置为 Eye。那么从世界到视图的矩阵可以拆成两步：先平移（把相机搬到原点），再旋转（把相机坐标系旋转到与世界坐标对齐）。
旋转矩阵的构造方式，是用相机基向量作为矩阵的行：
View = [ Rx Ry Rz 0 ] [ Ux Uy Uz 0 ] [ Fx Fy Fz 0 ] [ 0 0 0 1 ]但这里有个关键细节：这个矩阵的第三行填入的前向量 F，必须是指向相机“后方”的向量，也就是我们常说的 -Z 方向。因为在右手坐标系里，相机默认看向 -Z，所以 LookAt 矩阵里存的“前进方向”其实是目标位置减相机位置后取反。这个负号搞反，你拍出来的画面就会是镜像的，但你还看不出来哪里错了。
平移部分更简单：把相机位置取负，再点乘旋转矩阵的三行，得到最终的视图矩阵：
View = [ Rx Ry Rz -dot(R, Eye) ] [ Ux Uy Uz -dot(U, Eye) ] [ Fx Fy Fz -dot(F, Eye) ] [ 0 0 0 1 ]这里我建议你把 dot(R, Eye) 算成一个标量，不要直接在代码里拼矩阵，否则很容易搞成 -R * Eye 的逐元素乘，在矩阵运算下完全错误。
那么三个基向量怎么求？最通用的做法就是从 LookAt 参数里算：
- 先求前向向量：forward = normalize(target - eye)，这是相机真正看的方向。
- 再给定一个参考上方向 worldUp（通常取 (0,1,0)），求右向量：right = normalize(cross(forward, worldUp))。
- 最后求真正的上向量：up = cross(right, forward)。
注意右向量这里必须是 cross(forward, worldUp)，而不是 cross(worldUp, forward)。两个顺序结果刚好相反，选错了画面直接左右翻转，排查起来非常头疼。
2.2 透视投影矩阵：FOV、近远裁剪面到底怎么配
视图矩阵把顶点搬到了相机原点，接下来透视投影要把“视锥体”映射成一个长方体，也就是从视图空间进入裁剪空间。这个变换的核心是让“越远的东西看起来越小”这件事变得可计算。
透视投影矩阵的标准形式，在右手坐标系里长这样：
P = [ f/aspect 0 0 0 ] [ 0 f 0 0 ] [ 0 0 (zFar+zNear)/(zNear-zFar) (2*zNear*zFar)/(zNear-zFar) ] [ 0 0 -1 0 ]其中 f = 1 / tan(fov/2)，fov 是垂直视场角，aspect 是宽高比。
我第一次看这个矩阵的时候，第一反应是：为什么矩阵第三行那么奇怪，而第四行偏偏是 (0,0,-1,0)？这个 -1 是从哪来的？
关键就在于透视除法。矩阵第四行的作用是把顶点 w 分量从 1 变成 -z，这样在光栅化之前做透视除法时，x/w、y/w、z/w 就能真正体现“远处缩放”的效果。你可以这么理解：视图空间里顶点距离相机越远（z 的绝对值越大），除法后 x/w 越小，画面里就越靠近屏幕中心，也就是“透视缩小”的数学表达。
近裁剪面 zNear 和远裁剪面 zFar 的选择，我踩过的坑比 FOV 还多。这两个值差得太大，会直接导致深度缓冲的精度在远处不够用。比如 zNear=0.1、zFar=1000，在浮点深度缓冲下，近处精度看起来很高，但离相机 700 米以后，你会发现相邻两个深度值代表好几十米的距离差，物体互相“叠”在一起闪烁。
所以我的建议是：不要把 zFar 调得比实际场景需求大太多，近处尤其不要轻易用 0.001 之类的极限值。zNear 和 zFar 的比值控制在 1000 倍以内比较稳妥；如果你想做超大地图，再考虑带对数深度的方案，而不是硬拉远裁剪面。
2.3 视口映射：从 NDC 到屏幕像素的最后一公里
顶点经过 View 和 Projection 之后，齐次坐标除以 w，就进入 NDC。在右手系 OpenGL 风格管线下，NDC 的 x、y、z 范围都是 [-1, 1]。但最终屏幕的像素坐标是 x 在 [0, width]、y 在 [0, height]，这就需要一个视口变换。
屏幕坐标的计算公式：
screenX = (ndc.x * 0.5 + 0.5) * width screenY = (ndc.y * 0.5 + 0.5) * height这里有一个很容易被忽略的细节：大多数窗口系统的 y 轴是向下增长的，而 NDC 的 y 轴向上。如果你直接把 NDC 的 y 套进去，画面会上下颠倒。处理方式要么在视口变换时把 y 翻转：screenY = (1 - (ndc.y * 0.5 + 0.5)) * height，要么在 Projection 矩阵上做一次 y 轴镜像。
我做第一版软件渲染器的时候，画出来的模型脑袋朝下，整整找了一个晚上，最后发现不是模型数据的问题，而是窗口坐标 y 方向没翻转。这种事说穿了不值钱，但没遇到过真的会卡住你很久。
视口变换里还有一个细节：width 和 height 应该用实际渲染目标的分辨率，而不是窗口客户区尺寸，再乘上你需要的渲染缩放系数。做分辨率缩放渲染时，这一步是单独的 scale 参数，别写死在矩阵里。
3. 相机类的完整实现与实操
3.1 设计相机数据结构和接口
一个相机类该存什么？我的做法是尽量少存冗余量。你可以选择存 eye、target、up 三个向量，也可以存 eye、yaw、pitch 两个欧拉角。前者适合做围绕目标旋转的观察相机，后者适合做 FPS 式控制。最灵活的做法是把两种模式封装到同一个类里，但内部只保存一套基础状态：位置、俯仰角、偏航角。
我自己更偏好欧拉角方案，因为游戏开发里大多数相机交互都建立在“水平旋转 + 上下俯仰”上。目标点反而是派生量，随时可以由位置和两个角度算出来。
看一个精简的相机定义：
class Camera { public: glm::vec3 position = glm::vec3(0.0f, 0.0f, 3.0f); float yaw = -90.0f; // 偏航角 float pitch = 0.0f; // 俯仰角 float fov = 60.0f; float aspect = 16.0f / 9.0f; float zNear = 0.1f; float zFar = 200.0f; public: glm::mat4 getViewMatrix() const { glm::vec3 front; front.x = cos(glm::radians(yaw)) * cos(glm::radians(pitch)); front.y = sin(glm::radians(pitch)); front.z = sin(glm::radians(yaw)) * cos(glm::radians(pitch)); front = glm::normalize(front); return glm::lookAt(position, position + front, glm::vec3(0.0f, 1.0f, 0.0f)); } glm::mat4 getProjectionMatrix() const { return glm::perspective(glm::radians(fov), aspect, zNear, zFar); } };这里 yaw 初始值为什么是 -90 度？因为默认方向是 -Z 轴，而公式里的 cos/sin 在 yaw=0 时会指向 +X。这个细节不处理，相机一开始就歪着。
我不建议在相机类里直接调用 glm::lookAt 去绕开理解，但用这个库函数确实能帮你快速搭出原型。真正要深入时，把上一节手动推导的矩阵用代码实现一遍，替换掉库调用，你会对内部机制更有掌控感。
3.2 LookAt 模式下绕目标旋转
如果你做的是模型查看器，相机需要围着目标点旋转，这时最适合的参数不是位置增量，而是三个球面坐标：目标点 target、半径 radius、水平角 phi、俯仰角 theta。
相机位置可以由球面坐标换算：
eye.x = target.x + radius * cos(theta) * sin(phi) eye.y = target.y + radius * sin(theta) eye.z = target.z + radius * cos(theta) * cos(phi)然后直接用这个 eye 和 target 做 lookAt。鼠标拖动时，把屏幕像素差映射成 phi 和 theta 的增减量，滚轮则改变 radius。
这个方案的优点是你永远不会“飘”：相机无论如何旋转，都稳定地指向目标中心。缺点也很明显：一旦目标点移动，相机得跟着改，如果你需要相机追逐移动物体，这个模式就得小心做平滑。
我在这里踩过一个具体的坑：theta 不能无限增加。当俯仰角接近 90 度或 -90 度时，cos(theta) 趋向 0，相机几乎落在目标的正上方或正下方，这时水平旋转稍微动一点，相机位置会在顶部附近剧烈跳动。限制 theta 在 (-89度, 89度) 区间内，是最简单的解法。
3.3 第一人称模式：偏航角与俯仰角
FPS 相机和 LookAt 相机的区别在于，它控制的是“自身朝向”，而不是“围绕目标旋转”。鼠标移动改变 yaw 和 pitch，WASD 则沿着相机自身的前向和右向平移。
前向向量在上文 getViewMatrix 里已经算过。右向量可以这样求：
right = glm::normalize(glm::cross(front, worldUp));需要注意，front 和 worldUp 几乎平行时（比如抬头到 90 度），right 会退化成一个接近零向量的东西，WASD 移动会瞬间变得敏感或漂移。所以 FPS 相机同样要限幅 pitch。
平移的实现也别直接改 position.x/y/z 三个分量，而是用前向和右向量合成，否则你按 W 走向的方向会和眼睛看到的方向不一致。
float speed = 2.5f * deltaTime; if (Input::getKey(Input::KEY_W)) position += front * speed; if (Input::getKey(Input::KEY_S)) position -= front * speed; if (Input::getKey(Input::KEY_A)) position -= right * speed; if (Input::getKey(Input::KEY_D)) position += right * speed;为什么前向和右向要乘 deltaTime？因为每帧调用频率不固定。不乘 deltaTime 时，同样按一次 W，高刷新率屏幕下会走得快好几倍；乘上后速度就和帧率无关了。
3.4 宽高比与窗口 Resize 联动
aspect 参数是相机类里最容易“忘记更新”的变量。我见过不少项目的相机，fov 做了一大堆交互逻辑，窗口一改尺寸模型就压扁或拉长，问题基本都在 aspect 没同步。
窗口事件回调里要做的事很简单：
void onResize(int width, int height) { if (height == 0) height = 1; camera.aspect = static_cast<float>(width) / static_cast<float>(height); glViewport(0, 0, width, height); }height 为 0 的守卫判断不能省。某些窗口系统在最小化时会把宽度或高度变成 0，不处理就除零崩溃，这是我在实际项目里遇到过的场景，不是理论问题。
如果你是软件渲染器，没有 glViewport 这种自动接口，那你要做的是在帧缓冲遍历时按新的宽高重新分配像素缓冲，同时保证相机 aspect 同步更新。否则渲染图像的分辨率变了，透视画面却还按旧比例计算，上面说的压扁拉长问题就会重新出现。
4. 相机变换的调试与常见坑
4.1 相机颠倒、镜像、绕错轴
先讲一个我自己的教训。有一次我写了完整的 LookAt 矩阵，结果画面里的物体全都上下颠倒。我排查了很久，最后发现问题是上方向向量的叉乘顺序写反了，导致 up 向量指向下方。这类问题最可怕的地方在于它不报错，渲染仍然正常，只是画面是颠倒的。
我的排查方法很简单：先在原点放一个坐标轴指示器——三条不同颜色的线段，分别代表 X、Y、Z 轴。相机不动时，你应该能清楚区分三条轴的颜色位置。如果 R、G、B 三条线的方向和布局跟预期不一致，立刻就能看出哪个基向量算错了。
另外一个常见问题是“旋转方向反了”。你按 A 键相机往左转，但画面里世界在往右跑。这是 yaw 的增减方向定义问题。解决方法是把 yaw 的增减符号换一下，而不是去改矩阵，因为矩阵没错，是控制层的映射反了。
4.2 近裁剪面闪烁与纵深精度
近裁剪面闪烁是一个典型的“看得到但难以定位”的问题。物体离相机很近时，表面出现大量锯齿状闪烁，哪怕模型面数不高也一样。
原因通常是 zNear 设得太小。比如 zNear=0.01、zFar=5000，这种情况下深度缓冲的精度分布极其不均匀，近处占用了太多精度，远处的精度被压缩得几乎不可用。但奇怪的是，闪烁往往出现在“近处”，因为你贴着物体表面看，面片的深度差异已经小于浮点分辨率的间距。
我建议这样调整：先量出场景里“最近可能出现相机的位置”到“最近物体表面”的距离，把这个距离放宽 5 到 10 倍作为 zNear。比如你的人物角色半径是 1 米，相机不会贴到 0.5 米以内，那 zNear=0.5 就够，没必要硬上 0.001。
如果你做了大世界，zFar=5000 就几乎必然是精度瓶颈。可以考虑把 zFar 降到 800，或者干脆做一个水体、雾效来掩盖远距离裁剪，而不是真把远裁剪面拉到无限远。
4.3 万向锁与旋转插值问题
万向锁不是相机变换本身写错，而是欧拉角表示旋转时不可避免的问题。当俯仰角到达 90 度，偏航和翻滚的旋转轴重合，导致其中一个自由度丢失，旋转表现会变得非常诡异。
做第三人称相机时，这个现象尤其明显。相机绕着目标旋转，一旦俯仰角接近正上方或正下方，鼠标水平拖动时相机会突然跳变或卡顿，看起来就像“卡在一个套管里转不动了”。
为什么会这样？因为欧拉角本质上是三次固定顺序的旋转，在特定角度下，前后两次旋转会退化成绕同一个轴，丢失一个旋转维度。
我的选择：普通观察相机用限制俯仰角来绕开，核心玩法相机如果对旋转连续性和插值有强需求，就直接切换到四元数存储姿态。四元数没有万向锁问题，插值也能用 Slerp 做得很平滑。但要注意，四元数不直观，调试时你必须能通过打印角度来验证结果，否则出了问题更难查。
4.4 帧率、抖动与去抖方案
相机抖动和帧率的关系，折磨过每一个做引擎的人。如果你每帧都对相机的 position 和角度做增量更新，且增量没有乘 deltaTime，那么高帧率下相机运动速度就变快，低帧率下又变慢，视觉上表现为忽快忽慢的“颤振”。
还有一类抖动来自浮点精度。相机在离原点特别远的地方，比如一万个单位以外，矩阵运算里的浮点误差会被放大，顶点位置出现低频摆动。这个问题的常规解法是“相机居中”或“浮动原点”方案：渲染时用相机位置把整个世界做偏移，让相机的坐标保持在小数值区间。这个方法在大世界引擎里几乎是标配。
如果你只是做小场景，优先检查 deltaTime 是否真的应用到了相机移动上。其次，如果你用了平滑插值，比如 lerp 跟随目标，目标移动速度和插值系数要匹配帧率。一个常见的修正办法是：
float t = 1.0f - std::pow(1.0f - smoothness, deltaTime * 60.0f); position = lerp(position, targetPosition, t);这样无论帧率是多少，插值速度都保持一致。直接用固定 0.1 的 lerp 系数在 30 帧和 120 帧下的手感差距会非常大。
最后再分享一个小技巧：写相机调试代码时，一定要留一套“自动旋转”的调试模式。就是把相机固定在一个点，让 yaw 随时间自动递增，然后观察整个场景绕着你转。这个模式能让你一眼看出远近裁剪、宽高比、朝向符号、透视强度是不是都正常。我每写一个新引擎的相机，第一件事就是先把自动旋转跑起来，确认基础矩阵没问题，再去做交互控制。这个习惯帮我避开了至少一半的相机 bug。
