1. 实验课背后的真实意图：这门课到底在磨什么

计算机图形学实验，乍看是布置几道“画三角形”“加光照”的编程题，把它当成普通的代码作业就亏了。我带过几届学生做这类实验，也审过大量实验报告，一个很明显的规律是：最后能拿高分甚至拿满分的，都不是代码写得最花哨的，而是对渲染流程理解最透的那批人。

这门实验课的核心考核点，归纳起来就三层：

第一层是基础理论落地。课堂上讲的是光栅化、坐标系变换、Phong光照模型，听起来全在公式里。实验要求你用OpenGL把公式写成可运行的代码，这意味着你必须搞清楚矩阵乘法到底哪边乘哪边、法线向量为什么不能直接用模型矩阵变换、透视投影的远平面为什么会影响深度精度。每个“为什么”在课堂上是考点，在实验里就是功能能否正常显示的判据。

第二层是渲染管线的工程化理解。很多同学第一次写OpenGL程序都会懵：为什么要创建VAO和VBO？为什么着色器要自己编译链接？glDrawArrays的第三个参数为什么填3不是4？这些不是API的随机设计，而是GPU渲染管线里顶点获取、顶点着色、片元着色几个阶段的直接映射。实验做下来，管线就不再是PPT上的方块图了。

第三层是排错能力。图形学实验和普通后端开发不一样，它的问题往往没有报错信息，只有黑屏、白屏、闪烁、光照位置诡异。你要学会用“二分法”定位问题出在顶点数据、着色器编译、矩阵运算还是绘制状态，这种debug思路比代码本身值钱得多。

所以这篇文章不是简单复述实验步骤，而是把每个实验背后“为什么这么做、常见坑在哪、怎么做能拿高分”都拆开讲。适合正在做这门实验的学生、自学图形学想补实践的人，以及想了解高校图形学课程考核思路的开发者。

2. 实验整体设计与难度梯度：从画点画线到综合场景的进阶逻辑

2.1 典型实验安排与内在递进关系

不同学校的实验任务细节有差异，但主干几乎一致。我接触到的某高校软件学院图形学实验，通常按这样一条线展开：

为什么实验要这样阶梯式设计？因为图形学知识点之间是强依赖的。画不出三角形，后面的矩阵变换就没有载体；不会矩阵变换，光照里的坐标系讨论就是空中楼阁；没有光照的基础认知，纹理映射里“纹理坐标和顶点坐标对应”就说不清楚。这门课的设计者很清楚：图形学学的是“一条渲染流水线的完整实现”，而不是孤立的小技巧。

2.2 每个实验的“真实用意”与容易误读的部分

实验一看起来只是“画个彩色三角形”，实际上它考的是渲染管线的初始化流程。你在代码里写的每一步，都对应管线的一个阶段：创建顶点缓冲是告诉GPU“这里有数据”，定义顶点属性指针是告诉GPU“数据如何解释”，编译着色器是准备GPU执行程序，glDrawArrays才是真正让数据流经管线。不少同学在这个实验里跳过了VAO直接绑定VBO，旧版OpenGL确实能跑，但到了实验三需要切换多个物体时就会暴露问题——VAO的目的就是把顶点数据配置和绘制状态打包封装，让你每次绘制时只需绑定一次，而不是反复设置属性指针。

实验二的几何变换，核心不是你会调glm::translate，而是搞懂矩阵乘法的顺序。很多同学写出的代码是model * view * projection，然后疑惑为什么旋转中心不对。实际顺序应该是projection * view * model，然后顶点坐标在最右边作为列向量参与乘法。从数学上看，顶点先经过模型变换进入世界空间，再经视图变换进入摄像机空间，最后经投影变换进入裁剪空间。顺序反了，物体的位置就在每个坐标系里错位了。

