更新済み 2026年9月13日
3D 変換で保持されるものとそのコスト
メッシュを変換することは無料でもなく、無損失の操作でもありません。GLB と glTF はすべてを保持します。OBJ はオブジェクトを分けたまま保持し、マテリアル名も保持しますが、頂点カラーは破棄します。STL は三角形のみを保持します。PLY は頂点カラーを保持しますが、シーンを1つのメッシュに平坦化します。USDZ は両方のオブジェクトとUVを保持しましたが、再読み込み時に頂点カラーとマテリアル名を失い、USDA の zip を書き出します。下の数値は推定ではなく測定されたものです。
このページの各数値は、実際のファイルを使ってこのサイトが使用する同じコンバーターを実行し、書き込まれたバイトから属性を直接読み取ったものです。測定された 2026年9月13日 three.js r で。179方法はページの最後にあり、スクリプトはリポジトリにあります。
各フォーマットは何を保持するか？#
異なる名前を持つ2つのキューブを含むリファレンスシーンがあり、それぞれが名前付きの金属マテリアル、頂点カラー、UV座標、法線を持っています。このシーンは6つの形式に変換されました。GLBとglTFは完全に戻ってきました。他のすべてのフォーマットは何かを失い、それぞれ異なるものを失いました。
| 宛先 | 2つのオブジェクト | UV座標 | 頂点ごとの色 | マテリアル名 | 頂点数 |
|---|---|---|---|---|---|
| GLB | 保持されるもの 2 | 保持される | 保持される | 保持される | 48 頂点 |
| glTF | 保持されるもの 2 | 保持される | 保持される | 保持される | 48 頂点 |
| OBJ | 保持されるもの 2 | 保持される | 失われる | 保持される | 72 頂点 |
| STL | 1 つに結合 | 失われる | 失われる | 失われる | 72 頂点 |
| PLY | 1 つに結合 | 保持される | 保持される | 失われる | 48 頂点 |
| USDZ | 保持されるもの 2 | 保持される | 失われる | 失われる | 72 頂点 |
なぜSTLとPLYはシーンを1つのメッシュに統合するのですか？#
どちらのフォーマットもシーングラフを持っていません。GLB、glTF、OBJは同じファイル内で複数の名前付きオブジェクトを記述できます。STLは単一のソリッドを、PLYは単一の要素リストを記述するので、2つのキューブは1つのメッシュとして到着し、再度分離する方法はありません。
最も驚くべき損失は、目に見えないものです。変換されたモデルはビューワーではまったく同じに見えます。パーツを選択したり、マテリアルを変更したり、アニメーションをつけようとしたときに初めて、パーツがもはや存在しないことに気づきます。
モデルを引き続き分離可能にする必要がある場合、行き先は GLB、glTF、または OBJ である必要があります。もしラミネーターや単一材料の印刷に行く場合、統合は費用がかかりません。
ファイルはどれくらい大きくなるのでしょうか？#
ほとんどの人が予想する以上です。実際に生成されたメッシュでは、OBJ が元の OBJ の 5.6 時には、元のGLBとPLY 1.4 倍です。どちらも同じジオメトリを持っています。
| 変換 | 起点 | 結果 | 比率 | 書き込まれた頂点 |
|---|---|---|---|---|
| mug.glb a GLB | 880 KB | 1,173 KB | 1.3x | 25,000 |
| mug.glb a glTF | 880 KB | 1,564 KB | 1.8x | 25,000 |
| mug.glb a OBJ | 880 KB | 4,928 KB | 5.6x | 150,000 |
| mug.glb a STL | 880 KB | 2,441 KB | 2.8x | 150,000 |
| mug.glb a PLY | 880 KB | 1,221 KB | 1.4x | 25,000 |
| mug.glb a USDZ | 880 KB | 2,927 KB | 3.3x | 150,000 |
| lion.glb a GLB | 8,768 KB | 11,690 KB | 1.3x | 249,369 |
| lion.glb a glTF | 8,768 KB | 15,587 KB | 1.8x | 249,369 |
| lion.glb a OBJ | 8,768 KB | 51,880 KB | 5.9x | 1,496,202 |
| lion.glb a STL | 8,768 KB | 24,352 KB | 2.8x | 1,496,202 |
| lion.glb a PLY | 8,768 KB | 12,176 KB | 1.4x | 249,369 |
| lion.glb a 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はバッファをBase64でエンコードしたJSONであり、 33 GLBと同じものより約1パーセント高くつきます。なぜならBase64は3バイトごとに4バイトに変換するからです。
GLBからGLBに変換しても、なぜファイルが大きくなったのでしょうか？#
コンバータは、頂点法線を持たないメッシュには頂点法線を計算してから書き込むからです。生成されたメッシュにはしばしば法線属性がなく、そのため往復すると頂点ごとに完全なベクトルが1つ追加されます。
テストでは 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 の zip |
それでは、3D変換には損失があるのでしょうか、それともないのでしょうか？#
両方です。そして、その区別が有用です。ジオメトリ自体は何も失いません：入ってきた形が出て行く形です。ジオメトリを取り巻くすべては失われますが、どの部分を失うかは選んだ宛先によって完全に決まります。
ここでは座標を切り捨てることはありません。GLB、STL、そして PLY は 32 ビットのバイナリ浮動小数点を記録します。glTF は同じバイナリバッファを base64 として JSON 内に埋め込みます。USDZ は USDA の zip を書き込みます。OBJ は唯一座標を 10 進テキストとして書き込み、丸めるのではなく完全な精度で書き込むため、そのファイルが非常に大きくなる理由の一部でもあります。
これは、JPEG を再度保存するというような、各変換がモデルを少しずつ劣化させるという通常の懸念が当てはまらないことを意味します。GLB から OBJ に変換して戻しても、メッシュが滑らかになることはありません。
実際に行うことは、このページの上部に表示されているものを破棄することです：STLおよびPLYのシーングラフ、OBJ、STL、USDZの頂点ごとの色、STL、PLY、USDZのマテリアル名、そしてSTLのUVです。それらの損失は永久的であり、再度変換しても再び生成することはできません。
どの宛先を選ぶべきですか？#
宛先は、何を残す必要があるかに基づいて選び、受信ツールがリストの最初に置いた拡張子に基づいて選ばないでください。上記で測定されたものに基づく妥当な選択肢は次の通りです。
| もし必要なら | 選ぶ | 理由 |
|---|---|---|
| すべてを保持、単一のファイルで | GLB | シーンのグラフ、マテリアル名、UV、頂点ごとの色を一緒に保持した唯一のフォーマットで、完全なフォーマットの中で最も小さいサイズです。 |
| すべて保持されており、人間が読めます | glTF | GLBと同じ内容で、約 33 パーセント大きくなります。バッファはJSONの中でbase64で格納されるためです。 |
| デスクトッププログラムで名前付きに分けられたオブジェクト | OBJ | 両方のオブジェクトと両方の素材名を保持しました。頂点ごとの色は破棄し、6つの中で最も大きいファイルを書き込みます。 |
| 3Dプリント | STL | 三角形だけ、それがスライサーが読み取る全てです。実際のメッシュにおけるglTFではない最小の宛先。 |
| ジオメトリと頂点ごとの色、軽量で | PLY | 唯一 glTF ではない目的地で、頂点ごとの色を保持し、インデックスも維持しているので、元のサイズに近いままです。 |
| Apple の Quick Look / iPhone の AR | USDZ | 参照シーンの両方のオブジェクトと UV を保持しました。再読込すると、頂点ごとの色とマテリアル名を失いました。携帯電話で開ける USDA の zip。 |
これらのフォーマットを定義するもの#
上記の測定値は私たちのものです；各フォーマットがどの情報を持てるかは私たちが決めたものではありません。これらは仕様書とフォーマットの参照で決まるもので、このページの内容を信じるのではなく、元の情報源で確認できるようになっています。
- glTF 2.0 の仕様The Khronos Group
シーングラフ、GLB と glTF が持つマテリアルとアクセサリーを定義し、なぜここで唯一無傷で残った目的地だったのかを説明してください。
- メディアタイプ model/gltf-binaryIANA
上で測定された GLB の登録されたタイプ、バイナリコンテナ。
- メディアタイプ model/stlIANA
登録されている STL: 面の三角形と法線のみ、色、UV、マテリアル、オブジェクト名のフィールドはなし。
- Wavefront OBJ ファイルフォーマットポール・バーク
頂点ごとの色フィールドを持たない OBJ の定番リファレンスで、変換で破棄された内容と一致。
- PLY ポリゴンファイルフォーマットポール・バーク
頂点ごとのプロパティ、色を含め、PLY を唯一 glTF 以外の場所でも保持する目的地として特定する。
- USDZ ファイル形式の仕様 Pixar / OpenUSD
USDZ は最初のエントリが USDA シーンである zip です。これがこのコンバータが書き込み、読み込むパッケージです。
測定方法 #
測定は製品を実行して行われ、製品の説明ではありません。スクリプトはブラウザのコンバータと同じローダーとエクスポーターを、同じオプションでインポートし、数値を再現または議論できるようにリポジトリに置いてあります。
- 名前付きの 2 つの立方体で参照シーンを構築し、それぞれ名前付きの金属素材、頂点ごとの色、UV 座標、法線を持たせる。
- 生成された実際のメッシュを、コンバーターが与えられたファイルを読み込むのと同じ方法で読み込みます。頂点法線がないメッシュに対して法線を計算するステップも含めます。
- 同じコンバーターが呼び出すエクスポーターと同じバイナリ設定で、GLB、glTF、OBJ、STL、PLY、USDZにエクスポートします。
- 各結果のバイト単位のサイズを記録します。
- シーンを再読み込みするのではなく、書き込まれたバイトから直接属性を読み取ります。なぜなら、ローダーはファイルにないものを作り出すからです：vn行がないOBJは、法線属性が合成された状態で再読み込みされます。
- 結果から直接テーブルを公開します。測定された 2026年9月13日 three.js r で。179.
質問
- 3Dファイルを変換すると品質が失われますか？
- 形状番号。各宛先は変換されて再読み込みされ、三角形の数と総表面積は 498,734 三角形のメッシュで同一となり、いかなる形式でも座標は切り捨てられません。失われるのはジオメトリの周囲すべてで、宛先によって異なります：STLはUV、色、マテリアル、およびシーングラフを破棄します；OBJは頂点ごとの色を破棄します；PLYはマテリアル名を破棄し、シーンを統合します；USDZは再読み込み時に頂点ごとの色とマテリアル名を破棄します；GLBとglTFはすべて保持しました。
- どの3Dフォーマットが最も容量が小さいですか？
- GLB、実際のメッシュでは。このテストではGLBは 1,173 KB OBJが書き込んだところに書き込みました 4,928 KB 同じモデルについて、GLBはバイナリで共有頂点のインデックスを保持するのに対し、生成されたOBJはテキストで、各三角形の各角を別々に保存するからです。
- なぜ私のOBJは、元となったGLBよりもはるかに大きいのですか？
- 2つの理由があります。2つの測定値：OBJはテキストでありバイナリではなく、ここで書かれるOBJは三角形間で頂点を共有しないため、頂点数が倍増します。 6 適切にインデックスされたメッシュでは、表面は同じですが、会計（サイズ）は同じではありません。
- STLは色を保持しますか？
- いいえ。バイナリのSTLは三角形ごとに面の法線と3つの角を保持しており、色、UV、マテリアル、オブジェクト名用のフィールドはありません。これはこれらのテストで書かれたすべてのSTLで実行されました。
- 頂点ごとの色をGLBを使わずに保持できますか？
- はい、PLYを使えば可能です。これらのテストでは、ヘッダーに色プロパティを宣言したglTF以外の唯一の宛先でした。ただし、複数のオブジェクトを持つシーンを一つのメッシュに平坦化するため、色は保持されますがパーツは失われます。
- 3Dモデルを何度も変換すると劣化しますか？
- いいえ。JPEGを再保存するのとは異なり、3D変換では誤差が累積しません。座標はバイナリの浮動小数点としてコピーされ、OBJの場合は完全精度の10進数として書き込まれます。どのフォーマットでも往復しても表面は同一です。戻らないのは、宛先が最初から保持できなかったマテリアルやシーンの情報です。
- これらの数値を再現できますか？
- はい。計測用スクリプトはリポジトリ内の scripts/measure-conversions.mjs にあり、このページが読み込む JSON を書き出します。最後に実行されたのは 2026年9月13日 three.js r で。179.