简介：这是一份面向Qt与OpenGL开发者的三维模型加载示例工程，帮助解决在Qt窗口中加载并显示glb、obj等常见模型格式的问题。工程基于模型解析库完成文件读取，配合界面框架与OpenGL渲染管线，适合需要快速实现模型导入、缩放旋转、光照贴图等功能的开发者参考。资源共有118个文件，压缩包约9.94MB，以C++头文件与源代码文件为主，同时包含顶点着色器、片元着色器、界面布局文件、项目配置文件、模型与纹理资源，以及运行所需的动态库和静态库依赖，覆盖从工程搭建到渲染显示的完整代码结构。目前已有1732人学习或下载，主要模块包括模型加载类、OpenGL窗口部件和网格处理，配合示例模型即可直接查看加载效果。使用者可将这套工程集成到自己的Qt项目中，也可对照学习模型解析接口的调用与OpenGL绘制流程，适合在已有图形学基础上进一步提升三维应用开发能力。
1. Qt + OpenGL 加载 .glb/.obj：先让模型“能显示”，再谈“显示好”
把 .obj 拖进 Qt 窗口，第一次看到黑屏，我第一反应是显卡驱动坏了。查到最后，问题出在顶点属性布局：position 和 normal 的 stride 传错，GPU 拿到错位数据，自然画不出东西。这套 Qt + OpenGL 加载 3D 模型的工程，把 .glb 和 .obj 两种格式的解析、GPU 上传、着色器渲染串成一条完整链路，适合要在桌面工具里做模型预览、又不想为一个小功能拖进整套引擎的开发者。跟着后面的步骤走，先解决“能显示”，再处理贴图和坐标轴，坑我已经替你踩过一遍。
2. 从文件到 GPU 的数据管线：QOpenGLWidget、着色器与 VBO 布局
QOpenGLWidget 是 Qt 5 之后最稳妥的渲染容器，它把 OpenGL 上下文、帧缓冲和 Qt 事件循环的绑定关系都处理好了。我选它不是因为 Qt3D 不好，而是在只需要展示一个或少数几个模型时，QOpenGLWidget 的侵入性最低：放进 QMainWindow 的中央区域，重写三个虚函数就能跑。真正决定后面能不能顺利显示的是初始化时机——QSurfaceFormat 必须在创建窗口之前设好，否则你会拿到一个和预期不一致的默认 OpenGL 上下文。
很多从旧教程入门的开发者还在用 QGLWidget，那个类在 Qt 5 之后已经被标记为 deprecated，且它绑定的是 OpenGL 1.x 的固定管线写法。QOpenGLWidget 配合 OpenGL 3.3 Core Profile 才是现代做法：不用 glBegin/glEnd，也不依赖 GLU，顶点数据全部走 VAO/VBO，shader 负责顶点变换和着色。
2.1 先设置 QSurfaceFormat，再创建 QOpenGLWidget
我一般在 main 函数里就把默认格式定死，避免窗口建好后再去改。代码是这样的：
#include <QApplication> #include <QSurfaceFormat> #include "ModelWidget.h" int main(int argc, char *argv[]) { QApplication app(argc, argv); QSurfaceFormat fmt; fmt.setRenderableType(QSurfaceFormat::OpenGL); fmt.setProfile(QSurfaceFormat::CoreProfile); fmt.setVersion(3, 3); fmt.setDepthBufferSize(24); fmt.setSamples(4); QSurfaceFormat::setDefaultFormat(fmt); ModelWidget w; w.resize(1024, 768); w.show(); return app.exec(); }这段代码里的setVersion(3, 3)和setProfile(CoreProfile)决定你后面能用的 API 范围。Core Profile 下画三角形不能再写glBegin(GL_TRIANGLES)，必须走 VBO + VAO，这个约束其实是好事，逼着把顶点布局写清楚。setDepthBufferSize(24)是深度测试的基础，模型前后遮挡关系靠它；setSamples(4)是 4 倍 MSAA，模型边缘锯齿会轻一些。如果你的目标机器显卡比较老，先把 samples 改成 0，等基本轮廓能出来再开抗锯齿。
2.2 着色器里最不能省的矩阵：法线矩阵
顶点和索引只是原始数据，能不能看到立体的模型，取决于 shader。我用的顶点着色器长这样：
#version 330 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aNormal; layout(location = 2) in vec2 aUV; uniform mat4 uProjection; uniform mat4 uView; uniform mat4 uModel; out vec2 vUV; out vec3 vWorldNormal; out vec3 vWorldPos; void main() { vec4 worldPos = uModel * vec4(aPos, 1.0); vWorldPos = worldPos.xyz; vWorldNormal = mat3(transpose(inverse(uModel))) * aNormal; vUV = aUV; gl_Position = uProjection * uView * worldPos; }注意vWorldNormal这一行，它不是直接用mat3(uModel)乘 normal，而是先对uModel求逆再转置。原因很实际：当你对模型做非均匀缩放，比如 X 轴拉长两倍，法线如果跟着顶点一起缩放，方向就歪了，光照会出现奇怪的明暗块。这个transpose(inverse())的写法在 GLSL 里没有内置函数，只能自己在 CPU 端算好再传进去，或者像上面这样在 shader 里对 mat3 处理。模型数量少的时候 CPU 端隔帧算一次没问题；模型多起来，建议在 CPU 端用QMatrix4x4::normalMatrix()拿到结果，再传 uniform。
对应的片段着色器可以先用最简单的漫反射跑通：
#version 330 core in vec2 vUV; in vec3 vWorldNormal; in vec3 vWorldPos; uniform vec3 uLightPos; out vec4 fragColor; void main() { vec3 lightDir = normalize(uLightPos - vWorldPos); float diff = max(dot(normalize(vWorldNormal), lightDir), 0.0); fragColor = vec4(vec3(diff * 0.8 + 0.2), 1.0); }这样至少能通过明暗看出模型的体积。shader 的编译和链接在 Qt 里用 QOpenGLShaderProgram 完成，addShaderFromSourceFile支持 Qt 资源路径，我习惯把 shader 放进:/shaders/，省去部署路径的麻烦。
2.3 VBO 的数据布局：一个顶点一个打包结构体
同一个模型的数据有三种常见排法：position、normal、uv 各开一个 VBO；三个数组独立上传然后分别 setAttributeBuffer；或者所有属性按顶点交织成一个结构体数组。我推荐第三种，原因很简单：GPU 读取缓存更连续，glVertexAttribPointer 的 stride 也更好理解。
struct VertexData { float pos[3]; float normal[3]; float uv[2]; };上传时这样绑定：
m_vao.create(); m_vao.bind(); m_vbo.create(); m_vbo.setUsagePattern(QOpenGLBuffer::StaticDraw); m_vbo.bind(); m_vbo.allocate(vertexData.constData(), int(vertexData.size() * sizeof(VertexData))); m_ebo.create(); m_ebo.bind(); m_ebo.allocate(indexData.constData(), int(indexData.size() * sizeof(GLuint))); m_program.setAttributeBuffer(0, GL_FLOAT, 0, 3, sizeof(VertexData)); m_program.enableAttributeArray(0); m_program.setAttributeBuffer(1, GL_FLOAT, 3 * sizeof(float), 3, sizeof(VertexData)); m_program.enableAttributeArray(1); m_program.setAttributeBuffer(2, GL_FLOAT, 6 * sizeof(float), 2, sizeof(VertexData)); m_program.enableAttributeArray(2); m_vao.release();这里的第 4 个参数是顶点属性在单个顶点内部的起始偏移，第 5 个参数是整个顶点结构的长度。很多人写成0导致 normal 用了 position 的坐标，模型看起来像被揉成一团。偏移值用offsetof(VertexData, normal)写更稳，不要在三个地方手打常量，改了结构体忘了改偏移就是一次事故。VAO 创建后，EBO 会跟着 VAO 绑定，绘制时只需要m_vao.bind()，接着调glDrawElements，不需要每帧重新绑定 VBO。
3. 解析 .obj 的实战写法：顶点、法线、索引与 MTL 材质的处理边界
Wavefront OBJ 是文本格式，看似简单，但不同导出器写出来的差异能让人怀疑人生。v是顶点坐标，vt是纹理坐标，vn是法线，f是面索引，这个大家都懂。真正容易翻车的是索引基址和面的形状：OBJ 的索引从 1 开始，而 OpenGL 的顶点数组从 0 开始；OBJ 的面可以是三角面、四边面甚至多边形，但 OpenGL 的 GL_TRIANGLES 只认三角形。
很多网上下载的工业模型，f行可能有 5 个甚至 8 个顶点，直接丢给 GPU 绘制索引数组是不行的。我的做法是先按多边形读进来，再用扇形三角化拆成多个三角形。扇形三角化不适合非常复杂的带洞多边形，但预览场景足够，而且代码量小、容易排查。
3.1 OBJ 语法里最容易被忽略的两个点
第一个点：f 1/2/3 4/5/6 7/8/9这行里，三个数字分别代表 position 索引、纹理索引、法线索引的下标，后面的纹理和法线索引可能为空。比如f 1//3表示没有vt，但法线索引是 3。解析时不能整行直接toInt，必须按/拆开后逐段判断。
第二个点：OBJ 的索引基址是 1-based，读取之后必须-1。忘了减 1 的结果不是崩溃，而是模型的每条边都错位一格，看起来像被随机撕开，这种问题最难查，因为错误不会稳定报在同一个顶点上。我会在解析阶段统一把三个索引都减 1，后面所有代码都用 0-based 索引，不再回头处理。
3.2 解析并上传顶点数据：我常用的代码骨架
下面是我在一个 Qt 工程里实际用过的简化版解析代码，核心逻辑是先用临时数组存 position、normal、uv 和 face，再通过一个 corner-to-index 的映射做顶点去重：
struct Corner { int v; // position 索引 int vt; // 纹理坐标索引，-1 表示没有 int vn; // 法线索引，-1 表示没有 }; bool loadObj(QTextStream &in, QVector<VertexData> &outVertices, QVector<GLuint> &outIndices) { QVector<QVector3D> positions; QVector<QVector2D> texcoords; QVector<QVector3D> normals; QVector<QVector<Corner>> faces; while (!in.atEnd()) { const QString line = in.readLine(); if (line.isEmpty() || line.startsWith(QLatin1Char('#'))) continue; const QStringList tok = line.split(QLatin1Char(' '), QString::SkipEmptyParts); if (tok.isEmpty()) continue; if (tok[0] == QLatin1String("v") && tok.size() >= 4) { positions.append(QVector3D(tok[1].toFloat(), tok[2].toFloat(), tok[3].toFloat())); } else if (tok[0] == QLatin1String("vt") && tok.size() >= 3) { texcoords.append(QVector2D(tok[1].toFloat(), tok[2].toFloat())); } else if (tok[0] == QLatin1String("vn") && tok.size() >= 4) { normals.append(QVector3D(tok[1].toFloat(), tok[2].toFloat(), tok[3].toFloat())); } else if (tok[0] == QLatin1String("f")) { QVector<Corner> face; for (int i = 1; i < tok.size(); ++i) { Corner c{-1, -1, -1}; const QStringList segment = tok[i].split(QLatin1Char('/')); if (!segment.isEmpty()) c.v = segment[0].toInt() - 1; if (segment.size() > 1 && !segment[1].isEmpty()) c.vt = segment[1].toInt() - 1; if (segment.size() > 2 && !segment[2].isEmpty()) c.vn = segment[2].toInt() - 1; face.append(c); } faces.append(face); } } QHash<QString, GLuint> cache; auto makeVertex = [&](const Corner &c) -> GLuint { const QString key = QString::number(c.v) + QLatin1Char('/') + QString::number(c.vt) + QLatin1Char('/') + QString::number(c.vn); const auto it = cache.constFind(key); if (it != cache.constEnd()) return *it; VertexData vd; memset(&vd, 0, sizeof(VertexData)); if (c.v >= 0 && c.v < positions.size()) { vd.pos[0] = positions[c.v].x(); vd.pos[1] = positions[c.v].y(); vd.pos[2] = positions[c.v].z(); } if (c.vt >= 0 && c.vt < texcoords.size()) { vd.uv[0] = texcoords[c.vt].x(); vd.uv[1] = texcoords[c.vt].y(); } if (c.vn >= 0 && c.vn < normals.size()) { vd.normal[0] = normals[c.vn].x(); vd.normal[1] = normals[c.vn].y(); vd.normal[2] = normals[c.vn].z(); } const GLuint index = GLuint(outVertices.size()); outVertices.append(vd); cache.insert(key, index); return index; }; for (const auto &face : faces) { if (face.size() < 3) continue; const GLuint i0 = makeVertex(face[0]); for (int i = 2; i < face.size(); ++i) { outIndices.append(i0); outIndices.append(makeVertex(face[i - 1])); outIndices.append(makeVertex(face[i])); } } return !outVertices.isEmpty() && !outIndices.isEmpty(); }这段代码里决定成败的是三个参数：QString::SkipEmptyParts处理多空格和行尾空格；c.vt和c.vn的默认值设成-1，能安全跳过缺少纹理或法线的模型；makeVertex里的 cache key 用v/vt/vn三个索引拼出来，可以避免同一个角点被重复新建顶点，大幅压低顶点数。
3.3 MTL 材质：有默认颜色就能先跑，纹理放到第二步
OBJ 的材质信息存在同名的 .mtl 文件中，通过mtllib引用，面级通过usemtl指定。完整实现 MTL 解析要处理 Ka、Kd、Ks、Ns、map_Kd 等一堆字段，但预览场景可以先做减法：第一版不读贴图，默认给一个灰色或者用Kd的颜色填 uniform。先把模型的几何形状验证对，再引入 QOpenGLTexture 加载map_Kd。
如果你发现某个 OBJ 加载后全是黑的，先别怀疑光照，去看看它的f行有没有vn。很多基础模型只导出 position 和 uv，没有法线，shader 里 normalize 一个零向量，光照结果自然是黑的。这种情况可以在解析阶段根据相邻三角形叉积估算法线，或者先在 shader 里给一个假的朝上法线，形状验证通过后再补真实法线。
4. 加载 .glb / glTF 2.0：从 JSON chunk 到 accessor 的映射关系
GLB 是 glTF 2.0 的二进制容器，比 OBJ 要规整得多。整个文件由 header、JSON chunk、BIN chunk 构成，JSON chunk 描述场景结构和材质，BIN chunk 存放真正的顶点数据、索引数据、贴图数据。第一次接触时容易把 JSON 里描述的 accessor 和 bufferOffset 当作直接文件偏移，实际必须经过 bufferView 这一层才能定位到 BIN chunk 里的真实位置。
选择自定义解析还是用 tinygltf，取决于你对依赖的容忍度。如果只想读 GLB 的几何数据，自己解析 header 和 chunk 并不过分，因为 GLB 的文件结构很固定；如果你要处理 Draco 压缩、动画、稀疏 accessor，老老实实用 tinygltf 这类成熟库更省事。我在这套加载器里是先用自写代码读 chunk，再用 QJsonDocument 解析 JSON 里的 mesh 和 accessor，避免引入额外的 CMake 依赖。
4.1 GLB 文件结构：header、chunk 与 padding
GLB 的头部固定 12 字节，magic 是0x46546C67，对应 ASCII 的glTF，version 是 2，length 是整个文件长度。header 之后就是 chunk，每个 chunk 前 8 字节是 chunk 长度和 chunk 类型。JSON chunk 的类型是0x4E4F534A，BIN chunk 的类型是0x004E4942。需要注意的是 chunk 长度按 4 字节对齐，JSON chunk 末尾可能补0x20空格，解析 JSON 前要先trimmed()。
我用这张表记结构，避免解析时算错偏移：
| 偏移 | 长度 | 含义 |
|---|---|---|
| 0 | 4 | magic：0x46546C67 |
| 4 | 4 | version：通常为 2 |
| 8 | 4 | 整个 GLB 文件长度 |
| 12 | 4 | 第一个 chunk 的长度 |
| 16 | 4 | 第一个 chunk 类型 |
| 20 | chunkLen | 第一个 chunk 的数据 |
4.2 解析 chunk 的代码：QFile 一次读完
GLB 文件不适合边读边解析，文件不大时直接全部读进内存最省事：
bool readGlbChunks(const QString &path, QByteArray &jsonChunk, QByteArray &binChunk) { QFile file(path); if (!file.open(QIODevice::ReadOnly)) return false; const QByteArray data = file.readAll(); if (data.size() < 20) return false; quint32 magic = 0; quint32 version = 0; memcpy(&magic, data.constData(), 4); memcpy(&version, data.constData() + 4, 4); if (magic != 0x46546C67 || version != 2) return false; quint32 chunkLength = 0; quint32 chunkType = 0; int offset = 12; while (offset + 8 <= data.size()) { memcpy(&chunkLength, data.constData() + offset, 4); memcpy(&chunkType, data.constData() + offset + 4, 4); offset += 8; if (offset + int(chunkLength) > data.size()) break; if (chunkType == 0x4E4F534A) { jsonChunk = data.mid(offset, chunkLength).trimmed(); } else if (chunkType == 0x004E4942) { binChunk = data.mid(offset, chunkLength); } offset += int(chunkLength); } return !jsonChunk.isEmpty() && !binChunk.isEmpty(); }memcpy比直接强转指针更安全，避免对齐问题。循环里每次读完一个 chunk 后要把 offset 加上 chunkLength，否则下一个 chunk 读错位置。JSON chunk 的trimmed()是把 padding 空格清掉，BIN chunk 不能 trim，里面有二进制数据，只保留原始字节。
4.3 accessor、bufferView、buffer 的三层映射
GLB 的几何数据定位有严格的层级：buffer 是 BIN chunk 里的整块数据；bufferView 是 buffer 中的一段区间，带 byteOffset 和 byteLength；accessor 是 bufferView 中某个属性的具体语义，比如 POSITION、NORMAL、TEXCOORD_0。拿到一个 mesh primitive，要先从 attributes 里取 POSITION 的 accessor 索引，再通过 accessor 的 bufferView 索引找到 bufferView，最后用 byteOffset 在 BIN chunk 里截数据。
核心读取逻辑是这样的：
QJsonObject root = QJsonDocument::fromJson(jsonChunk).object(); QJsonArray accessors = root.value("accessors").toArray(); QJsonArray bufferViews = root.value("bufferViews").toArray(); QJsonArray meshes = root.value("meshes").toArray(); QJsonObject mesh = meshes.first().toObject(); QJsonArray primitives = mesh.value("primitives").toArray(); QJsonObject primitive = primitives.first().toObject(); int posAccessorIndex = primitive.value("attributes").toObject() .value("POSITION").toInt(-1); QJsonObject accessor = accessors.at(posAccessorIndex).toObject(); int bufferViewIndex = accessor.value("bufferView").toInt(-1); QJsonObject bufferView = bufferViews.at(bufferViewIndex).toObject(); int byteOffset = bufferView.value("byteOffset").toInt(0); int byteLength = bufferView.value("byteLength").toInt(0); const char *binPtr = binChunk.constData() + byteOffset; QVector<QVector3D> positions; for (int i = 0; i < accessor.value("count").toInt(); ++i) { const float *p = reinterpret_cast<const float *>(binPtr + i * 12); positions.append(QVector3D(p[0], p[1], p[2])); }POSITION的 componentType 是5126，也就是 GL_FLOAT，type 是 VEC3，所以每个顶点固定 12 字节。如果 GLB 用了交错布局，bufferView 里会多一个byteStride，读取时要用 stride 代替 12。这个字段最容易漏，漏了之后模型会变成满屏噪点，而且点位错得很规律。
5. 避坑记录：模型加载常见的五类翻车现场
加载 3D 模型的问题不像业务逻辑那样有明确的报错文本，很多时候就是黑屏、花屏、躺倒。下面这五类是我在实际调试里遇到最高频的问题，每一条都按现象、原因、解决写清楚。
5.1 全黑或空窗口：先怀疑着色器和深度测试
现象：程序正常启动，窗口也不报错，但渲染区域什么都没有，或者只有一个黑底。
原因：第一是 shader 编译链接失败，addShaderFromSourceFile返回 true 不代表 link 成功；第二是没有开深度测试，模型前后关系错乱；第三是 glDrawElements 的索引缓冲没有绑定到当前 VAO。
解决：在 initializeGL 里把 program log 打出来，if (!m_program.isLinked()) qWarning() << m_program.log();，同时加上glEnable(GL_DEPTH_TEST)。绘制前用glGetError()清一遍错误标志，绘制后立刻查一次返回值，如果出现GL_INVALID_OPERATION，优先检查 VAO 和 EBO 的绑定状态。
5.2 模型撕裂、乱序：查索引类型和基址偏移
现象：模型轮廓能看出来，但三角形连接完全不对，像是被随机切碎；或者模型一部分正常，另一部分花掉。
原因：最常见的是顶点数超过 65535，但 glDrawElements 还在用 GL_UNSIGNED_SHORT，导致索引被截断；其次是 EBO 上传时最后一个参数传了顶点数组指针而不是索引数据，或者在多个 VBO 混用时 offset 算错。
解决：根据顶点数量选择索引类型，vertices.size() > 65535就用 GL_UNSIGNED_INT，否则用 GL_UNSIGNED_SHORT。绘制代码里 glDrawElements 的最后一个参数含义是索引字节偏移，不是索引数组指针，如果你用的是单个 EBO，且索引从 0 开始，这个参数传nullptr是对的；如果同一个 EBO 里存了两段索引，要传实际的字节偏移。
5.3 纹理上下颠倒：OBJ 的 vt 和 glTF 的 uv 约定不是一回事
现象：模型几何正常，但贴上贴图后上下翻转，或者左右镜像。
原因：OBJ 的vt通常以图片左上角为原点，而 OpenGL 的纹理坐标原点约定在左下角；glTF 2.0 的 uv 约定又与部分导出器不一致。同一个 uv.y 直接塞给不同格式，出来的方向不可能都正确。
解决：把 uv 翻转做成加载器的一个开关，不要写在 shader 里。解析 OBJ 时如果发现贴图颠倒，就执行一次uv.y = 1.0f - uv.y；解析 GLB 时保持原样，等第一次贴图出来后再决定要不要翻。这个开关的好处是不同来源的模型可以单独调整，不会为了修 A 格式把 B 格式弄坏。
5.4 模型整体躺倒：坐标系转换不是玄学，是模型矩阵的事
现象：模型加载成功，旋转交互也正常，但模型是躺着的，比如原本应该是建筑立面，结果变成屋顶朝上。
原因：很多建模软件导出 OBJ 时用 Z-up 坐标系，OpenGL 和 glTF 习惯用 Y-up；GIS 转换出来的模型还可能带着 ENU（东北天）坐标系，和渲染坐标系差一个旋转。改顶点坐标是错误做法，正确的做法是改模型矩阵。
解决：加载完成后先打印包围盒，通过模型在 X/Y/Z 三个轴上的尺寸判断它当前是 Z-up 还是 Y-up。如果是 Z-up 转 Y-up，乘一个绕 X 轴旋转-90度的矩阵：
QMatrix4x4 model; model.rotate(-90.0f, 1.0f, 0.0f, 0.0f);这个旋转只作用在模型矩阵上，顶点数据保持原样，后续加缩放和位移都叠加在同一个矩阵上，不会污染原始模型。
5.5 渲染慢且 renderer 显示 llvmpipe：确认你在用硬件 OpenGL
现象：窗口能渲染，但旋转视角非常卡，打印 OpenGL 的 renderer 字符串，看到OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)。
原因：这说明 Qt 没有拿到硬件 GPU 驱动，OpenGL 调用全部落到 Mesa 软件渲染。常见于远程桌面、虚拟机、服务器环境，或者显卡驱动只支持 OpenGL 1.x，Qt 自动降级到软件渲染。
解决：先用glGetString(GL_RENDERER)确认自己到底在用谁渲染。本机调试优先更新显卡驱动；虚拟机里要看虚拟显卡是否透传；如果只是做加载逻辑验证，软件渲染也能跑，但别拿它评估性能。判断性能问题时，第一件事永远是确认 renderer 不是 llvmpipe。
6. 让加载过程可验证：包围盒打印、线框调试与模型矩阵校验
模型加载器最怕的不是报错，而是“看起来好像对了”。我会在加载完数据后立刻做三件事：打印顶点数、索引数、包围盒；用线框模式渲染一次；再把模型矩阵设成单位阵检查朝向。这三步能挡住大部分问题。
包围盒的计算很简单，遍历所有顶点，维护 min 和 max，然后打印尺寸。比如一个 OBJ 的包围盒是[-100, -100, 0]到[100, 100, 200]，那它的 Z 轴明显是主要高度轴，当前数据大概率是 Z-up。看到这样的信息，就应该在代码层面对模型矩阵做一次旋转，而不是等渲染出来再猜。
线框调试我一般这样写：
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); drawModel(); glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);线框模式下能很直观地看出三角形是不是接错了、有没有破面、法线方向是否一致。如果一个模型线框正常但填充后某些面缺失，基本就是绕序问题，检查顶点索引顺序和glFrontFace(GL_CCW)的设置。
从那以后，我每接入一种新模型格式，都强制走一遍这个流程：先打印包围盒和面数，再线框渲染，最后才开纹理。这套检查习惯救过我很多次，尤其是拿到来源不明的 GLB 时，一眼就能看出坐标系和顶点数据是否正常。希望帮到你。
本文还有配套的精品资源，点击获取
