简介：三维模型obj格式解析源码适用于计算机图形学入门者与C++开发者，帮助理解obj文件结构并掌握从文本读取到内存数据组织的完整流程。资源以Visual Studio 2013工程形式提供，核心包括ObjLoader.cpp/h源文件、Timer.h以及cube.obj、woman22.obj、人体基本模型.obj等测试模型，共27个文件，压缩包约17.14MB，除源代码和样例模型外还包含编译生成的exe、pdb、ilk等调试文件，可直接运行或断点调试。解析思路覆盖顶点、纹理坐标、法线和面索引的读取，采用面向对象方式封装，便于扩展为渲染管线的前置模块。已有857人学习，适合想通过动手实践理解三维模型加载机制的读者，可作为游戏开发或图形学课程设计的参考资料。

1. 三维模型格式 obj 文件解析源码到底在解决什么问题

拿到一个 obj 文件却没法渲染，这是很多三维开发者的第一道坎：建模软件导出的 obj 是纯文本，里面混杂着顶点、贴图坐标、法线、材质引用，而 OpenGL、Cesium 这类渲染器只吃数组和索引。所谓“三维模型格式 obj 文件解析源码”，就是把这种文本描述翻译成内存里的顶点缓冲与索引缓冲，供后续加载、归一化、坐标转换和绘制使用。它适用于写模型转换工具、做离线资源管道，或者需要在嵌入式环境里不依赖第三方库直接加载 obj 的人。下面我会用一个可运行的 Python 解析器为主线，把格式细节、参数陷阱和常见翻车点一次讲清楚。

2. 从几何到拓扑：obj 格式的结构拆解与选型理由

2.1 顶点、法线、纹理坐标与面索引：obj 的四种核心记录

obj 文件本质是一种“文档结构化解析”场景：每一行以关键字开头，后面跟着用空格分隔的数值。你需要关心的核心记录只有四类，下面这张表概括了它们的字段与含义：

f 行里每个索引用/分隔，例如f 1/1/1 2/2/2 3/3/3表示一个三角形，三个位置、纹理、法线的索引一一对应。索引从 1 开始，0 是非法的。如果某个值缺失，比如f 1//3表示只有位置和法线，没有纹理坐标。

除了这四类，你还会看到 o、g、s、usemtl、mtllib。o 是对象名，g 是组名，s 是平滑组，usemtl 切换材质，mtllib 引入外部材质库文件。对于纯几何解析，前三者可以忽略，但 mtllib 和 usemtl 在你要支持贴图渲染时必须保留，否则无法建立面和材质的映射。

2.2 为什么选择自己写解析器而不是直接用第三方库

常见的现成方案有 Assimp、trimesh、pywavefront，它们能省下大量工作。我一般会在三种场景下坚持自己写：一是目标平台是嵌入式或浏览器，不能引入重依赖；二是你需要的不是完整模型，而是把 obj 的几何数据抽取出来喂给自研引擎；三是需要精确控制内存布局，比如把顶点直接写成 OpenGL VBO 所需的扁平数组。

自己写解析器能拿回主动权，代价是要处理很多边界。obj 看起来简单，但它的语法允许负索引、允许多边形超过三条边、允许 vt 只有一位数。这些在第三方库中已经被处理掉，在自制解析器里就成了潜在的坑。选型时我会先问自己：我要解析的 obj 是自己导出还是外部用户上传？外部上传的场景必须按规范全量支持；内部工具链则可以约定导出的子集，解析器可以激进简化。

另外要注意的是，obj 格式本身没有定义二进制版本，所有数据都是文本。文本解析的性能瓶颈在字符串转换，而不是 I/O。所以如果你只是做一次性转换，Python 足够；如果要运行时热加载，我会把解析结果序列化成自定义二进制格式（后面第 6 章会讲）。这决定了你的解析器架构要从一开始就区分“离线解析”和“运行时加载”两条路径。

2.3 把对象模型映射到内存结构：顶点缓冲与索引缓冲

渲染引擎需要的数据结构通常是两个数组：顶点缓冲（vertex buffer）和索引缓冲（index buffer）。顶点缓冲里放的是不重复的顶点，每个顶点由位置、纹理坐标、法线拼成；索引缓冲里三个一组的整数描述三角形。obj 的 f 行里写的索引是“原始数据”的索引，不能直接作为渲染索引，因为同一个位置可能被不同面引用，而且同一个位置可能配不同的纹理坐标和法线。