实验三的光照是分水岭。Phong模型三个分量里，环境光和漫反射计算相对直观，镜面反射的pow值调参最容易出问题。还有两个隐蔽考点：一是法线矩阵。当模型发生非等比缩放时，法线向量不能直接用模型矩阵变换，因为缩放会改变法线方向，必须用模型矩阵的逆转置矩阵来变换。二是光源位置到底在哪个坐标系。如果是世界空间，片元的世界坐标需要由顶点着色器插值得到，这涉及到Gouraud和Phong着色两种策略的差异。

实验四的纹理映射，表面看是贴图，实际考的是纹理坐标和采样参数的配合。纹理过滤的GL_NEAREST和GL_LINEAR差异、纹理环绕的GL_REPEAT和GL_CLAMP_TO_EDGE差异，在实验中必须肉眼可见地调出来对比。这个实验也是大多数同学第一次遇到“图片反了”问题的地方——不是图片素材被上下翻转，就是纹理坐标的v轴方向搞反了。

综合场景实验是前面所有能力的合并，它不只是“把之前的代码拼起来”，而是考察渲染管理和状态切换。多个物体各自需要不同的VAO、不同着色器程序、不同纹理绑定，绘制顺序稍错就会出现透明物体挡在前面或物体看不见的问题。

3. 环境搭建与工具选型：为什么是OpenGL，以及环境怎么配最稳

3.1 OpenGL在高校实验中的统治地位与原因

如果你查资料，会发现DirectX 12、Vulkan、Metal这些现代图形API各有优势，但绝大多数高校图形学实验还是选OpenGL。这背后有很现实的原因。

OpenGL的抽象层级非常适合教学。它保留了“状态机”的概念：当前绑定哪个缓冲区、启用哪些功能，代码里一目了然。Vulkan把状态管理全部交还给开发者，效率高但复杂度爆炸；DirectX绑定特定平台，很多实验室的Windows机器上配置环境反而不那么顺畅。OpenGL配合GLFW和GLAD，Windows、Linux、macOS上都能跑，不锁定平台。

另一个原因是参考资源极度丰富。几乎所有图形学入门教程都有OpenGL版本，从窗口创建到PBR渲染，案例一抓一把。对于初次接触渲染管线的本科生来说，有一个庞大开源社区做后盾，卡住了能快速找到解法，这让课程的推进阻力小很多。作为教学工具，OpenGL是兼顾“学到原理”和“可行可跑”的最优解。

3.2 我的推荐环境组合：GLFW + GLAD + GLM

具体到实验开发，我个人最稳的组合是：

• GLFW：负责窗口创建、OpenGL上下文初始化、键盘鼠标输入。它在三个平台都预编译好，Cmake里target_link_libraries一行就搞定。
• GLAD：负责加载OpenGL函数指针。因为OpenGL规范只规定了函数接口，具体函数地址由显卡驱动提供，运行时必须动态加载。GLAD根据你指定的版本生成加载代码，配置最简单。
• GLM：纯头文件的数学库，矩阵和向量运算直接包含。虽然新版OpenGL止于GLSL 4.6，但GLM实现了GLSL风格的全部数学类型，和着色器代码里的表达式几乎一一对应，排错时特别省心。

为什么不选其他组合？比如用freeglut，比GLFW更轻量，但扩展性差，实验三开始我们往往需要监控鼠标移动控制摄像机视角，freeglut做起来很别扭。再比如我们自己写矩阵运算类，理论上是锻炼，但实验时间和调试成本会翻好几倍。课程实验的目标是把图形学原理跑通，不是造数学轮子，GLM是性价比最高的选择。

3.3 配置步骤与版本选定的实操方法

配置环境的步骤，我用CMake集成GLFW和GLAD，流程很稳定。GLAD部分需要注意版本选择：在glad的在线服务页面里，API选OpenGL 3.3 Core Profile。为什么是3.3？因为3.3是OpenGL现代化分界线，废弃了立即模式，强制走VAO/VBO和着色器流程，这正好对应教学要求。如果选老版本2.1，你会看到一堆旧式API，容易养成错误习惯；选4.x新特性多，但教学场景用不上，反而增加编译配置难度。

