glTF 与 GLB 的区别
glTF 与 GLB 的区别
glTF（GL Transmission Format）和 GLB（GL Binary）是同一套标准下的两种文件格式，核心目标都是高效传输和加载 3D 模型，但设计思路和应用场景不同：
1. glTF（JSON 格式）
本质：glTF 是一个 JSON（JavaScript Object Notation）格式的文本文件，主要作用是描述 3D 场景的结构、材质、动画等信息，类似于“模型的元数据清单”。它通过引用外部的二进制数据（
.bin文件）和纹理图片（如.png、.jpg）来完整定义模型。核心内容：
场景层级（Nodes）：模型的父子关系（如角色的手→手臂→身体）。
网格数据（Meshes）：顶点坐标、法线、UV 纹理坐标等的索引（告诉渲染引擎如何读取
.bin中的二进制数据）。材质与着色器（Materials）：定义颜色、粗糙度、金属度等 PBR（基于物理的渲染）属性，以及纹理的引用路径（如
"diffuseTexture": {"uri": "texture.png"}）。动画（Animations）：关键帧数据（如骨骼的旋转、位移随时间的变化）。
特点：
模块化：JSON 文件仅描述“结构”，实际数据（顶点、索引、纹理）通过外部文件引用，便于复用（例如多个 glTF 模型共享同一个
.bin或纹理）。可编辑性：直接修改 JSON 或纹理文件即可调整模型（无需重新打包），适合开发阶段的调试。
轻量传输：JSON 文本体积小，适合网络传输中快速解析模型结构（如 Web 端先加载 JSON 预览模型轮廓，再按需加载
.bin和纹理）。
2. GLB（二进制格式）
本质：GLB 是 glTF 的二进制封装格式，将 glTF 的 JSON 内容、
.bin二进制数据、纹理图片等所有资源打包成一个单一的二进制文件（.glb后缀）。核心设计：
单一文件：所有数据（结构描述、几何、纹理）集成在一个文件中，避免了多文件分发的复杂性（如 Web 页面只需加载一个
.glb，无需发起多个 HTTP 请求）。高效加载：二进制格式无需解析 JSON，可直接读取，适合对加载速度要求高的场景（如 VR/AR 应用、移动端 3D 展示）。
不可变结构：GLB 是“固化”的，无法像 glTF 那样灵活替换纹理或修改部分数据（需解包后重新打包）。
对比
为什么 glTF 常带有纹理和 .bin文件？
glTF 本身（JSON 文件）不直接存储二进制几何数据或纹理，而是通过引用外部文件来实现灵活和高效。这种设计的原因如下：
1. 纹理（Texture）：分离颜色与结构
纹理（如漫反射贴图、法线贴图）是模型的“外观细节”，而 glTF 的 JSON 主要描述模型的“结构”（顶点位置、面连接关系等）。分离纹理的原因：
复用性：多个模型可以共享同一张纹理（例如一批相同材质的桌子，只需一张纹理图）。
编辑灵活性：修改纹理（如更换颜色）时，只需替换图片文件，无需重新生成整个 glTF 文件。
压缩优化：纹理通常可以单独压缩（如使用
.ktx2或.basisu格式），而 glTF 的 JSON 不关心具体压缩方式，只需指定纹理路径即可。
2. .bin文件：存储几何与属性的二进制数据
.bin文件是 glTF 的二进制数据块，存储模型的顶点坐标、法线、UV 坐标、三角形索引等几何信息。分离 .bin的原因：
体积优化：二进制数据比 JSON 文本更紧凑（例如浮点数以二进制存储，无需文本解析的开销）。
渲染效率：GPU 可以直接读取
.bin中的二进制数据（无需解析文本），加速模型加载和渲染。结构解耦：JSON 仅记录“如何读取
.bin”（如顶点属性的偏移量、数据类型），而.bin存储“具体数值”，两者分工明确，降低文件冗余。
示例：一个完整的 glTF 模型结构
假设一个简单的立方体模型，其文件可能包括：
cube.gltf（JSON）：描述立方体的顶点索引、材质（引用texture.png）、场景层级等。cube.bin（二进制）：存储立方体的顶点坐标（如[x1,y1,z1,x2,y2,z2,...]）、三角形索引（如[0,1,2,2,3,0,...]）、法线等数据。texture.png（图片）：立方体的漫反射贴图（颜色纹理）。
