STL を 3MF に変換

STL は 1987 年に 3D Systems が公開した形式で、三角形しか持たないと割り切っています。単位もなく、色もマテリアルも名前もパーツの区別も頂点の共有もありません。3D プリントの世界がそのあとに付け加えたもの——単位の慣例、複数パーツのプレート、パーツごとの設定——はすべてファイルの外側で、開いた側が組み立て直しています。

2015 年に公開された 3MF は、それらをファイルの内側に持たせました。単位は宣言され、オブジェクトは分かれ、色とマテリアルには置き場所があり、全体がマニフェストを持つ OPC パッケージです。STL を変換すると、パッケージ化と単位の宣言はすぐに得られます。ただし、もともと記録されていなかった色やパーツをこの変換が作り出すことはありません。

STL はすべての三角形を、共有のない独立した 3 頂点として保存します。立方体——12 個の三角形——は、本来 8 個で足りるはずの位置を 36 個の頂点レコードとして持ちます。これは特定の書き出しツールの癖ではなく、形式そのものの性質です。

変換ではこれを溶接します。座標を小数点以下 6 桁で丸めてキーを作り、同じ位置にある三角形の角をすべて 1 個の共有頂点にまとめます。6 桁というのは印刷の許容誤差よりはるかに細かく、隣り合う三角形が浮動小数点の最後の 1 ビットで食い違う程度の誤差よりは十分粗い値です。こうして本物のインデックス付き曲面が生まれ、STL では全ての辺が境界だと報告されるマニフォールドチェックが、3MF では意味のある答えを返すようになります。

3MF の resources には 1 個のオブジェクト、build には 1 個のアイテムだけが入ります。これは簡略化ではなく、STL には三角形が何個の独立した立体を成しているかを言う手段がそもそもないためです。連結性を解析して分割するのは変換ではなくモデリングの判断になってしまいます。

STL が複数の分離した殻を含んでいる場合、たいていのスライサーには「パーツに分割」のようなコマンドがあり、インポート後に連結性から見つけ出してくれます。ファイル自体にパーツ分けを記録させたいなら、元をグループを持つ OBJ や複数メッシュを持つ glTF にする必要があります。

3MF は model 要素に unit="millimeter" を書き込み、座標はそのまま渡されます。厳密には、変換は元のファイルが宣言していなかった単位を主張していることになります。ただしこれは 3D の変換群の中でもっとも安全な部類の主張です。3D プリントの世界は 30 年間 STL の数値をミリメートルとして扱ってきており、あらゆるスライサーがそのように読み込みます。

得られるものは、その前提が前提でなくなることです。ミリメートルと書かれた 3MF は PrusaSlicer、Cura、Bambu Studio、Microsoft 3D Builder のいずれでも、独自の慣例を適用されることなく同じ大きさで読み込まれます。注意が要るのはインチ単位で書き出された CAD の STL で、これはもとから 25 分の 1 の大きさで読み込まれていたものが、単位の裏付きでそのまま小さく読み込まれることになります。

バイナリ STL の各三角形レコードは、仕様上は未使用の 2 バイトの属性フィールドで終わります。ここに VisCAM・SolidView の流儀と Materialise Magics の流儀という 2 つの異なる慣例が、それぞれ三角形ごとに 15 ビットの RGB 色を詰め込む形で広まりました。どちらも STL の一部ではなく、どのツールがどちらを使っているかを見分ける方法は共通していません。

この読み込み処理は各 50 バイトのレコードから面の法線 12 バイトと頂点データ 36 バイトだけを取り、残り 2 バイトには触れません。そのため色付きの STL は、静かに色のない 3MF になります。3MF には本物の色のモデルがあるので保持できますが、2 つの矛盾する慣例のどちらでビットパターンが作られたかを推測することは、変換が代わりにやるべき判断ではありません。

先頭の単語ではなく、計算で判定します。「solid で始まっているか」という一見わかりやすい判定は誤りです。バイナリ STL の 80 バイトのヘッダーには何でも書けるため、多くの書き出しツールがそこに solid という単語を入れています。この判定で失敗したファイルは、解析できたように見えて何も出力しません。

バイナリ STL はヘッダーに書かれた三角形数について、正確に 84 + 50n バイトになります。この数に偶然一致することはまずありません。長さが一致すればバイナリとして読み、一致しなければテキストとして頂点行を走査します。どちらの経路も同じ溶接済みモデルにたどり着きます。

STL 側は正確で確認しやすい数字です。10 万三角形のモデルは、形にかかわらず必ず 5,000,084 バイトになります。この予測しやすさは STL が本当に得意なことですが、同時に幾何情報に対してファイルが不必要に大きい理由でもあります。バイト数の 4 分の 3 は重複した座標です。

3MF は溶接された頂点をそれぞれ 1 個の XML 要素として持ち、三角形は 3 個の整数参照として持ちます。それを ZIP パッケージの中で deflate 圧縮します。冗長なマークアップは圧縮によく応じ、頂点の共有によって圧縮の前段階ですでに重複が取り除かれています。結果はモデルによって変わりますが、印刷向けの一般的な形状では、たいてい元の STL より確実に小さくなります。

ZIP の中に 3 つの要素——.model と .rels の内容種類を宣言する [Content_Types].xml、モデルへの関係を 1 個だけ持つ _rels/.rels、3MF のコアな名前空間でジオメトリを保持する 3D/3dmodel.model——が入っています。この構造が、DOCX や XLSX と同じ OPC パッケージという規約に沿ったものにしています。

これはモデルファイルであり、プロジェクトファイルではありません。印刷設定もフィラメントの割り当てもプレート配置もサムネイルもありません。それらはジオメトリの一部ではなく、各スライサー固有の拡張だからです。お使いのスライサーは選択中のプロファイルを適用し、より豊富な独自の 3MF はそのあと自分で保存できます。

穴は穴のまま、裏返った三角形は裏返ったまま、自己交差も内部の壁も微小な面もそのまま残ります。ここでは一致する頂点の統合以外、トポロジーの検査は一切行われません。STL としてスライサーのチェックに失敗したメッシュは、同じメッセージで 3MF としても失敗します。

変わるのは、頂点が共有されていないことによるエラーの種類だけです——これはすべての STL が構造的に抱えている問題です。溶接のあとは、幾何学的に閉じた面がトポロジー的にも閉じた面になるので、Blender や Meshmixer、スライサーの修復ツールが、3 万 6 千個のばらばらな三角形ではなく、意図したメッシュに対して働くようになります。それだけで修復作業の時間は短くなります。