画像から3Dモデルを作るローカルAIを4つ試した話
画像1枚から3Dモデルを作るローカルAIを、手元のGPUで4種類動かした。
目的は、単に画面で見て面白いかではなく、STLにして次の作業へ渡せるかを見ること。3Dプリント、レーザー用のレリーフ、金属や樹脂の加工前検討に使えるかを分けて見た。
前提
今回試したのはこの4つ。
TripoSG
Hunyuan3D-2mini
Pixal3D
TRELLIS.2
作業フォルダはローカルに分けて置いた。各ツールはローカルGPUで動かし、出力はGLB、その後STLへ変換した。
動作環境
今回の動作環境は以下。
項目 | 内容
OS | Microsoft Windows 11 Home 10.0.26200
WSL | Ubuntu 24.04 / WSL2
GPU | NVIDIA RTX PRO 6000 Blackwell Workstation Edition
VRAM | 97,887MiB
NVIDIA Driver | 596.36
Python | 3.10.20
PyTorch | 2.11.0+cu128
CUDA | 12.8
4種類ともクラウドAPIではなく、ローカルGPUで動かした。初回のリポジトリ取得やモデル取得にはネットワークが必要だが、生成処理そのものは手元のGPUで走らせた。
STL変換と検査には trimesh を使った。GLBを残しつつ、加工側で見やすいようにSTLも出す流れにしている。
見たかったところ
画像to3Dは、見た目だけなら判断しにくい。画面上でそれらしく見えても、STLにした時点で穴が多い、板がねじれる、裏側が破綻する、ということがある。
加工側で見るなら、最低限このあたりを見たい。
STLとして読めるか
面数が極端に少なすぎないか
ファイルが重すぎないか
watertightか
形が「置物」向けか「レリーフ」向けか
今回は同じ椅子画像で4種類を通し、GLBとSTLを残した。その後、葡萄と葉の細かい装飾レリーフでも試した。
椅子を3Dモデルにした出力
最初に作ったのは椅子の3Dモデル。4種類ともGLBまでは出た。そこからSTLに変換して、加工側へ渡せる形かを見た。
ツール | GLBサイズ | STLサイズ
TripoSG | 0.09MB | 0.24MB
Hunyuan3D-2mini | 11.32MB | 31.44MB
Pixal3D | 35.47MB | 46.05MB
TRELLIS.2 | 6.20MB | 8.91MB
この時点で、4つの性格はかなり違った。TripoSGは軽く、形状のラフ確認向け。Hunyuan3D-2miniは重くなるが、椅子としてのまとまりがよかった。Pixal3Dは情報量が多く、TRELLIS.2はGLBで見せる用途に寄っている。
椅子モデルをSTLにした結果
椅子画像で出したSTLはこうなった。
ツール | STLサイズ | 頂点数 | 面数 | watertight
TripoSG | 0.24MB | 2,491 | 5,000 | false
Hunyuan3D-2mini | 31.44MB | 329,678 | 659,356 | true
Pixal3D | 46.05MB | 482,755 | 965,632 | false
TRELLIS.2 | 8.91MB | 93,165 | 186,807 | false
この結果だけ見ると、Hunyuan3D-2miniが一番扱いやすかった。今回の条件では唯一watertightになった。STLとして次に渡すなら、まずここから見る。
TripoSGは軽い。軽い分、細かい形状を期待する用途では物足りない。ラフ形状を早く置きたい時には向いている。
Pixal3Dは情報量が多い。ファイルも重い。見た目の密度は出るが、STLのまま加工側へ持っていくには修復が必要だった。
TRELLIS.2はGLBとして見せる用途に寄っている印象だった。テクスチャ付きの3Dデータとしては見やすいが、STLにしてそのまま次工程へ渡す用途では追加の処理がいる。
4つの使い分け
TripoSGは、軽く形を出す用途。面数を抑えた試作向け。加工の前段というより、アイデア確認に近い。
Hunyuan3D-2miniは、STLへ落とす時の安心感があった。もちろん入力画像次第で崩れるが、今回の椅子では一番素直に扱えた。
Pixal3Dは、細かい形を拾おうとする分、データが重くなる。造形前提なら、メッシュ修復やリダクションを挟む。
TRELLIS.2は、見た目を含めた3Dアセット寄り。STL加工素材としては一段手間を見ておいた方がいい。
葡萄レリーフでは別の問題が出た
次に、葡萄、葉、蔓が入った細長い装飾画像を試した。スプーン柄や細長い金属面へのエンボスを想定した形だ。
Hunyuan3D-2miniでGLBとSTLは作れた。STLも読めた。ただ、結果は「細長い盾のような立体物」に寄った。葉脈や葡萄の粒は残るが、レーザーや浅いエンボスで欲しい高さの整理とは違う。
ここで分かったのは、通常の画像to3Dとレリーフ用の深さマップは別物だということ。3Dモデル生成AIは、物体としての厚みや裏側を作ろうとする。ところがエンボスに欲しいのは、正面から見た白黒の高さ情報だ。
結局、葡萄レリーフはAI 3Dではなく、高さマップ方式でも作った。画像の明度を高さに変換し、STLと16bit深さマップを出す流れにした。
この方式で出したものは以下。
grape_relief_laser_heightfield.stl
grape_relief_laser_heightfield_depth_white_high_16.png
grape_relief_laser_heightfield_depth_black_deep_16.png
grape_relief_laser_heightfield_depth_preview_8.png
grape_relief_laser_heightfield_depth_histogram.png
STLは約45.7MB。深さマップは白が高い版と、黒が深い版の両方を出した。
レーザー用はヒストグラムも見る
レーザーでレリーフを彫る場合、見た目だけで判断すると外す。プレビューがそれらしくても、深さの値が中央に寄っていると、最初の層で面をならすだけになり、細部が出にくい。
今回の高さマップでは、ヒストグラムも出した。
p1: 0.0469
p50: 0.8037
p99: 1.0000
p99 - p1: 0.9531
中央寄り警告: false
中央に寄りすぎていないので、レリーフ加工用の深さマップとしては扱いやすい方向だった。もちろん実機では材料、出力、速度、焦点、回数で変わる。だから最初は小さい端材で極性と深さを見た方が早い。
今回の結論
画像から普通の3Dモデルを作るなら、今回の条件ではHunyuan3D-2miniから見るのが早かった。STLがwatertightになったことが大きい。
一方で、葡萄や葉のような装飾レリーフは、画像to3Dをそのまま使うより、深さマップとして作った方が加工の考え方に合う。AI 3Dは物体を作る。レリーフ加工は高さを作る。この差が大きい。
今後の作業では、用途で分ける。
置物や形状確認: Hunyuan3D-2mini、Pixal3D、TRELLIS.2
軽いラフ形状: TripoSG
彫刻、エンボス、スプーン柄: 深さマップ方式
レーザー用: 16bit PNG、白黒極性、ヒストグラムを必ず見る
画像to3Dは便利だが、加工素材として見るとまだ下処理がいる。使う場面を分けると、かなり現実的な道具になる。
T.Worksの作業記録と販売ページはこちら。
HP: https://thousandthworks.pages.dev
※本記事の内容は執筆時点の情報です。商品仕様・価格は変更される可能性があります。 ※販売ページで扱う工具は、柔らかい金属や工芸素材向けの製作補助具です。日本で通用する貨幣(現行流通貨幣および記念貨幣)の加工は法令で禁止されています。 ※工具の使用は自己責任でお願いします。保護具を必ず着用してください。 ※AI支援で作成しています。誤りがあればコメントでご指摘ください。