CMake里核心配置大概是：

find_package(OpenGL REQUIRED) add_executable(graphic_lab main.cpp) target_link_libraries(graphic_lab PRIVATE glfw glad ${OPENGL_LIBRARIES})

这里有个细节：CLion用CMake，Visual Studio也可以直接加依赖项，但不建议手工把dll往系统目录塞。用CMake管理依赖的好处是换机器重克隆项目后能一键重建，不会因为少个dll导致整个环境跑不起来。

GLM的引入更省事，因为它全是头文件，直接把include目录指向GLM源码根目录就能用：

#include <glm/glm.hpp> #include <glm/gtc/matrix_transform.hpp>

环境配置阶段最容易出的问题就是版本不匹配。GLAD生成的函数列表是针对某个OpenGL版本的，而GLFW创建的上下文也是指定版本的，两者不一致时，glGenVertexArrays函数会报“illegal call”或者直接崩。所以初始化GLFW时一定要显式指定：

glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);

别忘了这组hint。少写一行，语境就是另一个世界，改动会非常痛苦。

4. 核心实验逐项拆解：从代码结构到算法选择的完整思路

4.1 实验一：VAO/VBO的完整创建流程与绘制状态封装

第一个实验很多人从复制教程代码开始，这一步没问题，但必须边抄边问“为什么这样”。以最基础的三角形绘制为例，正确的创建顺序是：

1. 生成并绑定VAO；
2. 生成并绑定VBO；
3. 将顶点数据拷入VBO；
4. 设置顶点属性指针（glVertexAttribPointer）；
5. 启用顶点属性（glEnableVertexAttribArray）；
6. 解绑VBO和VAO。

为什么必须先绑定VAO再绑定VBO？因为VAO的核心作用就是记录“当前VBO是谁、属性指针怎么解释、属性是否启用”这整套状态。如果我们先创建VBO再绑定VAO，VAO就没有机会记录这个VBO的信息，绘制时GPU根本不知道顶点数据在哪。

还有一个容易忽视的点：顶点属性指针的最后一个参数是偏移量，而不是步长。比如位置属性是3个float，偏移量就是0；如果我们后续再加颜色属性是3个float，颜色属性的偏移量则是3 * sizeof(float)。玻璃心一点的同学会觉得纠结，但我可以在创建时直接定义顶点结构体：

struct Vertex { glm::vec3 position; glm::vec3 color; };

然后glVertexAttribPointer里传offsetof(Vertex, color)，这样即使以后vertex结构体加了UV或法线字段，属性偏移也不会写错。

着色器编译链接的流程也是固定套路：读取源码、创建shader、指定GLSL版本、检查编译日志。GLSL里第一行必须写：

#version 330 core

如果版本号比GLFW上下文版本高，编译报错；比版本低，部分新语法用不了。我又一次遇到同学在Shader里写in和out，结果GLSL版本写的是110，编译报了一堆语法错误——这些前置的统一设置最好直接做成一个工具函数，之后每个实验复用。

4.2 实验二：坐标系矩阵乘法顺序与深度冲突问题

几何变换实验的代码核心很简单，就是构造三个矩阵：

glm::mat4 model = glm::mat4(1.0f); model = glm::rotate(model, glm::radians(angle), glm::vec3(0.0f, 1.0f, 0.0f)); glm::mat4 view = glm::lookAt(cameraPos, cameraTarget, cameraUp); glm::mat4 proj = glm::perspective(glm::radians(45.0f), (float)WIDTH / HEIGHT, 0.1f, 100.0f); glm::mat4 mvp = proj * view * model;

着色器里gl_Position = mvp * vec4(aPos, 1.0f);的矩阵顺序，一定要先乘model到世界空间，然后乘view到相机空间，最后乘proj到裁剪空间。这个顺序背后是坐标系的嵌套层级，model是把局部坐标变到世界坐标，view是把世界坐标变到观察坐标，proj是观察坐标变到裁剪坐标。顺序反了，请你想象把所有物体先压扁再搬走再旋转，结果必然诡异。

