STL vs OBJ vs glTF：3Dファイルフォーマットを徹底比較
なぜフォーマット選びが重要なのか
3Dファイルフォーマットの選択を間違えると、テクスチャが見つからない、ジオメトリが壊れている、スライサーがモデルを開いてくれない、といった問題と何時間も格闘する羽目になります。STL、OBJ、glTFは最もよく目にするフォーマットですが、それぞれが全く異なる目的のために、異なる年代に生まれました。STLは、初期の3Dプリンター向けに1987年にはるばる標準化されました。OBJは1992年頃にWavefront Technologies社による柔軟な中間フォーマットとして登場。そしてglTF 2.0は？2017年にKhronos Groupによって策定され、ウェブ上でのリアルタイムレンダリングのためにゼロから作られました。この最も古いフォーマットと最も新しいフォーマットの間の30年という隔たりが、実用上のほぼすべての違いを説明しています。PrusaSlicerで完璧にプリントできるファイルが、ウェブビューワーでは灰色の塊のように見えたり、ゲーム向けのモデルが単純なデスクトップFDMプリンターには全くのオーバースペックだったりするのです。このガイドでは、それぞれのフォーマットの構造、機能、そして一般的なファイルサイズを解説し、変換を考える前、あるいはCocoConvertのようなツールに変換を頼む前に、あなたが正しい選択をする手助けをします。
STL：3Dプリンティングの主力
STLはStandard Tessellation Languageの略ですが、STereoLithographyと呼ばれることもあります。このフォーマットは極めてシンプルで、3Dサーフェスを三角形のメッシュとして表現します。それだけです。色も、テクスチャも、マテリアルもなく、純粋なジオメトリのみ。各三角形は、3つの頂点と外向きの法線ベクトルによって定義されます。バイナリSTLファイルでは、この情報が50バイトにぎゅっと詰め込まれています。法線に12バイト、頂点に36バイト、そしてほぼ常に無視される2バイトの「属性」カウントです。この効率性により、100万個の三角形を持つモデルでも、管理しやすい50MB程度のファイルサイズに収まります。人間が読めるASCII版もありますが、ファイルサイズが5〜6倍大きくなるため、バイナリ形式が主流です。 3Dプリンティングにおいて、STLのシンプルさは最大の強みです。PrusaSlicer、Cura、Bambu Studio、Chituboxといったスライサーはすべて、何も聞かずにSTLをネイティブで開くことができます。Fusion 360のようなプログラムからエクスポート（ファイル → エクスポート → .stl）する際には、精度を調整し、弦の許容誤差を0.001mmまで低く設定できます。この数値は、平らな三角形が理想的な曲面にどれだけ近く沿うかを決定します。許容誤差を低くすると三角形の数が増え、ファイルサイズも大きくなりますが、最終的なプリントで滑らかな曲線を得るための鍵となります。 しかし、このフォーマットの限界もまた明らかです。ジオメトリ専用であるため、視覚的な情報を一切扱うことができません。モデルに複数の色や異なるマテリアルの仕上げが必要な場合、STLは役に立ちません。また、単位の概念もありません。「1.0」という値が1ミリメートルなのか1インチなのか分からず、モデルをインポートしたら埃の粒ほどのサイズだったり、超高層ビルのようだったりするのは、多くの人が経験する典型的なフラストレーションの原因です。
OBJ：ジオメトリにマテリアルを追加、ただし注意点あり
デフォルトでは、OBJファイルはプレーンテキストのASCII形式で、頂点（v）、テクスチャ座標（vt）、法線（vn）、面（f）を個別の行としてリストアップします。そして、別ファイルのMTL（Material Template Library）ファイルがマテリアルを定義し、JPEGやPNGなどの外部テクスチャ画像へのパスを指定します。この複数ファイル構造が、OBJを扱う上での最大級の頭痛の種です。誰かに.objファイルだけを送っても、色情報が全くないモデルを受け取ることになります。.obj、.mtl、そして参照されているすべてのテクスチャをZipファイルや共有フォルダにまとめるよう注意しないと、受け取った側はのっぺりとした灰色のオブジェクトを眺めるだけになってしまいます。 OBJの救いは、その圧倒的なソフトウェアサポートです。Blender、Maya、Cinema 4D、ZBrush、Rhinoなど、基本的に存在するすべての3Dアプリケーションが読み書きできます。また、STLに対するいくつかの重要な利点もあります。例えば、1つのファイル内に複数の名前付きオブジェクトをサポートしているため、複雑なシーンに適しています。さらに、面を三角形だけでなく、四角形やNゴン（多角形）で定義できます。これは、サブディビジョンモデリングのワークフローを使うアーティストにとっては非常に重要で、最終的なレンダリングやプリントのために三角形化される前に、苦労して作成したきれいなトポロジーを維持できるからです。 ファイルサイズは大きくなりがちです。詳細な建築モデルでは、200MBのOBJ、わずか5KBのMTL、そして800MB相当の高解像度テクスチャといった構成になることもあります。フォーマットに組み込みの圧縮機能はありませんが、一部のツールでは圧縮された.objzという亜種を提供しています。また、OBJはアニメーション、スケルタルリギング、複雑なシーン階層といった現代的な機能を全くサポートしていません。このため、ゲームアセットやインタラクティブな体験には不向きです。静的で視覚的にリッチなモデルを異なるソフトウェア間でやり取りする際には、OBJは今でも必要悪と言えるでしょう。ただし、関連ファイルをすべて同じフォルダに入れておくことを忘れずに。
glTF：3DフォーマットのJPEG
Khronos GroupがglTF 2.0を「3DのJPEG」と呼んでいるのは有名ですが、この例えは完璧です。これは、アクティブな編集のためではなく、効率的な配信と高速な読み込みのために作られたフォーマットです。glTFファイルはJSONベースで、外部のバイナリデータ（.bin）やテクスチャを参照できます。さらに良いことに、.glbという拡張子を持つ自己完結型の単一バイナリファイルにまとめることができます。どのような配布形態であれ、常にGLBを使用すべきです。ファイルは1つで、アセットが欠落する可能性がなく、テクスチャを埋め込むと同等のOBJバンドルよりも20〜40%も小さくなることがよくあります。 glTF 2.0は現代のグラフィックスハードウェアを念頭に設計されており、だからこそ物理ベースレンダリング（PBR）マテリアルを標準でサポートしています。そのコアマテリアルモデルは、Three.js、Babylon.js、Unity、Unrealといったエンジンが直接期待するメタリック・ラフネスのパラメータを使用します。メタリック値を1.0、ラフネスを0.1に設定すれば、説得力のあるクロームになります。メタリックを0.0、ラフネスを0.8にすれば、フラットなマットプラスチックになります。これらのプロパティはファイル内に直接保存されるため、アプリケーションごとに手動でマテリアルを再割り当てしなくても、モデルがどこでも同じように見えることが保証されます。 この点でも、glTFは古いフォーマットをはるかに引き離しています。モーフィングターゲット、スケルタルアニメーション、複数のカメラ、そして完全なシーン階層をサポートします。拡張機能を使えば、ガラス（透過）やワックス状の素材（サブサーフェススキャッタリング）のような高度な視覚効果も追加できます。1つのGLBファイルで、ウェブサイトのプロダクトコンフィギュレーター、モバイルアプリのARプレビュー、ブラウザゲームのキャラクターを動かすことができるのです。 しかし、glTFは繰り返し編集を行うには最悪のフォーマットです。PDFで小説を編集しないのと同じように、glTFで直接モデリングすることはないでしょう。glTFにエクスポートするたびに、ジオメトリは通常三角形化され、複雑なマテリアルシェーダーは単純なPBRテクスチャにベイクされます。このプロセスを何度も繰り返すと、モデルは劣化します。ですから、glTFはウェブやリアルタイムプロジェクトの最終納品フォーマットと考え、常にオリジナルのソースファイルは`.blend`のようなネイティブフォーマットで保存しておきましょう。
直接対決：実践的な比較リファレンス
実際の制作ワークフローで重要となる基準で、3つのフォーマットを比較してみましょう。 **ジオメトリのサポート：** 3つすべてが基本的な三角形メッシュを扱えます。OBJはより柔軟で、四角形やNゴンをサポートしており、モデリングに便利です。glTFはレンダリングに適したデータに焦点を当てており、三角形とラインセット（ワイヤーフレーム用）をサポートします。 **色とマテリアル：** STLは色を表現できず、ネイティブサポートがありません。OBJは外部のMTLファイルを使用して、フォンシェーディングによる基本的なマテリアルを定義します。glTFは、完全なPBRマテリアルモデルがフォーマットに直接組み込まれており、この点では明らかに勝者です。 **テクスチャ：** これもSTLにはありません。OBJは、付属のMTLファイルから参照される外部画像ファイルに依存します。glTFは外部テクスチャを参照するか、GLB形式では直接埋め込むことができます。ベースカラー、ノーマル、メタリック・ラフネス、オクルージョン、エミッシブマップ専用のスロットがあります。 **アニメーション：** これは簡単です。STLとOBJにはアニメーションのサポートがありません。glTFはスケルタルアニメーションとモーフィングターゲットアニメーションの両方をサポートしており、アニメーションコンテンツにはこの3つの中で唯一の選択肢となります。 **一般的なファイルサイズ：** 中程度の複雑さのモデル（約50万ポリゴン、1マテリアル）の場合、バイナリSTLは約25MBになります。同等のOBJは、MTLとテクスチャを含めると、テクスチャサイズに応じて35〜120MBの範囲になります。GLBは、最新の圧縮技術のおかげで、これをわずか8〜25MBにまで縮小できます。 **ソフトウェアの互換性：** STLは3Dプリンティングおよび製造ツールの世界共通言語です。OBJはクラシックな中間フォーマットで、ほぼすべてのデジタルコンテンツ制作（DCC）ツールでサポートされています。glTFは現在、リアルタイムおよびウェブ関連のすべてにおいて支配的な力を持っており、DCCアプリでのサポートも日々向上しています。 **主な用途：** FDM、SLA、またはSLS方式の3DプリンターにはSTLを送りましょう。静的なモデルを異なるモデリングおよびレンダリングプログラム間で移動させるにはOBJを使いましょう。ウェブビューワー、AR/VR、ゲームエンジン、EコマースにはglTF（特にGLB）を選びましょう。 物理的なパーツをプリントするなら、STLをエクスポートします。詳細な建築モデルをレンダリングアーティストに送るなら、OBJが無難な選択です（FBXの方が良い場合もありますが）。製品をウェブサイトやARアプリに掲載するなら、GLBが唯一の答えです。
フォーマット間の変換：うまくいくケース、いかないケース
CocoConvertは、STLからOBJ、OBJからSTL、OBJからglTF/GLB、GLBからOBJといった最も一般的な変換ジョブに対応しています。特にSTLが関わるような、ジオメトリのみを変換する場合は、プロセスは非常に安定しています。STLには三角形データしか含まれておらず、その情報はOBJとglTFの両方のジオメトリセクションにきれいにマッピングされます。 本当の課題は、リッチなフォーマットからよりシンプルなフォーマットへの変換です。テクスチャ付きのOBJをSTLに変換すると、マテリアルとテクスチャのデータはすべて取り除かれます。なぜなら、STLフォーマットには文字通りそれを格納する場所がないからです。CocoConvertはこの点について警告を表示しますが、サポートされていない機能をフォーマットに魔法のように作り出すことはできません。もっとも、ほとんどの人にとっては、3Dプリンター用の生のジオメトリさえ手に入れば十分なことが多いのですが。 OBJからGLBへの変換は人気のあるタスクですが、単純な1対1のマッピングではありません。CocoConvertは、古いフォンベースのMTLパラメータを現代のPBRの同等物に変換しようと試みます。ディフューズカラーはベースカラーになり、スペキュラの指数（MTLファイルの「Ns」値）はラフネスを近似するために使用されます。これは近似であり、完璧な変換ではありません。レガシーなレンダラーで完璧に見えた光沢のあるプラスチックが、PBRビューワーでは少し違って見えるかもしれません。ミッションクリティカルな作業では、元のオーサリングアプリケーション（BlenderやMayaなど）から直接glTFにエクスポートするのが最良の結果をもたらします。これにより、PBRマテリアルの設定を完全にコントロールできます。 また、CocoConvertは現在、アニメーション付きのGLBファイルをサポートしていないことを知っておくことも重要です。スケルタルアニメーションを含むGLBをアップロードしてOBJに変換すると、そのアニメーションデータは失われ、デフォルトポーズの静的なメッシュだけが残ります。私たちはアニメーションに対応した変換に積極的に取り組んでいますが、現時点では、アニメーションアセットを扱うにはBlenderに組み込まれているglTFエクスポーター（ファイル → エクスポート → glTF 2.0）が最も信頼できるツールです。
プロジェクトに適したフォーマットの選び方
ファイルの最終的な行き先が分かっていれば、正しい選択は思ったよりずっとシンプルです。 モデルは3Dプリンターに行きますか？ それならSTLを使いましょう。話はこれだけです。地球上のすべてのスライサーがSTLを好み、ファイルは適度に小さく、機能が不足していてもプリンターはマテリアルをレンダリングしないので問題ありません。ただし、必ずASCIIではなくバイナリSTLをエクスポートし、滑らかな曲線のために弦の許容誤差を十分に小さく設定してください。高さ200mmのモデルなら、0.01mmが良い出発点です。 モデルを異なる3Dモデリングプログラム間で移動させたり、レンダリングアーティストに渡したりしますか？ OBJがクラシックで安全な中間フォーマットです。ただし、規律を守ってください。MTLとすべてのテクスチャファイルを、分かりやすい名前を付けて同じフォルダに保管しましょう。そして、どうかファイル名にスペースを使わないでください。いまだにスペースで問題を起こす古いツールがどれだけ多いか驚くはずです。シーンが複雑な場合は、FBXも検討の価値があります。シーン階層やアニメーションの保持に優れていますが、独自のプロプライエタリな癖もあります。 モデルの行き先はウェブ、ARアプリ、ゲーム、あるいは何らかのリアルタイムビューワーですか？ GLBを使いましょう。これ以上の選択肢はありません。単一ファイルのパッケージはアセットの欠落を防ぎ、PBRマテリアルモデルは視覚的な一貫性を保証し、DracoやKTX2のような最新の圧縮技術を使えば、50MBのアセットを品質の低下をほとんど伴わずに5MBまで縮小できます。これは現代の3Dウェブのネイティブ言語なのです。 クライアントや協力者が必要とするものが分からない場合は、彼らがどのソフトウェアを使っているか尋ねるだけで解決します。その一つの質問が答えを教えてくれます。CuraユーザーはSTLを必要とし、BlenderアーティストはOBJやGLBを扱え、製品ビューワーを構築しているウェブ開発者は間違いなくGLBを要求するでしょう。フォーマットを宛先のツールに合わせることで、全員の頭痛の種を減らすことができます。