已更新 2026年9月13日
3D 转换可以保留什么以及费用是多少？
转换网格不是免费的，也不是无损操作。 GLB 和 glTF 保留一切。 OBJ 保留单独的对象及其材质名称，但丢弃每个顶点的颜色。 STL 仅保留三角形。 PLY 保留每个顶点的颜色，但将场景展平为单个网格。 USDZ 保留了两个对象和 UV，在重读时丢失了顶点颜色和材质名称，并写入了 USDA 的 zip。下面的数字是测量的，而不是估计的。
此页面上的每个图形都来自运行该站点使用的相同转换器和真实文件，并直接从其写入的字节中读取属性。测量了 2026年9月13日 与三.js r179。该方法位于页面底部，脚本位于存储库中。
每种格式保留什么？#
具有两个不同命名的立方体的参考场景被转换为六个目标，每个立方体都有自己命名的金属材质、每个顶点的颜色、UV 坐标和法线。 GLB 和 glTF 完整返回。所有其他格式都丢失了一些东西，并且每种格式丢失了不同的东西。
| 目的地 | 两个物体 | 紫外坐标 | 每个顶点的颜色 | 材料名称 | 顶点数 |
|---|---|---|---|---|---|
| GLB | 的 2 | 它被保存下来 | 它被保存下来 | 它被保存下来 | 48 顶点 |
| glTF | 的 2 | 它被保存下来 | 它被保存下来 | 它被保存下来 | 48 顶点 |
| OBJ | 的 2 | 它被保存下来 | 丢失了 | 它被保存下来 | 72 顶点 |
| STL | 合并为1 | 丢失了 | 丢失了 | 丢失了 | 72 顶点 |
| PLY | 合并为1 | 它被保存下来 | 它被保存下来 | 丢失了 | 48 顶点 |
| USDZ | 的 2 | 它被保存下来 | 丢失了 | 丢失了 | 72 顶点 |
为什么 STL 和 PLY 将场景合并到单个网格中？#
这两种格式都没有场景图。 GLB、glTF和OBJ可以在单个文件中描述多个命名对象； STL 描述单个实体，PLY 描述单个元素列表，因此两个立方体作为单个网格到达，并且无法再次将它们分开。
最令人惊讶的是损失，因为它是看不见的。转换后的模型在取景器中看起来完全相同。仅当您尝试选择、更改材质或为其某一部分设置动画时，您才会发现这些部分不再存在。
如果模型必须保持可分离，则目标必须是 GLB、glTF 或 OBJ。如果使用层压机或单一材料打印，则熔合不会产生任何成本。
文件增长了多少？#
超出大多数人的预期。在真实生成的网格中，OBJ 占据 5.6 是原始 GLB 和 PLY 的倍 1.4 次。它们都具有相同的几何形状。
| 转换 | 产地 | 结果 | 比例 | 书面顶点 |
|---|---|---|---|---|
| mug.glb 到 GLB | 880 KB | 1,173 KB | 1.3x | 25,000 |
| mug.glb 到 glTF | 880 KB | 1,564 KB | 1.8x | 25,000 |
| mug.glb 到 OBJ | 880 KB | 4,928 KB | 5.6x | 150,000 |
| mug.glb 到 STL | 880 KB | 2,441 KB | 2.8x | 150,000 |
| mug.glb 到 PLY | 880 KB | 1,221 KB | 1.4x | 25,000 |
| mug.glb 到 USDZ | 880 KB | 2,927 KB | 3.3x | 150,000 |
| lion.glb 到 GLB | 8,768 KB | 11,690 KB | 1.3x | 249,369 |
| lion.glb 到 glTF | 8,768 KB | 15,587 KB | 1.8x | 249,369 |
| lion.glb 到 OBJ | 8,768 KB | 51,880 KB | 5.9x | 1,496,202 |
| lion.glb 到 STL | 8,768 KB | 24,352 KB | 2.8x | 1,496,202 |
| lion.glb 到 PLY | 8,768 KB | 12,176 KB | 1.4x | 249,369 |
| lion.glb 到 USDZ | 8,768 KB | 30,487 KB | 3.5x | 1,496,202 |
为什么OBJ和STL的顶点数相乘？#
因为它们都不共享三角形之间的顶点。索引良好的网格仅保存每个角一次，并从与其接触的所有三角形引用它；这里写的OBJ和STL分别存储每个三角形的三个角。在测试中与 lion.glb，就变成了 249,369 顶点在 1,496,202, 一些 6 更多倍。
几何形状不会改变。相同的表面、相同的三角形、相同的轮廓；只是会计比较贵，文件也或多或少按同样的比例增长。
PLY 是有用的反例。它维护索引，因此相同的网格以接近原点的大小写入，并且仍然带有每个顶点的颜色。对于仅需要保留几何形状的大型网格，PLY 是此列表中最便宜的诚实目标。
文本与二进制会让情况变得更糟。 glTF 是 JSON，其缓冲区以 base64 编码，其成本约为 33 比相同的 GLB 多 %，因为 base64 将每三个字节转换为四个字节。
为什么从 GLB 转换为 GLB 时文件仍然增长？#
因为转换器会计算没有顶点法线的任何网格的顶点法线，然后写入它们。生成的网格通常没有法线属性，因此往返过程会为每个顶点添加一个完整的向量。
测试与 mug.glb 是一个明显的例子：他们输入 880 KB 他们离开了 1,173 KB，几何形状没有任何变化。添加的法线就是差异。
这是一个深思熟虑的决定，而不是一个缺陷。在大多数观看者中，没有法线的网格看起来是平坦且多面的，因此转换器在加载时计算一次它们，而不是让每个后续工具必须猜测。
转换会改变形状吗？#
不会。每个目标都经过转换，然后读回，表面结果是相同的：相同数量的三角形和相同的总表面积，直到测量极限，在网格上 498,734 三角形。几何图形是 3D 文件中在转换后完好无损的部分。
| 目的地 | 之后的三角形 | 表面积误差 | 坐标如何保存 |
|---|---|---|---|
| GLB | 没有变化 | 0% | float32 二进制 |
| glTF | 没有变化 | 0% | Base64 缓冲区 |
| OBJ | 没有变化 | 0% | 文本 与 17 小数 |
| STL | 没有变化 | 0% | float32 二进制 |
| PLY | 没有变化 | 0% | float32 二进制 |
| USDZ | 没有变化 | 0% | 来自 USDA 的压缩包 |
那么3D转换是否有损呢？#
两者都是东西，区别就是有用的东西。几何学不会失去任何东西：进入的形状就是离开的形状。几何体周围的所有内容都会丢失，丢失的部分完全取决于您选择的目的地。
这里没有任何东西会截断坐标。 GLB、STL 和 PLY 写入 32 位二进制浮点数。 glTF 在其 JSON 中嵌入了与 base64 相同的二进制缓冲区。 USDZ 写入 USDA 的 zip。 OBJ 是唯一一款将位置写入十进制文本的产品，并且以全精度写入而不是四舍五入，这也是其文件如此之大的部分原因。
这意味着通常担心的每次转换都会稍微降低模型性能（例如重新保存 JPEG），这一点并不适用。从 GLB 转换为 OBJ 并返回不会平滑网格。
它所做的就是丢弃本页上方出现的内容：STL 和 PLY 中的场景图，OBJ、STL 和 USDZ 中的每个顶点颜色，STL、PLY 中的材质名称以及这些损失是永久性的，因为重新转换无法再次发明它们。
您应该选择哪个目的地？#
它根据必须生存的内容来选择目的地，而不是根据接收工具在其列表中首先放置的范围。这些是根据上述测量得出的合理选择。
| 如果您需要 | 选择 | 为什么 |
|---|---|---|
| 所有内容都保存在一个文件中 | GLB | 唯一将场景图、材质名称、UV 和每个顶点的颜色保存在一起的目的地，并且具有完整格式中最小的尺寸。 |
| 一切都保存下来，可供人读取 | glTF | 与GLB内容相同，大约一个 33 百分比大一些，因为缓冲区采用 JSON 中的 base64 格式。 |
| 在桌面程序中分隔命名对象 | OBJ | 他保留了这两个物体和两个材料名称。丢弃每个顶点的颜色并写入六个文件中最大的文件。 |
| 3D打印 | STL | 三角形，没有别的，这就是层压机读取的全部内容。最小的非 glTF 目标位于真实网格上。 |
| 每个顶点的几何形状和颜色，权重很小 | PLY | 除 glTF 之外唯一保留每个顶点颜色并维护索引的目标，因此它保持接近源的大小。 |
| iPhone 上的 Apple Quick Look/AR | USDZ | 它将两个对象和 UV 保留在参考场景中。重新读取时丢失了每个顶点的颜色和材质名称。手机可以打开的 USDA zip。 |
这些格式的定义是什么#
以上测量值是我们自己的；每种格式可以采用什么不是由我们决定的。这些是决定它的规范和格式参考，因此可以在来源处验证此页面所说的内容，而不是简单地相信。
- glTF 2.0 规格科诺斯集团
定义了 GLB 和 glTF 所携带的场景图、材质和访问器，并解释了为什么它们是唯一完好无损的目的地。
- 媒体类型 model/gltf-binary互联网号码分配机构
为 GLB（上面测量的二进制容器）注册的类型。
- 介质类型型号/stl互联网号码分配机构
STL 已注册：三角形和面法线，没有任何颜色、UV、材质或对象名称字段。
- Wavefront OBJ 文件格式保罗·伯克
OBJ 的通常参考，它没有自己的每个顶点颜色字段，这与转换排除的内容一致。
- PLY 多边形文件格式保罗·伯克
记录每个顶点的属性（包括颜色），使 PLY 成为此处保留它的唯一非 glTF 目标。
- USDZ 文件格式规范皮克斯/OpenUSD
USDZ 是一个 zip，其第一个条目是场景 USDA。这就是该转换器写入和读取的数据包。
测量方法#
测量执行的是产品，而不是产品的描述。该脚本导入与浏览器转换器相同的加载器和导出器，具有相同的选项，并且位于存储库中，因此可以复制或讨论这些图。
- 使用两个命名立方体构建参考场景，每个立方体都有命名金属材质、每个顶点的颜色、UV 坐标和法线。
- 加载实际生成的网格的方式与转换器加载您提供的文件的方式相同，包括当网格到达时没有顶点法线时计算顶点法线的步骤。
- 使用转换器调用的相同导出器和相同的二进制设置导出到 GLB、glTF、OBJ、STL、PLY 和 USDZ。
- 记录每个结果的大小（以字节为单位）。
- 直接从写入的字节中读取属性，而不是从重新加载的场景中读取属性，因为加载程序发明了文件不包含的内容：没有 vn 行的 OBJ 也会使用合成法线属性重新加载。
- 直接根据该结果发布表格。测量了 2026年9月13日 与三.js r179.
问题
- 转换 3D 文件会降低质量吗？
- 表格编号每个目标都被转换并读回，三角形的数量和总表面积在网格上显示相同 498,734 三角形，无需截断任何格式的坐标。丢失的是几何体周围的所有内容，这取决于目的地：STL 丢弃 UV、颜色、材质和场景图； OBJ 丢弃每个顶点的颜色； PLY丢弃材质名称并合并场景； USDZ 在重读时丢弃每个顶点的颜色和材质名称； GLB 和 glTF 保留了这一切。
- 哪种 3D 格式占用的空间最少？
- GLB，在真实的网格上。在这些测试中 GLB 写道 1,173 KB OBJ 写的地方 4,928 KB 对于同一模型，因为 GLB 是二进制的并维护共享顶点索引，而生成的 OBJ 是文本并分别保存每个三角形的每个角。
- 为什么我的 OBJ 比它原来的 GLB 占用的空间多得多？
- 出于两个原因，这两种措施：OBJ 是文本而不是二进制，并且 6 在索引良好的网格上。表面相同；会计没有。
- STL 保留颜色吗？
- 不会。二进制 STL 保存每个三角形的一个面法线和三个角，并且没有颜色、UV、材质或对象名称字段。这些测试中编写的所有 STL 都是如此。
- 我可以在不使用 GLB 的情况下保留每个顶点的颜色吗？
- 是的，使用 PLY。在这些测试中，它是唯一在其标头中声明颜色属性的非 glTF 目标。当然，它将多个对象的场景扁平化为单个网格，因此您可以保留颜色并丢失部分。
- 反复转换 3D 模型是否会降低其性能？
- 不会。与重新保存 JPEG 不同，3D 转换不会累积错误：坐标被复制为二进制浮点数，或者在 OBJ 的情况下，被写入为全精度小数。通过任何一种格式的往返都会返回相同的表面。回不去的，是命运从一开始就无法承载的物质和场景信息。
- 我可以复制这些数字吗？
- 是的。测量脚本位于存储库的 script/measure-conversions.mjs 中，并写入读取此页面的 JSON。最后执行于 2026年9月13日 与三.js r179.