举个例子：一个立方体有 8 个角，但每个角在三个面上对应的 UV 不同，所以渲染顶点数量会远大于 8。正确的做法是在解析 f 时，把 (vi, ti, ni) 三元组当作一个“渲染顶点”的 key，做去重后分配新的索引。这样，你的解析器输出应该是：

• positions 数组：float 列表，来自 v
• texcoords 数组：float 列表，来自 vt
• normals 数组：float 列表，来自 vn
• faces 列表：每个元素是若干“索引三元组”的集合

在构建渲染网格时，遍历 faces，把每个三元组映射到渲染顶点数组的下标，同时生成索引列表。这个过程看似简单，但顺序很重要：必须先知道当前已读取的顶点总数，才能处理负索引。这也是为什么我推荐流式解析而不是分两遍读文件。

3. 用 Python 写一个最小可用的 obj 解析器：从文件流到顶点数组

3.1 按行读取与预处理：处理注释、空行和换行符的坑

打开文件的常规姿势是逐行读取，不要一次read().splitlines()，因为大文件会让内存翻倍。每行先strip()去掉首尾空白，然后跳过空行和以 # 开头的注释行。注意 Windows 导出的 obj 文件通常用\r\n，strip()会把它处理干净；但如果你用的是split()按空白切分，其实不strip()问题也不大。真正的坑是文件编码：很多建模软件导出 obj 时用本地编码写入材质名或组名，如果里面有中文，直接用utf-8打开会报错。我的做法是errors='ignore'忽略非法字符，几何数据是 ASCII，材质名乱码影响不大。

def read_obj_lines(filepath): vertices = [] texcoords = [] normals = [] faces = [] with open(filepath, 'r', encoding='utf-8', errors='ignore') as f: for raw_line in f: line = raw_line.strip() if not line or line.startswith('#'): continue parts = line.split() keyword = parts[0] if keyword == 'v': vertices.append([float(x) for x in parts[1:4]]) elif keyword == 'vt': # 有些 obj 只写一个 u，这里按长度兼容 if len(parts) >= 3: texcoords.append([float(parts[1]), float(parts[2])]) else: texcoords.append([float(parts[1]), 0.0]) elif keyword == 'vn': normals.append([float(x) for x in parts[1:4]]) elif keyword == 'f': faces.append(parts[1:]) return vertices, texcoords, normals, faces

这个函数初始化了四个列表，遇到 v 时把坐标转成 float 放到 vertices；vt 只取前两个分量，缺省补 0。faces 这里先保存原始 token 字符串，没有立即解析，原因是为了保持代码分步易懂。但在正式处理负索引时，这种延后解析会要求你在解析 f 的瞬间记录当时各类数据的长度。

换句话说，上面的代码只适合“文件里 v 全部出现在 f 之前”的常见情况。如果遇到导出器把 f 穿插在 v 中间（少见但存在），负索引就会算错。所以后面我会给出一个流式版本，把 faces 的解析也提前，利用当前计数。

3.2 解析 v / vn / vt / f 四类记录并生成索引缓冲

解析 f 行的核心是一个 token 解析函数。obj 的索引可以是负数：-1 表示最后一个已读取的顶点，-2 表示倒数第二个。因此，你必须在读取到该 f 行时知道当前总顶点数、纹理坐标数和法线数。下面的代码把 token 按/拆开，并处理负索引：

def parse_face_token(token, current_counts): pieces = token.split('/') vi = int(pieces[0]) ti = int(pieces[1]) if len(pieces) > 1 and pieces[1] != '' else 0 ni = int(pieces[2]) if len(pieces) > 2 and pieces[2] != '' else 0 if vi < 0: vi = current_counts['v'] + vi + 1 if ti < 0: ti = current_counts['vt'] + ti + 1 if ni < 0: ni = current_counts['vn'] + ni + 1 return vi, ti, ni

current_counts是在读取到 f 那一行时，文件流中已经出现的 v、vt、vn 条数。这里缺失的 ti 和 ni 用 0 表示，因为 obj 索引没有 0，0 正好可以做空标记。注意负索引转正后，最小值是 1，所以后续用vi - 1访问数组下标。

接下来是生成渲染几何的核心函数。它遍历 faces 中的原始 token，对每个三元组做去重，然后为每个面做三角化：

