GLB を STL に変換

GLB は Web や 3D 制作アプリでよく使われるモデル形式で、色やテクスチャ、アニメーションまで持ち運べます。3D プリンター側のスライサーが必要としているのは、その中の三角形の形状だけです。

この変換は GLB から三角形の位置情報だけを取り出し、STL としてスライサーに渡せる状態にします。

この変換が読み書きするのは、三角形がどこにあるかという情報だけです。マテリアル、テクスチャや UV 座標、頂点や面の法線、頂点カラー、カメラやライト、アニメーション、スキン、モーフターゲット、シーングラフそのものは、変換の対象に含まれていません。

これは処理が省略されているのではなく、中間で扱うデータの形自体に、色や UV を置く場所がないためです。

GLB のノードが持つ移動・回転・拡大縮小の情報は、変換の過程で各頂点の座標に直接反映されます。シーン上でどこに配置されていたかという情報は、座標そのものに変換されて残ります。

これにより、シーン内で複製・配置されていたオブジェクトも、それぞれ独立したジオメトリとして正しい位置に出力されます。

GLB が複数のメッシュ、複数のパーツで構成されていても、STL に書き出す際にはすべてが 1 つのメッシュにまとめられます。パーツごとの名前も、この時点で失われます。

部品ごとに分けて後から扱いたい場合、STL という形式そのものが個別の名前や階層を持てないため、この制約は避けられません。

この変換器が読むのは三角形として定義された面だけです。線分や点、三角形以外の描画方式で定義された部分は読み飛ばされます。

一般的な 3D 制作ソフトで書き出された GLB は三角形化されていることが多く、通常の用途で問題になることはまれです。

GLB の中にはジオメトリを Draco という方式で圧縮しているものがあります。この変換器は Draco 圧縮を展開する機能を持たないため、そうしたファイルは読み込みの時点で断られます。

その場合は、制作ソフト側で Draco 圧縮を無効にした状態で書き出し直す必要があります。

この変換器が書き出す STL は常にバイナリ形式です。テキストベースの ASCII 形式の STL を必要とするソフトには、後から別途変換が必要になります。

ファイル形式が binary か ASCII かの判定は、多くのソフトが冒頭の文字列で行いますが、この変換器のバイナリ判定はそれとは別の、ファイルの構造そのものを見る方式を使っています。

複数の GLB を一度に置いても、順番に処理されて ZIP にまとめて返ってきます。アップロードは発生しませんが、1 回にまとめられるのは 100 ファイルまでです。

ポリゴン数の多いモデルほど処理に時間がかかるため、大きなファイルを多数まとめて置く場合は端末の性能に応じて分けることを勧めます。