Assimp加载模型纹理丢失主因是路径解析失败、嵌入纹理未提取、UV未翻转、多纹理绑定错位及TBN矩阵失效；需结合绝对路径拼接、aiTexture数据提取、stbi_set_flip_vertically_on_load(true)、显式binding和TBN同步变换解决。
加载模型时纹理路径没被正确解析
很多初学者用 Assimp 加载模型（比如 .obj），发现模型渲染出来是纯色或黑块——根本不是纹理缺失，而是 Assimp 读到的纹理路径是相对路径（如 "textures/brick.jpg"），而程序当前工作目录不是模型所在目录，导致 fopen 或 stbi_load 返回 nullptr。
- 用
Assimp::Importer::GetLoadedFile()获取模型绝对路径，再用std::filesystem::path拼接纹理路径（C++17+） - 或在加载前调用
importer.SetPropertyInteger(AI_CONFIG_IMPORT_USE_FILENAME_AS_TEXTURE_NAME, 1)，强制让纹理名只取文件名，再手动按约定规则查找（如统一放assets/textures/下） - 检查
aiMaterial::GetTexture返回的aiString是否为空，不为空才尝试加载；否则跳过该纹理槽位
纹理坐标翻转导致贴图上下颠倒
OpenGL 的纹理坐标原点在左下角，而大多数图像格式（PNG/JPEG）和建模软件（Blender、Maya）默认以左上为原点。直接加载后，纹理会垂直翻转——你看到的砖墙可能“倒着铺”。
- 加载图像前调用
stbi_set_flip_vertically_on_load(true)（stb_image.h提供） - 如果用了其他图像库（如 DevIL、SOIL），查对应 API 是否有类似开关；SOIL2 默认已翻转，但旧版 SOIL 没有
- 不要在顶点着色器里手动
uv.y = 1.0 - uv.y—— 这会让法线贴图、PBR 粗糙度图等所有通道都翻转，破坏物理一致性
多纹理绑定时 sampler2D 对应错 slot
当模型带漫反射贴图（albedo）、法线贴图（normal）、金属度贴图（metallic）等多个纹理时，容易出现“法线贴图显示成颜色”或“金属度全白”——本质是着色器里 sampler2D 变量绑到了错误的纹理单元（texture unit）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 在着色器中显式指定 binding：例如
layout(binding = 0) uniform sampler2D uAlbedo;，然后 CPU 端用glBindTextureUnit(0, albedoTexID)（OpenGL 4.5+） - 若用传统方式，必须保证
glActiveTexture(GL_TEXTURE0 + i)和glUniform1i(loc, i)中的i严格一致；常见错误是循环里i从 1 开始，但 shader 里uAlbedo绑在 slot 0 - 检查每个纹理是否真的生成了非零 ID：
glIsTexture(texID)返回GL_TRUE；否则glBindTexture会静默失败
模型旋转后纹理拉伸变形
加载的模型顶点法线、切线、纹理坐标都没问题，但绕 Y 轴旋转后，砖墙纹理开始横向拉长——这是纹理坐标的 Tangent 和 Bitangent 向量没随模型变换同步更新，导致 TBN 矩阵失效，法线贴图计算出错。
立即学习“C++免费学习笔记（深入）”；
- 确保顶点着色器中对
inTangent和inBitangent应用与顶点相同的模型变换（即乘mat3(modelMatrix)，不是mat4） - 若使用法线贴图，必须在 CPU 或着色器中重建 TBN 矩阵；仅传入
normal不够——normal是表面朝向，tangent才定义 UV 如何映射到空间 - 验证方法：临时把片元着色器输出设为
normalize(tbn * normal)，看是否随旋转保持稳定；若颜色乱跳，说明 TBN 构建或变换有误
实际跑通的关键不在“怎么画”，而在“怎么确认每一步没 silently fail”：纹理 ID 是否有效、采样器绑定是否匹配、UV 是否真正落在 [0,1] 区间、TBN 是否正交归一——这些地方没有报错，只有黑屏或奇怪的条纹。