关于投影矩阵的参数，透视投影的fov通常取45度，near取0.1，far取100。如果场景很小，near不能取太小，比如0.001，因为near和far的比值决定了深度缓冲的精度分布，near太小会导致远处的深度值挤在一起，出现深度冲突——远处的物体表面闪烁抖动。

我自己处理过一个案例，场景是一个地面加两个立方体，地面用重复纹理延伸到远方，相机拉远后地面部分区域疯狂闪烁。排查了很久，最终把near从0.001改到0.1，问题立刻消失。这就是典型深度精度问题，需要记住一个经验法则：near和far间距越小，深度精度越好；fov越大，场景边缘畸变越严重。

4.3 实验三：Phong光照模型的三种实现策略与法线矩阵

光照实验是最容易拿捏不准的一次。先聊着色策略，有Gouraud shading、Phong shading和Blinn-Phong shading三种。

• Gouraud：在顶点着色器算光照，结果插值到片元。性能最好，但高光容易变形，适合低精度模型。
• Phong：在片元着色器算光照，逐像素计算，效果好，是实验最常要求的。
• Blinn-Phong：用半程向量代替反射向量计算高光，比Phong更贴近真实感，而且效率略高。

实验要求里如果只写“Phong”，建议实现Blinn-Phong，因为代码差别极小，呈现效果却更平滑。半程向量公式很简单：

vec3 lightDir = normalize(lightPos - fragPos); vec3 viewDir = normalize(viewPos - fragPos); vec3 halfDir = normalize(lightDir + viewDir); float spec = pow(max(dot(normal, halfDir), 0.0), shininess);

Blinn-Phong和Phong之间的视觉差异主要在平滑度，Blinn-Phong会对低shininess值更友好，能展示更多的柔和高光。

光照实验中最大的坑在法线变换。当model矩阵含非等比缩放时，直接normalize(mat3(model) * normal)会得到错误光照。这时需要用法线矩阵：

glm::mat3 normalMatrix = glm::transpose(glm::inverse(mat3(model)));

在顶点着色器里把法线乘以normalMatrix传给片元着色器。注意：如果model只是旋转和平移，inverse和transpose可以省略，因为旋转矩阵是正交矩阵，inverse就是transpose，变换法线效果一样。但一旦有非等比缩放，不做逆矩阵直接变换，比如一个拉长的盒子表面，高光方向会完全错乱。

另外，光源位置信息的传入要注意坐标系。如果你在顶点着色器算光照（Gouraud），光源位置必须也在世界空间，那么顶点模型坐标要先乘model再参与计算。如果你在片元着色器算光照，把fragPos从顶点着色器插值过来，同样保持世界空间。常见的错误是在片元着色器里又乘了一遍model，导致光照位置跟着物体一起旋转，看起来就像是光贴在了模型上。

我建议养成一个习惯：定一个“全部在世界空间计算”的约定。model变换后的fragPos是世界坐标，lightPos和viewPos都是世界坐标，normalMatrix处理后的法线是世界坐标，所有计算都在同一个坐标系里，少一个坐标系，就少一类bug。

4.4 实验四：纹理映射的坐标方向与过滤效果对比

纹理实验的流程：stb_image加载图片，生成纹理对象，绑定并设置参数，然后传给着色器采样。听起来简单，但第一个坑就会出现：图片加载出来是上下颠倒的。

这源于OpenGL纹理坐标的原点在左下角，而常见图片格式如PNG、JPG的扫描顺序通常从左上角开始。我加载纹理后通常在着色器里翻转v坐标，或者在传UV时用1.0 - v，效果相同。可以用stb_image的stbi_set_flip_vertically_on_load(true)一行解决。这个设置是一次性的，放main函数开头即可。

