OBJ文件不支持切线数据，需自行计算；解析时须容错处理vn行格式、正确拆分f行索引、归一化法向量、按UV手性与镜像校正切线方向。
OBJ文件里根本没有切线（tangent）数据
Wavefront OBJ 格式规范本身不定义 tangent、binormal 或 bitangent 属性。你看到的所谓“切线”，几乎肯定是模型导出时由 DCC 工具（如 Blender、Maya）额外写入的非标准扩展行，比如：
vtan 0.999 0.001 0.002或
usemtl 后跟自定义注释。标准 OBJ 只支持 v（顶点）、vn（法向量）、vt（UV）和 f（面）。解析前先用文本编辑器打开 OBJ 文件确认是否存在这类自定义行——没有就别硬找，得自己算。
解析 vn 行必须严格匹配空格与浮点格式
OBJ 的 vn 行形如 vn -0.4213 0.8765 -0.2341，但实际文件中常混入制表符、多余空格或科学计数法（如 vn 1.23e-02 -4.56E+01 0.0）。用 std::stringstream 直接 >> 读取易失败；更稳的方式是：
- 用
std::string::find_first_of(" \t")跳过前缀，再用std::stof()配合std::string::substr()分段提取 - 对每个字段做容错：跳过空字符串、忽略非数字前缀（如
vn#1）、处理inf/nan（虽少见但导出器可能写入） - 法向量未归一化？OBJ 不保证单位长度，
vn行只存方向，渲染前务必调用glm::normalize()或手写归一化
面索引（f 行）里的 // 和 / 区分决定法向量能否对齐
f 1/2/3 4/5/6 7/8/9 表示顶点/UV/法向量三元组；f 1//3 4//6 7//9 表示顶点//法向量（UV 缺失）；而 f 1 4 7 则完全没带法向量索引。关键点：
- 必须按
/出现次数动态拆分字段，不能简单按空格切分——否则f 1/2/3/4（非法但偶有出现）会崩 - 法向量索引是 1-based，且可能越界（导出器 bug），读取前需检查是否在
vn容器 size 范围内 - 同一个顶点被多个面共用时，若各面指定不同
vn索引（即平滑组分裂），必须拆分为多个顶点副本——否则法向量会错位
切线得自己算，且依赖顶点布局与 UV 方向
真实项目中，切线几乎总是运行时从顶点位置 v 和 UV 坐标 vt 推导。核心是 MikkTSpace 算法（工业标准），但手动实现要注意：
立即学习“C++免费学习笔记（深入）”；
- 必须使用面内三个顶点构成的三角形局部坐标系，单靠顶点和 UV 点不够——要算
dPdu、dPdv，再正交化 - OBJ 中 UV 的
v轴默认朝上（OpenGL 风格），但某些导出器翻转了它（DirectX 风格），会导致切线朝向相反；检查vt行中第二分量是否随几何“下”走来判断 - 若模型含镜像 UV（UV 坐标行列式为负），切线需翻转符号，否则法线贴图会反色；这一步常被跳过，结果就是部分表面高光错乱
真正麻烦的不是解析，而是 OBJ 没有元数据说明其 UV 手性、法向量是否已平滑、甚至面是否为逆时针。这些都得靠启发式检测或用户配置补全。
