OBJファイルとは

OBJ はプレーンテキスト形式です。どのエディターでも開けます。 ピクセルではなく図形と座標を保存するので、どんな大きさでも鮮明なままです。看板の大きさまで引き伸ばしたロゴでも、失うものはありません。 プログラム間のデータ受け渡しと編集のために使われます。

拡張子は .obj、正式名称は Wavefront Object です。ただしどちらも、そのファイルが中に何を持てるかほどには多くを語りません。このページの残りは、その中身についての話です。

Wavefront Technologies が 1992 年に公開しました。

これだけ長く読まれ続けてきた形式なら、10 年後に取り出したいものを預けても大丈夫です。

仕様書がそのまま公開されているので、中身を推し量るのではなく文書を読んで実装できます。この形式が数多くのプログラムに載っているのはそのためであり、20 年前に書かれたファイルが今も開けるのもそのためです。ただし「仕様が公開されている」ことと「使用料が要らない」ことは別の話です。中でコーデックを包んでいる形式では、特許のライセンスは仕様書が答えていない別の問題として残ります。

OBJ ファイルは中身をそのまま保存します。保存し直しても何も変わらないので、開いて、直して、また保存する——それを何度繰り返しても劣化は積み上がりません。これが、渡すための形式ではなく作業のための形式である理由です。

Blender、MeshLab、Mayaが読めますし、同じ種類のプログラムならたいてい読めます。

ファイルが開かないとき、形式が悪いことはめったにありません。たいていはプログラムのほうが形式より古いのです。もっと古い形式に変換してしまうのが確実な逃げ道で、このサイトの残りの部分はそのためにあります。

これを読めるブラウザーはありません。

これを変換するいちばんよくある理由がこれです。形式が悪いのではありません。ファイルを見せたい場所が、それを読めないというだけのことです。

OBJ は、開いて手を入れるために作られています。作業が続いているあいだはこの形式でファイルを持ち、完成したものが必要になるたびに、ここから書き出してください。

OBJ は 1992 年から 3D の最大公約数であり続けています。あらゆるモデリングソフト、あらゆるゲームエンジン、あらゆるレンダラー、あらゆるオンラインビューアーがこれを読み込め、これはほかのどのメッシュ形式にも当てはまりません。それだけで生き残っています。仕様は三十年前のもので、ほかのすべてが持つ機能を欠いていますが、相手がそのファイルを開けるかどうかが問われているとき、そんなことは関係ありません。

プレーンテキストであることも、この魅力の半分です。頂点は v で始まり三つの数値が続く行、面は f で始まりその頂点を結ぶ行です。テキストエディタでモデルを開いて理解できるというのは、3D 形式としては珍しく、口にする価値があります。

OBJ が持つのはジオメトリだけです。色やマテリアル、テクスチャは、OBJ が冒頭数行で名前を挙げる別の .mtl ファイルの中にあり、テクスチャの画像はさらに別のファイルで、MTL が名前を挙げています。

だからモデルは実質フォルダーです。.obj が一つ、.mtl が一つ、そして何枚かの画像ファイル。.obj だけを送る ── 見覚えのある名前のファイルだから、人はよくそうします ── と、受け取った側にはテクスチャのない灰色のジオメトリしか見えません。これはこの形式でいちばんよくある問題で、直し方はすべてを送るか、フォルダーごと ZIP にすることです。

テクスチャは平らな画像で、モデルはその画像のどの部分が面のどこに属するかを言わなければなりません。それが UV 座標で、頂点ごとにひと組ずつある別の数値の組で、メッシュを画像の上に写像します。

これは OBJ の中に保存されているので、マテリアルが渡らなくても旅を生き延びます。モデルがテクスチャなしで届いたときこれは知っておく価値があり、UV が無事なら、テクスチャを付け直すのはどのモデリングソフトでも二分の仕事です。UV を持たずに書き出されていた場合、誰かがメッシュを改めて展開し直さなければならず、そちらは本物の手間です。

OBJ の中の数値には単位が付いていません。幅 10 の立方体は 10 ミリメートルかもしれず、10 センチメートルかもしれず、10 メートルかもしれず、ファイルはそれを言いません。各ソフトウェアが読み込み時に自分の前提を当てはめるので、モデルは極小で届くこともあれば、建物ほどの大きさで届くこともあります。

向きについても同じです。あるソフトウェアは Y を上として扱い、あるソフトウェアは Z を上として扱い、この形式はどちらの立場も取りません。だからモデルは横倒しで届くことが日常的にあります。どちらの問題も、読み込み時に拡大縮小と回転をすれば数秒で直り、何かを測定したり印刷したりする前に確かめておく価値があります。

すべての座標を十進のテキストとして保存するのは、かなりの容量を消費します。同じメッシュをバイナリの STL や PLY にすれば、たいてい三分の一から五分の一のサイズになり、OBJ として書き出された精密なスキャンは何百メガバイトにも達することがあります。

また同じ理由で非常によく圧縮されます。ZIP 化した OBJ は元のほんの一部になります。十進のテキストは非常に冗長だからです。モデルの転送やアーカイブには、ZIP 化はほぼ無料で、この形式に対する反対理由の多くを取り除いてくれます。

アニメーションなし、リギングやボーンなし、シーンの階層なし、カメラやライトなし、そして現代的なマテリアルモデルもありません。MTL 形式は 1990 年代初頭のシェーディングの考え方を記述していて、メタルネスやラフネスのマップには居場所がなく、慣習として渡されるにすぎません。

これが glTF が存在し、ゲーム向けのパイプラインが代わりにそれを使う理由です。OBJ は静的な形状を一つのソフトウェアから別のソフトウェアへ渡すためのもので、そこに関してはほかの何より優れています。リギングされたキャラクターやアニメーションのあるシーン、物理ベースのマテリアルには、この形式は間違った選択です。

スライサーは OBJ を受け付けます。ジオメトリはきれいに STL に変換されます。STL は OBJ が表現できるものの厳格な部分集合 ── 三角形だけ ── だからです。問題になるのはメッシュが水密かどうかです。すべての辺がちょうど二つの面に共有され、穴がなく、反転した法線もないこと。

レンダリング用に作られたモデルはたいていそうなっていません。厚みのない面はビューポートでは完璧に見えても印刷不可能です。スライサーはその内側が何かを判断できないからです。印刷の前に修復ツールにファイルを通しておけば、たいていの問題を捕まえられ、プリンターで四時間かけて問題に気づくより速く済みます。