作者：Huy Nguyen · ·
GLB 是 Sketchfab、Blender 的 glTF 导出、摄影测量服务，以及一切为网页而做的东西给你的格式。FBX 则是 Unity、Unreal、Maya 和 3ds Max 要的格式。在这两者之间转换是游戏和动画工作里最常见的活儿之一，而问题几乎从来不是三角面能不能过去，而是骨骼、贴图和动画能不能跟着一起过去。
这些担心很合理，因为不少转换器会悄悄把它们丢掉。一个 GLB 可以带骨架、逐顶点蒙皮权重、把贴图打包进同一个文件的 PBR 材质，以及动画片段。FBX 这些也都能带，所以一次好的转换不该丢掉任何实质内容。
我们没有只是这么断言，而是今天做了三个 GLB 文件，其中一个带真正的两节蒙皮骨骼，一个把 PNG 贴图内嵌在文件里，用这个页面背后同一个转换器转了一遍，然后把每个结果都放回 Blender 5.1，并直接读了 FBX 的原始字节。下面是我们实测到的结果。
三次实测保住了什么，丢了什么
三个输入。一个是普通场景，两个命名对象各一种纯色，其中一个带 40 帧旋转动画。一个是同类场景，但 GLB 里内嵌了一张 64 x 64 的 PNG 贴图并通过 UV 映射。还有一个是蒙皮骨骼：两节骨骼的骨架、一个按逐顶点权重绑定到骨架的网格，以及 30 帧骨骼旋转动画。
| 输入 | 输出 | 结论 |
|---|---|---|
| 每个场景两个命名对象 | 两个网格对象，名字不变 | 保住了。没有被合并，也没出现临时名字 |
| 972 个和 540 个三角面 | 972 个和 540 个三角面 | 完全保住，顶点一一对应 |
| 带基础色的命名材质 | 同样的名字，颜色精确到小数后两位 | 保住了 |
| 内嵌在 GLB 里的 PNG 贴图 | 同一张图片内嵌在 FBX 里 | 保住了。不需要额外带着图片文件 |
| UV 布局 | UV 布局 | 保住了 |
| 40 帧旋转动画 | 一段动画，第 1 到 40 帧 | 保住了，但被改写成烘焙过的变换曲线 |
| 两节骨骼的骨架 | 同样两节骨骼的骨架 | 保住了 |
| 逐顶点蒙皮权重 | 同样两个权重组，仍然绑在骨架上 | 保住了 |
| 30 帧骨骼动画 | 一段动画，第 1 到 30 帧，带真正的骨骼曲线 | 保住了 |
| 以米为单位的坐标 | 数值完全相同，上轴一致 | 保住了。没有缩放也没有旋转 |
骨骼活下来了，这才是值得知道的部分
这是大多数人真正关心的问题，所以我们专门做了一个文件来回答它。输入是一条小小的蒙皮手臂：骨架里有名为 Lower 和 Upper 的两节骨骼，网格按逐顶点权重绑定到这两节上，上节骨骼带 30 帧旋转。
转换之后，FBX 里依然有一个骨架，依然是 Lower 和 Upper 两节骨骼，网格依然带着以这两节骨骼命名的两个权重组，并且依然绑在骨架上。直接读 FBX 的话，蒙皮数据也在该在的位置：一个蒙皮变形器、每节骨骼一个 cluster，以及一份保存下来的绑定姿态。动画回来时是一段覆盖第 1 到 30 帧的片段，而且曲线是打在 Upper 这节骨骼上的，不只是打在对象上。
所以一个带骨骼的 GLB 角色在这里转换之后，到你的引擎里应该还是一个带骨骼的角色。需要如实说明的限制是：我们的骨骼只有两节、只有一段动画。我们没有测过完整的人形骨架、同一个文件里多段动画，也没有测过形变目标，所以那些属于未测，不能算已确认。
贴图是走在 FBX 里面的
GLB 把图片放在单个文件内部，这正是这个格式的意义所在。FBX 也能这样做，而在我们的测试里它确实做了：PNG 的字节就内嵌在 FBX 本身里，旁边还有一条 FBX 内嵌媒体的标准引用。导回 Blender 时，那张 64 x 64 的图片和 UV 一起被恢复出来了。
这一点要紧，因为转换之后关于贴图最常见的抱怨，就是模型灰扑扑地进来并报一个找不到文件的错误。这次没有发生，而且你也不需要在 FBX 旁边另外保管一个图片文件。
有一个我们实测到的细节，照实说明。那个带贴图的材质，基础色数值回来时是纯白，由贴图提供颜色；而原来的 GLB 里那一项根本没有数值，完全靠贴图。看起来的效果是一样的，但如果你本来以为那一栏里还会有一个颜色，那里是没有的。
动画活下来了，但被改写成烘焙曲线
两个带动画的场景都把动画片段完整带回来了，帧范围也一样：对象旋转是第 1 到 40 帧，骨骼动画是第 1 到 30 帧。没有被截断，也没有片段丢失。
存储方式确实变了。GLB 用四元数写旋转，而且只写真正有变化的通道。我们拿回的 FBX 则在每个有动画的节点上都写了位移、旋转和缩放曲线，旋转用欧拉角表示，有变化的那个通道每帧一个关键帧。
对播放来说这没有区别，FBX 这么做正是因为烘焙过的变换通道在任何引擎里都不会有歧义。但如果你本来打算之后再编辑曲线，那就有影响了：你会发现自己只打了两个关键帧的地方变成了三十个，四元数变成了欧拉角。如果编辑曲线才是目的，请把 GLB，或者更好的是原始工程文件，当作权威来源留着。
上轴和缩放在这里都不用改
这是 GLB 转 FBX 比大多数转换都轻松的一点。两个格式都以 Y 轴为上，所以没有旋转需要撤销。我们拿回的 FBX 正是这么声明的：上轴 Y、前轴 Z、单位比例因子 1，文件是版本 7400 的二进制 FBX。
坐标本身也没动。我们那个 0.05 米的方块在 FBX 里还是 0.05，0.03 米的球还是 0.03，各个对象的高度也和 GLB 里一致。没有任何东西被乘过。
但到了引擎里会怎样，取决于引擎而不是文件。按惯例 FBX 以厘米计数，而 glTF 以米计数，所以在 GLB 里意味着五厘米的那个 0.05，可能被一个默认按厘米理解的导入器读成半毫米。如果模型进来小了或者大了一百倍，要改的是 Unity、Unreal 或 Maya 里的导入缩放设置，而不是再转一次。我们只在 Blender 里测过，它读回来的尺寸和原始一致。
FBX 里确实装不了的东西
- Draco 压缩。GLB 可以用 Draco 压到很小，FBX 没有对应的机制，所以那种情况下 FBX 会明显更大。我们没有测过 Draco 文件。
- 原则上的单文件保证。FBX 也可以改为引用外部贴图而不是内嵌。我们这次是内嵌的，但你从别处拿到的 FBX 可能不是，在机器之间搬动之前先确认一下。
- 适合网页这件事。如果你的目标是浏览器或网页查看器，转成 FBX 完全是走反了方向，请留着 GLB。
- GLB 本来没有的东西。如果你的 GLB 是一个没有骨骼的静态网格，任何转换都不会给它加上骨架。
文件体积两个方向都可能
这里没有简单的规律，我们三次测试的结果方向都不一样。普通的两对象场景从 73,656 字节缩到 55,980 字节。带贴图的场景略微变大，从 43,548 到 46,092 字节。骨骼那个大了很多：9,452 字节的 GLB 变成 40,076 字节的 FBX，四倍多。
背后的规律是，FBX 在描述骨架和烘焙动画曲线时很啰嗦，而处理纯几何数据时还算紧凑。所以一个骨骼多、动画重的角色涨得最厉害，如果你在反方向上接近上传上限，这一点值得记住。
我们最大的测试文件不到 75 KB，所以上面这些只是比例关系，不能用来推断一个 200 MB 的角色会怎样。
想自己在电脑上做同一件事
- Blender 是标准路线，而且免费：文件、导入、glTF 2.0，然后文件、导出、FBX。在 FBX 导出面板里，把 Path Mode 设为 Copy 并启用旁边的内嵌贴图按钮，图片才会被放进 FBX 里而不是放在旁边。
- 如果文件是带骨骼的角色，请在导出时把对象类型限制为骨架和网格。把相机、灯光和空物体也一起导出，是引擎里冒出多余节点最常见的原因。
- 较新版本的 Unity 和 Unreal 都能直接导入 GLB，所以如果你的目标是这两个，先确认一下你到底需不需要 FBX。
- Autodesk FBX Converter 是个免费的独立工具，但它很老，并且读不了 glTF 和 GLB，所以在这个方向上帮不上忙。
本站的限制，以及你的文件会怎样
- 免费：每个文件最大 30 MB，每小时 10 次转换，同时最多 2 个任务，不需要注册。
- Pro：每个文件最大 1 GB，每小时 50 次转换，同时最多 5 个任务。带骨骼的角色文件比静态网格更容易撞到 30 MB。
- 上传的文件和转换结果会在上传后 1 小时内从我们的服务器上删除。
- 从 GLB 出发，本站可以转成 FBX、OBJ、STL、GLTF 和 USDZ。其中能带上动画的是 FBX 和 USDZ，OBJ 和 STL 不行。
2026 年 10 月 29 日用 Blender 5.1 做的三个 GLB 实测：一个是两个对象带纯色材质和 40 帧旋转动画（73,656 字节）；一个是同类场景，但材质带一张内嵌在 GLB 里的 64 x 64 PNG 贴图，并有同样的动画（43,548 字节）；还有一个是蒙皮骨骼，含两节骨骼的骨架、逐顶点蒙皮权重和 30 帧骨骼动画（9,452 字节）。三个都在本站转成 FBX，再导回 Blender 5.1 清点对象、顶点、材质、贴图、骨骼、顶点组和动画曲线，并直接读取 FBX 文件核对其声明的上轴和单位比例。