GLTF を STL に変換

GLTF は JSON でシーンの構造を記述し、頂点データなどを別ファイルやテキスト内の base64 で持つ形式です。3D プリンター側のスライサーが必要としているのは、その中の三角形の形状だけです。

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

GLTF は仕様上、頂点データを別の .bin ファイルに分けて持つことができます。この変換器はアップロードされた 1 つのファイルだけを見るため、そうした外部参照を解決できず、読み込みを断ります。

このケースに当たった場合、制作ソフト側で GLB として書き出し直すのが確実な回避策です。GLB は頂点データを含めてすべてを 1 つのファイルにまとめる形式なので、外部参照の問題そのものが起きません。

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

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

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

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

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

STL という形式そのものが個別の名前や階層を持てないため、この制約は避けられません。

この変換器が読むのは三角形として定義された面だけで、線分や点、三角形以外の描画方式は読み飛ばされます。ジオメトリを Draco 方式で圧縮した GLTF も、展開する機能がないため読み込みの時点で断られます。

いずれの場合も、制作ソフト側で該当する機能を無効にして書き出し直す必要があります。

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

バイナリかどうかの判定は、ファイル冒頭の文字列ではなく構造そのものを見る方式で行われるため、慣習的に "solid" という文字列で始まるバイナリファイルでも誤判定されません。

複数の GLTF を一度に置いても、順番に処理されて ZIP にまとめて返ってきます。ただし外部の .bin を参照するファイルが混ざっていると、そのファイルだけ処理に失敗します。

アップロードは発生しませんが、1 回にまとめられるのは 100 ファイルまでです。実際の制約は端末の空きメモリーとポリゴン数です。