纹理过滤参数的选择也影响视觉质量，建议用GL_LINEAR_MIPMAP_LINEAR三线性过滤，同时生成mipmap，这样视角拉远时不会出现摩尔纹（高频细节混叠产生的波纹闪烁）。生成mipmap只需一行：

glGenerateMipmap(GL_TEXTURE_2D);

如果纹理坐标超出[0,1]，就需要设置纹理环绕方式。GL_REPEAT让纹理重复平铺，GL_CLAMP_TO_EDGE让边缘像素拉伸。这里建议在实验里做一张对比图：一个平面用GL_REPEAT，一个用GL_CLAMP_TO_EDGE，肉眼观察有什么区别，报告里直接截图，老师一眼就能看到你理解了这个参数。

纹理单元的绑定也是常见困惑点。GPU上有多个纹理单元，默认使用GL_TEXTURE0。如果你的着色器里有多个sampler，需要先glActiveTexture(GL_TEXTURE0)，再glBindTexture，然后把uniform按单元号赋值：

glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture1); glUniform1i(glGetUniformLocation(shader.ID, "texture1"), 0);

5. 实验报告怎么写在分数上的权重：严谨记录比华丽排版重要

5.1 常见评分标准与报告结构建议

实验课的最终成绩通常由代码演示和实验报告两部分决定。我在往届评审中观察到，报告占40%~60%不等，代码占40%~50%，还有一些考勤和抽查提问。所以“写完代码就算完”是大忌。

报告里最需要写清楚的是四块：

1. 实验目的与原理：不抄PPT，用自己的话描述本次实验要验证的渲染管线的哪个阶段，或者光照模型的哪个公式。能写出“这一实验验证了法线矩阵对非等比缩放的必要性”这句话，老师就知道你真理解了。
2. 核心算法与流程：画数据流图或者伪代码，标注关键转换公式。不要贴整段源码，贴核心函数即可。
3. 实验结果与分析：必须要有截图，而且是要能体现特性差异的对比截图。比如光照实验调高shininess前后的高光变化、纹理实验更换过滤方式前后的清晰度变化，这类对比图是报告的信息密度所在。
4. 问题与解决：记录你在实验中遇到的至少1个bug，描述现象、定位过程和解决方式。这一部分的含金量极高，因为排错过程就是工程能力的直接证据。

5.2 提高分的三个小技巧

第一个技巧是做扩展实验。实验要求画一个立方体，你锉平一个场景里放五个物体并加了一个轨道摄像机，但不需要写很多扩展说明，报告里列出扩展点即可。这部分不是炫技，而是证明你有“迁移应用”的能力。

第二个技巧是截图讲究“参数标注”。不要只放一张最终效果图，而是在图旁边写清楚当前是什么参数，比如“fov=60”“shininess=32”“光源位置(2,3,1)”，最好同一视角分别渲染两个不同参数的效果对比。读数的人不用猜，印象分直接提升。

第三个技巧是记录运行环境。OpenGL版本、显卡型号、屏幕分辨率、操作系统，这些看起来琐碎的信息其实会影响渲染结果。特别是你在公司或机房电脑上演示，和自己笔记本环境不一致时，这些信息能帮老师快速判断是不是环境差异导致的问题，也体现你的工程素养。

6. 常见问题与排查技巧实录：黑屏、不显示、光照异常的定位思路

6.1 编译与链接阶段：报错信息解读的方法

图形学实验的编译错误，90%集中在链接库不对和GLSL版本不匹配上。

链接报错“undefined reference toglfwCreateWindow”这类，说明GLFW没有链接成功。检查CMake的target_link_libraries里是否写了glfw，以及依赖顺序是不是在源文件之后。CMake的链接库里，顺序有讲究：b先依赖a，此时写法要target_link_libraries(target PRIVATE b a)。