def build_render_geometry(vertices, texcoords, normals, faces, counts): render_vertices = [] index_map = {} indices = [] for face in faces: face_indices = [] for token in face: vi, ti, ni = parse_face_token(token, counts) key = (vi, ti, ni) if key not in index_map: vx, vy, vz = vertices[vi - 1] if ti: tx, ty = texcoords[ti - 1] else: tx, ty = 0.0, 0.0 if ni: nx, ny, nz = normals[ni - 1] else: nx, ny, nz = 0.0, 0.0, 1.0 index_map[key] = len(render_vertices) render_vertices.append([vx, vy, vz, tx, ty, nx, ny, nz]) face_indices.append(index_map[key]) if len(face_indices) == 3: indices.extend(face_indices) elif len(face_indices) == 4: # 四边形拆成两个三角形：0,1,2 和 0,2,3 indices.extend([face_indices[0], face_indices[1], face_indices[2]]) indices.extend([face_indices[0], face_indices[2], face_indices[3]]) else: # 多边形先用扇形拆解，凹多边形会出错 for i in range(1, len(face_indices) - 1): indices.extend([face_indices[0], face_indices[i], face_indices[i + 1]]) return render_vertices, indices

逻辑说明：这里对四边形做了特殊处理，因为四边形是最常见的非三角形面，而 GPU 只画三角形，所以四边形必须拆成两个三角形。拆分顺序 0-1-2 和 0-2-3 能保证两个三角形共享边 0-2，这样不会出现裂缝。对大于四边的多边形，代码用扇形方式拆解（以第一个顶点为公共点），这只适合凸多边形。凹多边形拆出来会和其他面重叠或穿插，这是后面避坑章的重点之一。

参数方面，render_vertices的每个元素是长度为 7 的列表，布局是 [x, y, z, tx, ty, nx, ny, nz]，这个布局直接对应后续glBufferData的 stride。如果你要接入 Cesium 或 WebGL，把它改成平面数组即可。默认法线给 (0,0,1) 是应急做法，最好在解析完所有面之后统一点算面法线再赋给顶点，否则光照效果会非常奇怪。

3.3 归档到内存：如何导出为字典或 dataclass

解析器输出的结构应该方便上层使用。我习惯用一个 dataclass 封装，并提供两个导出方法：一个是返回扁平 float 数组，一个是返回字典方便调试。

from dataclasses import dataclass, field from typing import List, Tuple @dataclass class ObjModel: vertices: List[float] = field(default_factory=list) # 扁平化 [x,y,z,tx,ty,nx,ny,nz,...] indices: List[int] = field(default_factory=list) object_names: List[str] = field(default_factory=list) material_libraries: List[str] = field(default_factory=list) def to_flat_array(self) -> List[float]: return self.vertices def to_dict(self) -> dict: return { 'vertex_count': len(self.vertices) // 7, 'index_count': len(self.indices), 'vertex_buffer': self.vertices, 'index_buffer': self.indices, 'objects': self.object_names, 'mtllib': self.material_libraries, }

把顶点扁平化的意义在于大多数图形 API 都不接受嵌套数组。OpenGL 的glBufferData需要连续内存，WebGL 的Float32Array可以直接从数组构建，Cesium 的GeometryAttribute也需要ComponentDatatype.FLOAT的 typed array。所以to_flat_array才是真正投喂给渲染层的接口。

这里有一个容易被忽略的点：如果 obj 里有多个 o 或 g 分组，且你希望这些分组像节点一样可以独立移动，就不要把所有顶点合并成一个 buffer。正确做法是每个分组单独生成一个ObjModel，或者记录顶点范围的起始和结束。很多解析报错都源于把所有面混在一起后，分组信息就丢了。因此object_names列表的索引需要和顶点范围对应，我通常会在解析 f 时记录当前o的名字和当前已生成的顶点偏移，这样上层的场景树才能区分模型部件。

4. 解析精度的三个必调参数与渲染对接：指数组、归一化与坐标系

4.1 索引从 1 开始：obj 的负索引与相对偏移

obj 的 index 和大多数编程语言不一样，它从 1 开始计数，0 是非法值。新手最容易翻车的点是负索引：f -1不是报错，而是表示“当前文件流中最后一个顶点”。这种相对索引在旧版 3ds Max 导出器里很常见。它带来的解析规则是：你不能把整个文件读进来，数完所有顶点之后再处理 f，而必须在读到 f 行时，用当时的顶点计数去换算负索引。

