クリエイティブ解説
ComfyUIでTRELLIS.2・Pixal3Dをローカル実行する前に|3D生成の違いと注意点

目次
ComfyUIで1枚の画像から3Dモデルを作りたいなら、2026年8月31日のネイティブ統合以降はTRELLIS.2とPixal3Dを最初に比較する価値がある。
以前はTRELLIS.2をComfyUIで使うためにカスタムノードや環境依存のコンパイル済み拡張へ頼る構成が一般的だった。現在のComfyUI中核では、TRELLIS.2とPixal3Dの生成だけでなく、メッシュの再メッシュ化・ポリゴン削減・UV展開・PBRテクスチャの焼き込みまで含む3D処理パイプラインがネイティブ化されている。
ただし、「ネイティブ対応した=軽い」「どのGPUでも快適」という意味ではない。3D生成では拡散モデルだけでなくVAE、画像入力エンコーダー、形状情報推定、メッシュ処理まで動くため、必要VRAMや処理時間は実際のワークフロー条件で確認する必要がある。
入力画像への一致を重視するならPixal3D、汎用性を見るならTRELLIS.2から試す
両者は同じComfyUIワークフロー内で切り替えて使えるが、狙っているものが少し違う。
| 項目 | TRELLIS.2 | Pixal3D |
|---|---|---|
| 主な用途 | 1枚画像から高品質な3D素材を生成 | 入力画像に強く対応した3D素材を生成 |
| 特徴 | 4Bモデル、O-Voxel表現、複雑なトポロジーにも対応 | 画素対応生成で入力視点との対応を重視 |
| テクスチャ | PBRマテリアル生成 | PBRマテリアル生成 |
| ComfyUI | 中核ネイティブワークフロー | 中核ネイティブワークフロー |
| 向いている判断 | 全体の形状・質感を含めた汎用3D生成 | 正面など入力画像との見た目の一致を優先 |
ComfyUI公式はPixal3Dについて、カメラ情報を考慮したな画素対応生成により入力画像との対応を強く保つモデルとして説明している。一方TRELLIS.2は4Bの画像から3Dモデルで、構造、形状、テクスチャを段階的に生成する。
迷うなら、同じ入力画像を2つの処理パイプラインで生成して結果を比べる方が早い。ComfyUIの公式ワークフロー自体が両方を切り替えられる構成になっている。
ネイティブ統合で何が変わったのか
今回重要なのは、モデルそのものが新しくなったことよりもComfyUIでの実行経路が変わったことだ。
Comfy Orgによると、従来のTRELLIS.2周辺ではPyTorchやCUDAの特定バージョン、FlashAttention、疎な畳み込み、nvdiffrastなどのコンパイル済み依存関係が導入障壁になっていた。ネイティブ統合では3D 後処理部分がPyTorchとSciPy中心に再実装され、ComfyUI標準ノードとして扱えるようになった。
これは、カスタムノードの依存関係トラブルを完全になくすという意味ではない。しかし、TRELLIS.2を使うためだけに別のカスタムノード構成一式を構築する必要性は大きく下がる。
ComfyUIを更新し、テンプレートライブラリからPixal3D & TRELLIS.2: Image to Model ワークフローを使うのが基本経路になる。
TRELLIS.2のワークフローは何をしているのか
TRELLIS.2の公式ワークフローは、単に画像を3Dメッシュへ変換して終わりではない。
大まかには次の順番で処理される。
- BiRefNetで背景を除去する
- 疎な構造潜在表現から大まかな3D構造を作る
- 形状段階と高解像度化でメッシュを細かくする
- テクスチャ拡散でベースカラー・金属度・粗さを生成する
- 再メッシュ化、ポリゴン削減、UV展開を行う
- 法線マップと環境遮蔽を含むテクスチャを焼き込みする
最終的にはComfyUIの3Dプレビュー版で確認でき、3D素材として保存できる。
このため、2D画像生成のように「チェックポイントだけのVRAMサイズ」を見ても負荷全体は判断できない。公式ワークフローではTRELLIS.2拡散モデルにINT8 ConvRotチェックポイント、形状/テクスチャVAEにBF16、DINOv3画像入力エンコーダーなど複数構成要素を使う。
Pixal3Dは入力画像との対応を強く意識する
Pixal3DもTRELLIS.2と同じ基本アーキテクチャやVAEを多く共有するが、条件付け方法が異なる。
公式ワークフローではMoGeを使って入力画像から形状情報とカメラ視野of視点を推定し、その情報を画素対応条件付けへ使う。正面画像の見た目を3D側でも崩しにくくしたい場合は、この設計が選ぶ理由になる。
ただし、「入力画像と1:1」という説明を、見えていない裏側まで正確に復元できる意味には広げない方がよい。1枚の2D画像だけでは隠れている面の情報は存在しないため、モデルによる生成や推定は残る。
商品画像、キャラクター、小物など、入力視点の見た目を優先したい用途ではPixal3Dから試し、より自由な形状生成も含めて評価したいならTRELLIS.2と比較するのが分かりやすい。
「一般向けハードウェア対応」から最低VRAMを逆算しない
Comfy Orgは今回のネイティブ実装を一般向けハードウェアで動くローカル3D生成として案内している。
一方、公式ドキュメントには「RTX 3060なら何GB」「16GBなら必ず動く」といった普遍的な最低VRAM値は示されていない。
したがって、GPUを選ぶときは次を分けて確認したい。
- 拡散モデルを読み込んだときのVRAM使用量のピーク
- 形状 / テクスチャVAE実行時のVRAM使用量のピーク
- 生成解像度
- メッシュ精細化の設定
- システムRAM使用量
- 1素材あたりの処理時間
- ComfyUIバージョンとPyTorch環境
VRAM不足が出た場合は、ComfyUIのCUDA out ofメモリ対処と同じように、どの段階で不足しているかを切り分ける必要がある。
3D生成目的でGPUやBTOを買うなら、モデルが起動する最低線だけではなく、同じ素材を何度も試行できる速度と余裕まで見る方がよい。
商用利用では「モデルのライセンス」と「実行処理パイプラインの依存関係」を分ける
今回のネイティブ統合で見逃せないのがライセンス面だ。
Comfy Orgは、TRELLIS.2の元の参考処理パイプラインで使われていたNVIDIAのnvdiffrast / nvdiffrecについて、用途制限を含むライセンスが商用利用上の問題になり得たと説明している。ネイティブ統合ではその依存を外し、生成物を商用利用しやすい経路へ整理したとしている。
ただし、これは「3D生成なら今後すべて無条件に商用利用できる」という意味ではない。モデル重み、コード、追加LoRA、入力素材などのライセンスは別々に確認する必要がある。
公開・販売を前提に使う場合は、AIモデルのライセンスをダウンロード前に確認する手順と同じように、使う配布ファイルごとの条件を残しておく方が安全だ。
今から試すならこの順番がよい
最初から最大解像度へ上げる必要はない。
まずComfyUIを最新化して公式テンプレートを読み込み、1枚の入力画像を用意する。同じ画像でPixal3DとTRELLIS.2をそれぞれ1回生成し、次の項目を記録する。
入力画像:
ComfyUI version:
GPU:
system RAM:
pipeline: Pixal3D / TRELLIS.2
resolution:
生成時間:
peak VRAM:
形状の破綻:
入力画像との一致:
texture品質:
meshの扱いやすさ:
この比較でPixal3Dの一致度が十分なら、そのままそちらを基準にする。TRELLIS.2の方が全体形状や質感で良ければ切り替える。
3D生成では「どちらがベンチマークで上か」より、入力画像・用途・メッシュの後処理まで含めた結果の方が重要だ。
選ぶときの判断
TRELLIS.2とPixal3Dのネイティブ統合は、ComfyUIの小さな機能追加ではない。
これまで3D生成を避けていた理由が「カスタムノードの導入が重い」「CUDA拡張機能が壊れる」「ライセンスの依存関係が分かりにくい」だった人にとっては、試す条件がかなり改善した。
一方で、公式情報だけでは一般向けGPU別の実測VRAMと速度はまだ十分ではない。現時点では特定GPUを「3D生成に最適」と断定するより、公式ワークフローを基準にVRAM使用量のピークと生成時間を実測し、その結果をGPU購入判断へつなげるのが妥当だ。
1枚画像からローカル3D素材を作りたいなら、まずPixal3DとTRELLIS.2を同一画像で比較する。 これが今のComfyUIでは最も分かりやすい入口になる。
まとめ
- TRELLIS.2とPixal3DはComfyUI中核でネイティブに扱えるようになり、従来の専用カスタムノードやコンパイル済みCUDA拡張機能への依存を減らせる
- TRELLIS.2は汎用的な高品質画像から3D、Pixal3Dは入力画像との画素位置合わせを重視する方向が明確
- どちらも形状生成だけでなくPBRテクスチャとメッシュ後処理まで1つのワークフローで扱える
- ComfyUI公式は一般向けハードウェアでのローカル実行を案内しているが、固定の最低VRAM値は示していないためGPU容量を断定しない