更隐蔽的问题是GLAD和GLFW的OpenGL版本不匹配。有个典型现象：窗口创建成功后，glGenVertexArrays直接段错误。排查先看GLAD是不是生成的3.3版本、GLFW是否在创建窗口前调用了glfwWindowHint。再多提一嘴：glfwInit的返回值要检查，失败早发现早解决。

GLSL编译器日志是很友好的排错助手。在着色器编译失败后调用glGetShaderInfoLog就能看到具体行号和错误原因：

int success; char infoLog[512]; glGetShaderiv(shader, GL_COMPILE_STATUS, &success); if (!success) { glGetShaderInfoLog(shader, 512, NULL, infoLog); std::cout << "ERROR::SHADER::VERTEX::COMPILATION_FAILED\n" << infoLog << std::endl; }

错误信息里最常见的两个：一个是“version not supported”，另一个是“syntax error”，前者说明版本设置不一致，后者说明GLSL语句里有解析错误，尤其要注意vec3是类型名，不能同时用作变量名。

6.2 运行时阶段：黑屏和场景缺失的定位逻辑

黑屏是最让人头疼的现象，但不报错。我的排查轴固定是：

1. 先确认清屏颜色。改glClearColor为白色，看窗口是否变白。如果变白，说明上下文和交换缓冲正常。
2. 确认着色器是否编译链接成功。GLSL报错不一定会打断程序运行，只是程序里没有可用shader，绘制的结果是未定义行为。所以通过glGetUniformLocation返回值是否为-1，能快速判断着色器程序是否有效。
3. 确认相机视角。很多“黑屏”实际是物体在相机外面。把glm::lookAt的相机位置改成(0,0,5)，目标点改成(0,0,0)，再确认near和far覆盖了物体距离。如果物体距离5，near是0.1，far是100，就在范围内。
4. 确认MVP矩阵。用一个最简单的位移测试：model全是单位矩阵，proj用一个正交投影，比如glm::ortho(-1.0f, 1.0f, -1.0f, 1.0f, 0.1f, 100.0f)，如果能看到物体，再换回透视投影，问题就出在透视矩阵参数上。

如果以上都正常但物体仍是黑色，那可能是光照计算的normal方向全部朝里了，或者说片元法线和光线方向点乘结果为负，取max(0, dot)之后全部输出0。把漫反射改成长亮色测试，比如：

vec3 color = vec3(0.75f, 0.75f, 0.75f);

如果颜色正常显示，就可以确认问题出在光照输入而非管线流程。

6.3 光照异常的典型案例与调整方法

光照实验里最常见的一个画面是：物体半边亮半边黑，而且分界线不随光源移动而改变。这是法线数据或法线矩阵的问题。用调试着色器直接把法线显示成颜色：

color = normal * 0.5f + vec3(0.5f);

展开到屏幕上，正常法线应该是平滑渐变的彩色。如果出现硬边界或者出现负值导致的黑色区域，就说明法线数据本身有误，要么顶点数据没定义法线，要么从OBJ文件读入时法线索引错位。

另一个常见问题：高光部分太小或者太亮。这是shininess参数的问题，你可以在代码里通过glfwSetKeyCallback动态加减这个值，实时观察效果。但注意一个细节，shininess值大时高光倾向于小而锐利，值小时高光大而柔和，这个变化在做报告对比图时非常直观。

至于光源颜色和物体颜色是乘法的关系，这点不少同学会忽略。他们用纯白光源加纯白物体还正常，换成黄色光源配蓝色物体，结果物体变绿了——这不是bug，这是光照颜色乘法的自然结果，GLSL里的vec3乘法是逐分量相乘，不是点乘也不是叉乘。

7. 综合场景扩展：如何用最少的代码搭建一个能演示的3D小世界

综合实验的目标是展示自己掌握了整个渲染流程，但不等于要写很多很复杂的代码。我见过有同学用2000行代码搭了一个完整城市场景，但也见过300行代码做出一个星空地面加浮动立方体的效果，后者分数反而更高，因为核心知识点的完整度更清晰。