举例说明：文件前几行写了两个 v，然后有一个f -1 -2 1，那么 -1 对应索引 2，-2 对应索引 1，1 还是索引 1。如果换成先读完全部 v 再解析 f（比如文件后面还有 100 个 v），负索引解析出来的就是 100 和 99，整个面就扭曲了。因此，流式处理不是性能优化，而是正确性要求。

下面这个简化的流式循环体现了正确的计数方式：

def parse_obj_streaming(filepath): vertices, texcoords, normals = [], [], [] faces = [] counts = {'v': 0, 'vt': 0, 'vn': 0} with open(filepath, 'r', encoding='utf-8', errors='ignore') as f: for raw_line in f: parts = raw_line.strip().split() if not parts: continue if parts[0] == 'v': vertices.append([float(x) for x in parts[1:4]]) counts['v'] += 1 elif parts[0] == 'vt': texcoords.append([float(parts[1]), float(parts[2]) if len(parts) > 2 else 0.0]) counts['vt'] += 1 elif parts[0] == 'vn': normals.append([float(x) for x in parts[1:4]]) counts['vn'] += 1 elif parts[0] == 'f': # 这一行里的负索引基于当前的 counts parsed = [parse_face_token(t, counts) for t in parts[1:]] faces.append(parsed) return vertices, texcoords, normals, faces

注意counts在遇到 f 行时已经包含了此前所有 v/vt/vn 的增量，这正是负索引解析的正确基准。如果你沿用“先收全集再统一处理”的思路，就必须额外记录每一条 f 出现的行号，再去原始文件里找当时的计数，复杂度反而更高。

4.2 归一化缩放与中心化：把模型搬进渲染场景

obj 的坐标单位完全由建模时的场景决定，可能是一个边长 0.001 的零件，也可能是一个 40000 公里的地形块。直接丢进渲染器会出现两个问题：一是模型在视锥之外，二是相机参数（近裁剪面、远裁剪面）很难匹配。所以解析之后通常要做一次归一化，把模型平移到原点并缩放到单位尺寸。

def normalize_geometry(render_vertices): min_x = min(v[0] for v in render_vertices) max_x = max(v[0] for v in render_vertices) min_y = min(v[1] for v in render_vertices) max_y = max(v[1] for v in render_vertices) min_z = min(v[2] for v in render_vertices) max_z = max(v[2] for v in render_vertices) cx = (min_x + max_x) * 0.5 cy = (min_y + max_y) * 0.5 cz = (min_z + max_z) * 0.5 size_x = max_x - min_x size_y = max_y - min_y size_z = max_z - min_z scale = 1.0 / max(size_x, size_y, size_z) for v in render_vertices: v[0] = (v[0] - cx) * scale v[1] = (v[1] - cy) * scale v[2] = (v[2] - cz) * scale return scale, (cx, cy, cz)

返回的scale和中心点必须保留下来，因为你后续要在场景中把这些变换还原回去。比如一个 obj 是从卫星图生成三维模型的倾斜摄影数据，坐标是带地理参考的平面坐标，你千万不要直接归一化，否则会把模型从实际地理位置“抠”出来。正确做法是先判断文件有没有附带 .prj、.tfw 或 geo 信息，再决定是否做归一化。我见过的做法是：解析器先检查是否存在 mtllib 之外的空间参考文件，有就跳过归一化，直接走地理坐标转换流程。

4.3 对接 OpenGL / Cesium 时的坐标轴转换与三角化

obj 的官方坐标系是右手系、Y 轴向上，OpenGL 也是 Y 轴向上，所以桌面渲染可以直接用。但 Web 端常见的 Cesium 用的是 Z 轴向上（东北天坐标系），加载 obj 模型时需要做轴转换：把 Y 轴数据搬给 Z 轴，Z 轴数据按需要取负。

具体到代码，对每个顶点执行[x, z, -y]还是[x, z, y]取决于你的模型是朝上还是朝下。这个值基本是试出来的，我第一次做的时候把法线做了同样的变换，结果光照全反，最后发现是绕序问题。法线变换时必须使用逆转置矩阵，而不是直接拿坐标变换矩阵套。不过对于刚体旋转（没有缩放）的轴转换，直接换分量不会错；一旦解析脚本里带了非均匀缩放，法线就会歪。

