FFFire小火1. 一个经常被忽略的浪费源：所有被挡住的背面其实都进了渲染管线
1.1 场景还原：几百个方块为什么慢得离谱
我曾经在一台笔记本上调一个体素风格的小场景，大概六七十个方块，加上几个水面平面，自认为这点数量对 GPU 来说连热身都算不上。结果帧率掉到十几帧，而且越靠近方块堆叠区域越卡。第一反应是画了窗口裁剪，也开了深度测试，理论上很多屏幕片段在片元着色器里会被深度测试挡掉，但性能还是上不去。
后来用 RenderDoc 抓了一帧，发现一个非常尴尬的事实：所有方块的不透明几何体其实都被完整送进了光栅化阶段，片元着色器执行次数远大于屏幕上最终可见的片元数量。那些被前面的方块完全挡住的后表面、朝墙那一面的三角形，虽然最终看不见，却已经完成了大量计算。
问题根源其实是个非常老的优化点：面剔除，也就是 Face Culling。
很多人第一次看到这个词会觉得没必要，因为深度测试不是已经在管“谁挡住谁”了吗？事情没那么简单。深度测试发生在片元着色器之后、写入颜色缓冲之前，它只是把“像素级结果”筛了一遍，属于事后补救。而面剔除发生在光栅化之前，它直接把一整块三角形从渲染流程里去掉，属于事前决策。通俗点说，深度测试是“画完了打回去重画”，面剔除是“干脆别画”。
在 LearnOpenGL 的高级 OpenGL 部分，面剔除被单独拎出来讲是有原因的。它不是一个很炫的技术，但如果你了解 GPU 的图元处理流程，就会发现这个简单的开关让 GPU 少干了非常多的脏活累活。
1.2 GPU 在哪一步算“白干”？从图元裁剪到像素着色的账本
把一次普通三角形绘制拆开来看，大致是这样：
- 顶点数据进入顶点着色器，每个顶点都会执行。
- 图元组装，把三个顶点拼成一个三角形。
- 裁剪，对位于视锥体之外的顶点做处理。
- 视口变换，把裁剪坐标变成窗口坐标。
- 光栅化，把三角形转成片元。
- 片元着色器逐个片元执行。
- 深度测试、混合、写入颜色。
面剔除没有执行在顶点着色器之前，它至少要等三角形完成视口变换之后才能判断朝向。所以它并不能帮顶点着色器省钱，三角形的三个顶点该执行还是会执行。真正省掉的是光栅化和片元着色器这一段。
为什么这一段最贵？因为光栅化需要生成大量片元，片元着色器还要对这些片元做纹理采样、光照计算、输出颜色。如果一个三角形在屏幕上覆盖了四分之一个窗口，那么片元着色器就要跑几十万次。而它如果只是个背对摄像机的面，被前面的物体挡得严严实实，这几十万次几乎全是白跑。
我那个体素场景的情况更极端。每个方块是 6 个面，站在外面看最多只能看到 3 个面，另外 3 个面要么朝向内部，要么被旁边的方块挡住。在没有面剔除的时候，这 3 个背面的三角形依然要经历光栅化和片元着色，而且因为方块挨得密，背面三角形与正面三角形重叠的区域特别大，片元着色器执行量几乎翻倍。
开启面剔除之后，每个不透明方块只需要画朝向摄像机的那几个面。性能提升非常直观，同一台笔记本上帧率从十几帧回到了流畅状态。
这里有一条经验可以分享：只要场景模型都是封闭实体，绝大多数几何体都可以放心开面剔除。真正要小心的是那些开着洞、单面片、草叶、半透明面片，这些情况需要单独处理，后面我会展开说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 逆时针就是正面？先把顶点环绕顺序这件事捋清楚
2.1 从一组三角形的“方向感”说起
面剔除的原理听起来简单：把背朝摄像机的那一面丢掉。但 GPU 怎么知道一个三角形是正面还是背面？
假设你手里有一张纸片，你在纸上画一个三角形。从正面看过去，三角形的顶点可能是顺时针排列，也可能是逆时针排列。只要你能看见这张纸的正面，就说明三角形的法向量大致指向你。反过来，如果你从侧面看到的是纸的背面，你看到的三角形顶点顺序会恰好相反。
OpenGL 约定：默认情况下，顶点在窗口坐标里按逆时针顺序排列的三角形被认为是正面。也就是说，三角形在屏幕上形成的外轮廓如果呈逆时针方向，它就是一个面向你的表面，绘制；如果呈顺时针方向，它就是一个背向你的表面，可以被剔