搭建综合场景，我推荐的最小可用方案：

地形：一个平面网格，手动生成顶点数组即可。用GL_TRIANGLES且逐行列遍历，生成顶点颜色的渐变效果，配合一张草地纹理和GL_REPEAT参数。

物体：立方体加球体两种即可。立方体适合展示纹理映射，球体适合展示光照效果，两个物体用不同的材质参数。球体的法线生成要注意用顶点坐标归一化而不是面法线，否则球体表面的高光会呈平面化阶梯分散。

光源：两个点光源加一个方向光是最均衡的组合。点光源放在相机左右两侧的不同高度，方向光作为太阳。两盏点光源让物体表面出现双高光，这个视觉效果用来展示Blinn-Phong模型的优缺点更有说服力。

摄像机控制：用GLFW的鼠标回调和键盘回调实现第一人称旋转观察，这个模式只需几十行代码，但演示时可以让老师自由观察场景的每个细节，是提升演示体验最有效的一步。

摄像机控制的每一步都不能省：先处理glfwGetCursorPos计算偏移，再更新yaw和pitch，注意pitch要限制在正负89度防止万向锁翻转，最后根据欧拉角构造front向量。

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)); cameraFront = glm::normalize(front);

这套代码在后续做任何3D交互程序都可以复用，不要觉得麻烦，这是图形学实验里复用价值最高的模块之一。

8. 我的实操心得：交实验前必须做的五项自查

每次做完实验，我建议按下面这个清单自查一遍。这个习惯能帮你省掉答辩被临时提问时的尴尬：

第一，检查窗口大小变化时的表现。固定窗口大小看不到问题，但调整窗口大小后物体可能被拉伸变形。这是因为没有在窗口回调里更新glViewport，或者投影矩阵里的宽高比还是写死的。可以注册glfwSetFramebufferSizeCallback来更新视口和投影矩阵。

第二，检查多物体绘制时的状态泄漏。综合场景里绘制球体用shaderA，绘制地面用shaderB。如果画完球体后没有重置混合模式或深度状态，画地面时会发生奇怪的现象。规矩是shader.use()前先设置需要的状态，用完不用急着改，但每次绘制前必须让状态符合当前物体需求。

第三，检查glDisable的配对。开启深度测试后，如果涉及透明物体，你可能要暂时关闭深度写入或调整混合函数。这个过程中写下的每个glEnable/glDisable都要检查是否成对，否则透明物体显示逻辑会崩溃，而且只能折半定位。

第四，对着构图谈谈美感。实验报告里如果你截了几张图，构图和光照角度本身就会说话。多花几分钟调出“物体占画面中央、高光点不过曝、背景色与物体对比明显”的画面，截图质量会直接影响第一印象分。

第五，把代码里所有硬编码的参数归类。比如光源位置、旋转速度、视角fov，建议全部用const变量或者在main函数顶部集中定义。答辩时老师问“如果把光源移到右边，物体效果有什么变化”，你可当场改参数重新编译演示，这是你代码可用性和可维护性的直接证明。

最后分享一个我自己的习惯：图形学实验的坑踩多了之后，我会在代码里频繁使用glGetError检查错误，但更有效的是写一个宏封装，每帧结束时自动检查一次OpenGL错误队列：

#define GL_CHECK() \ do { \ GLenum err; \ while ((err = glGetError()) != GL_NO_ERROR) { \ std::cerr << "OpenGL error: " << err << " at line " << __LINE__ << std::endl; \ } \ } while(0)

这个宏不会帮你修复问题，但它会把隐藏的API错误暴露出来，比如glDrawArrays之前VAO没绑定好，glUniform3fv传了错误的uniform位置，这些都能在运行日志里第一时间看到。图形学实验本身是一个“以可见结果为导向”的训练，出了bug不要慌，把问题拆成管线每一阶段分别验证，基本都能在半小时内定位。这套思维，比实验本身给的分数更值得带走。