三角化方面，obj 允许任意的多边形面。Cesium 加载 obj 模型时，底层几何 API 大多按三角形处理。你的解析器必须把多边形拆成三角形。前面代码已经处理了三角形、四边形、多边形。但凹多边形的 fan 切分会出错，这是最隐蔽的坑。可靠的方案是使用 ear clipping 算法，或者交给triangle这类库。在自研解析器中，我通常约定：如果面顶点数超过 4，且无法确认是凸多边形，就直接报错，而不是默默生成坏面。这样可以逼迫上游工具预先三角化。

5. obj 解析源码中的常见崩溃与避坑清单

5.1 现象：解析后模型缺失一半面，渲染结果只有部分三角形

原因：最常见的不是 f 行丢数据，而是多边形拆分错误。用扇形方式处理凹四边形或多边形时，会产生自相交的三角形，这些三角形在渲染时因为背面剔除被丢弃，视觉上就像模型缺了一半。

解决：在解析阶段记录每个面的顶点数，超过三个顶点时先做凸性检测。检测方法是依次计算相邻边的叉积，如果符号不一致就是凹多边形。对于凹多边形，不要自己硬拆，调用mapbox_earcut库（Python 和 JS 都有实现），它能处理带洞多边形。改完之后，用一个小测试模型验证：构造一个 L 形平面，只有 6 个顶点，看解析后三角形是否填满整个 L 形。

5.2 现象：纹理错位或 UV 颠倒，贴图上下颠倒

原因：obj 的 vt 坐标原点在左下角，v 轴向上增长；而 OpenGL 的纹理坐标约定是原点在左下，DirectX 和 WebGL 的很多图片解码器则默认原点在左上。如果你的渲染管线用glTexImage2D+GL_UNSIGNED_BYTE加载图片，并且没有设置UNPACK_FLIP_Y_WEBGL，那么 UV 的 v 分量需要翻转：new_v = 1.0 - old_v。

解决：在解析器中增加一个开关flip_uv_v，默认开启。注意有些建模软件导出的 obj 已经做了翻转，这时再翻一层就会上下颠倒。我的经验是：先在解析器里固定用1.0 - v输出，渲染一张带文字的贴图验证；如果颠倒，就把开关关掉。这不是逻辑问题，而是数据来源的约定问题，没有通用正确答案。另外，vt 缺失时我给 0.0，但默认 UV 应该给 (0.0, 0.0) 还是 (0.5, 0.5) 取决于你的材质语义，我建议给 (0.0, 0.0) 并防止采样器越界。

5.3 现象：Cesium 加载 obj 模型后黑面或闪烁

原因：这通常是面绕序不一致导致背面剔除错误。obj 格式没有规定三角形顶点必须逆时针排列，建模软件导出的数据有的顺时针有的逆时针。Cesium 的材质系统默认启用背面剔除，绕序错误的面被剔掉，只剩背面黑面。

解决：在解析时统一绕序。遍历每个三角形，计算法线方向，如果法线指向视线背面，则交换第二个和第三个顶点索引。具体做法是：计算cross(b - a, c - a)的法线，然后和顶点法线或相邻面的平均法线点乘，如果点乘为负就交换b和c。代码示意：

def fix_winding(tri_indices, render_vertices): a = render_vertices[tri_indices[0]] b = render_vertices[tri_indices[1]] c = render_vertices[tri_indices[2]] ux, uy, uz = b[0]-a[0], b[1]-a[1], b[2]-a[2] vx, vy, vz = c[0]-a[0], c[1]-a[1], c[2]-a[2] nx = uy * vz - uz * vy ny = uz * vx - ux * vz nz = ux * vy - uy * vx # 与预设法线比较，这里假设 obj 法线方向是原始设计意图 if nx * a[5] + ny * a[6] + nz * a[7] < 0: tri_indices[1], tri_indices[2] = tri_indices[2], tri_indices[1] return tri_indices

注意这段代码需要在索引缓冲生成之后、送入 GPU 之前执行。由于它依赖顶点法线，如果模型没有 vn，则需要先从顶点位置计算面法线兜底。这个操作是逐三角形消耗性能的，离线解析时无所谓，运行时做会比较吃力。

5.4 现象：内存暴涨与字符串解析性能瓶颈

原因：很多自制解析器为了图方便，先把 f 行按 token 切分成字符串数组，再在下一遍转成整数。一个 500MB 的 obj 大约有 2000 万行，字符串数组本身就能占用几个 GB。而且用dict存(vi, ti, ni)元组时，每个元组都是独立对象，内存开销进一步放大。

解决：一是不要在读取阶段保留原始 token，直接在当前行内解析完，丢弃字符串；二是把去重 key 从元组改成单个整数。可以用位运算把三个索引打包成一个 64 位整数：key = (vi << 40) | (ti << 20) | ni，在 Python 里整数对象比元组省内存。如果模型顶点数超过 100 万，也可以把index_map换成一个array('q')加哈希表，但收益不大。更彻底的做法是跳过index_map，直接用排序去重：

# 收集所有唯一的 (vi, ti, ni) 组合 unique_keys = set(face_tokens) sorted_keys = sorted(unique_keys) key_to_index = {k: i for i, k in enumerate(sorted_keys)}

这种做法的优势是你可以先收集所有组合，再一次性分配渲染顶点，避免在循环中反复 resize 列表。实测对 10 万面模型，用元组 set 比逐个插入 dict 快 30% 左右，内存也更可控。

5.5 现象：解析报错提示行号对不上，问题出在 mtllib 文件缺失

原因：obj 的材质库是外部文件，很多解析器只解析 obj 本身，忽略 mtllib 指向的.mtl文件，导致usemtl引用的材质不存在，渲染时报材质错误。

解决：解析器需要返回material_libraries列表，并在解析完 obj 后主动加载对应.mtl文件。.mtl里同样是一行一关键字，常见的有newmtl、Kd（漫反射色）、map_Kd（漫反射贴图路径）。贴图路径通常是相对 obj 文件目录的，所以加载时要先os.path.dirname(obj_path)再拼接。如果.mtl缺失，不要直接崩溃，给出警告并给一个默认灰色材质。这里要特别提醒：不要用绝对路径写死在解析器里，因为模型文件可能被复制到别的目录，一旦路径失效，所有材质都渲染成紫黑色。

6. 进阶：用序列化缓存把 obj 加载提速一个量级

6.1 离线转二进制缓存，运行时不再碰文本解析

看到这里，你已经能写出一个正确、能应付常见模型的 obj 解析器。但如果要把解析结果用于运行时加载，例如要做“cesium 加载 obj 模型”的实时预览，反复做文本解析就不划算了。我会把 obj 解析放到离线步骤，运行时装二进制。具体做法是，把ObjModel的顶点和索引用struct打包成紧凑的.objb文件，加载时用numpy.frombuffer直接读取。

import struct def save_objb(model, filepath): with open(filepath, 'wb') as f: f.write(struct.pack('<II', len(model.vertices) // 7, len(model.indices))) f.write(struct.pack('<%df' % len(model.vertices), *model.vertices)) f.write(struct.pack('<%dI' % len(model.indices), *model.indices)) def load_objb(filepath): import numpy as np with open(filepath, 'rb') as f: header = f.read(8) vcount, icount = struct.unpack('<II', header) vertices = np.frombuffer(f.read(vcount * 7 * 4), dtype=np.float32) indices = np.frombuffer(f.read(icount * 4), dtype=np.uint32) return vertices.reshape(-1, 7), indices

序列化的好处有两个：一是加载时间从几百毫秒降到几毫秒，二是numpy.frombuffer得到的是只读数组，可以直接用于大部分 WebGL 绑定而不用再拷贝。我一般会在解析脚本里加一个--cache参数，第一次解析 obj 时生成.objb，之后所有工具链只消费.objb这个中间产物。这样“obj 序列”（比如动画关键帧模型）也走同一套流程：离线把几十个 obj 逐个解析成缓存，运行时按帧切换索引，而不是每秒都调解析器。

这里有个血泪经验：.objb的版本号一定要写进 header，因为解析器修复 UV 翻转逻辑后，旧的缓存文件会带着错误 UV。我在项目里吃过这个亏，改了解析逻辑但忘记更新版本号，程序加载旧缓存，表现出的症状和直接读取 obj 完全不同，排查了很久。所以离线缓存和解析器要配套发布，header 里至少要放格式版本和顶点布局版本。

做索引去重时也值得留一个开关：当模型需要保留边界焊接（比如把多个 obj 拼成大地图）时，不要用标准去重，而改用基于位置数组的哈希去重，只合并完全相同的(x, y, z)，忽略 UV 和法线。这个逻辑写成独立函数后，既满足渲染性能，又不破坏场景拼接。希望这个技巧能帮你在做模型转换和加载工具时少走弯路。

本文还有配套的精品资源，点击获取