scenario-3d

Scenario 3D アセットのワークフロー

概要

Scenario は、画像生成に使われるものと同じ MCP 生成ループを通じて、テキストから 3D、画像から 3D、3D から 3D のモデルを実行します。最も信頼性の高いパイプラインでは、まずコンセプト画像を生成し、それを画像から 3D に変換するモデルに渡します。テキストから 3D への直接生成（txt23d）も可能ですが、画像から 3D への変換のほうがカタログが充実しており、アートディレクションをより細かく制御できます。モデルファミリーごとの仕様は、scenario-meshy、scenario-rodin、scenario-sparc3d です。歩行可能なシーンとガウシアンスプラットには、scenario-3d-worlds を使用します。完成したメッシュやシーンの PBR リテクスチャリングには、scenario-patina-retexture を使用します。Blender 内で作業する場合は、Scenario for Blender 拡張機能を通じて scenario-blender を使用します。接続と基本的なループについては、scenario スキルを参照してください。ここに記載された関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください（npx skills add scenario-labs/skills --skill <name>）。無人で処理する場合は、ツールスキーマに基づいて進め、不足があることを明記してください。

クイックリファレンス

手順	ツール	備考
3D モデルを探す	能力とユーザー自身の言葉を指定して recommend を使用（モデル名で探す場合は search）	能力：txt23d、img23d、3d23d
入力を確認する	model_schema_get	model_run の前に必ず呼び出してください
生成する	model_run	参照画像はアセット ID として渡してください
待機する	jobs_wait	アセットを含まずに返された job_id（待機がタイムアウトした場合の in_progress、または wait=false の場合の queued や in-progress）はすべて job_ids に指定してください。ループ内で job_get をポーリングしないでください
プレビューする	asset_display	MCP App ホスト上でインタラクティブな GLB/FBX/VOX/OBJ ビューアーを使用できます
ダウンロードする	asset_download	URL が返されます。curl -L で保存してください

作業例：コンセプト画像からゲーム用メッシュへ

「3D の宝箱プロップを作成する」場合の現実的な手順です。手順 1 の前に、後続の各手順（手順 2 と、リギングまたは再テクスチャリング）について recommend を実行してください。これはプランの確認です。requires_plan_upgrade と表示された項目は、その前の手順の料金が支払われた後にのみ、プラン名を示す 403（ModelAccessRestrictedError）で失敗します。そのため、先にアップグレードするか、別のモデルを選んでください。

1. コンセプトを生成します。ユーザー自身の言葉を prompt として recommend を使い、テキストから画像を生成するモデルを選びます。次に、無地の背景に被写体が 1 つだけ中央に配置されるよう記述したプロンプトで、model_schema_get と model_run を実行します。ユーザーが参照画像を持っている場合は、それを upload_asset し（マルチパートの場合は upload_asset_complete も実行）、代わりにそのアセット ID を渡します。
2. ユーザー自身の言葉を prompt として、capability="img23d" を指定して recommend を実行します。現在利用できるモデルには、Hunyuan 3D、Meshy、Tripo、Trellis の各ファミリーと、Scenario 独自の LLM ベースの 3D 生成モデルである GPT-6 Astra 3D、Claude Opus 5.5 3D（執筆時点では 2 つのうち低価格のモデルであり、dry_run で両方を比較してください）が含まれます。これらは 1～8 枚の写真またはレンダリング画像から 1 つのオブジェクトを再構成し、名前付きパーツとパーツごとの PBR マテリアルを備えた編集可能なメッシュを生成します。これらのモデルはプロップやハードサーフェスの被写体に適していますが、キャラクターには適しておらず、画像が必要です（執筆時点では、プロンプトだけの場合は 400 が返されました）。価格は buildEffort を standard から high（デフォルト）、さらに maximum へ上げるほど高くなります。faceBudget は、エクスポート時の納品三角形数の上限です（ゲーム用アセットでは 10k～50k。デフォルトは細部を維持する設定であり、ゲーム用ではありません）。結果を変更するには、メッシュを編集してください（「メッシュの調整」を参照）。
3. 選択したモデルに対して model_schema_get を実行します。3D のスキーマはモデルによって大きく異なり、単一画像と複数視点の配列、ポリゴン数の目標、PBR の切り替え、トポロジーの選択肢などがあります。
4. parameters={"image": "asset_xxx", ...} を指定して model_run を wait=false で実行します（バッチの料金を見積もるには、先に dry_run=true を指定します）。次に、job_ids=["<job_id>"] を指定して jobs_wait を実行します。タイムアウトした場合は、返された pending_job_ids を job_ids として指定し、再度呼び出してください。後続の手順（リギング、再テクスチャリング）は、入力メッシュが存在するまで dry_run に渡すペイロードがありません。まず recommend で見積もりを確認し、実際のアセットを使って dry_run で再見積もりしてから開始してください。プレースホルダー ID を使って dry_run を実行してはいけません。ファイル ID はプランアクセスの確認より先に解決されるため、呼び出しは 404 を返し、料金もアクセス権も確認できません。
5. 出力された asset_id で asset_display を実行してプレビューし、次に format: "glb" を指定して asset_download を実行し、curl -L -o chest.glb "<url>" でエンジンにインポートします。format が glb、fbx、obj の場合、asset_download はメッシュを変換します。省略した場合は、保存されている元のファイルを返します。LLM ベースのモデルでは、元のファイルは Blender ファイルです。glTF インポーターのない Unity プロジェクトでは fbx を指定し、GLB も保存しておいてください。執筆時点では FBX に埋め込まれる画像は 2 枚だけだったため、すべての PBR マップが含まれていない可能性があります。

複数視点モデルは、同じ被写体を異なる角度から撮影した複数の画像を受け付けます。画像の枚数と順序はモデルごとに異なるため、どちらも model_schema_get で確認してください（通常、1 枚目は正面図です）。

テクスチャとライティングの制御

いくつかの画像から3Dを生成するモデルファミリーでは、テクスチャとジオメトリが分かれており、それぞれの設定は model_schema_get を1回呼び出すだけで確認できます。見た目を約束する前に、設定を確認してください。Tripoメンバーでの作成時の例を紹介します。

• texture: false を指定すると、テクスチャのない素のメッシュが返され、cost_impact フィールドも含まれます。ユーザーがDCCでテクスチャを付ける場合に、コストを抑えられる方法です。textureQuality（fast、standard、detailed、extreme）も料金に影響します。テクスチャのバージョン選択欄を空のままにすると、プロバイダーのデフォルトが使われます。
• delight は、参照画像に焼き込まれたライティングや影を取り除き、ユーザーのエンジンでメッシュに適切なライティングが適用されるようにします。デフォルトはオンです。手描きのプロップのように、塗りの陰影がアートスタイルになっている場合に限り、オフにしてください。どちらの場合も、エクスポートされるのはライティングが適用されたマテリアルです。そのため、エンジンで再ライティングをまったく行わない場合は、インポート時にユーザーがアンリットシェーダーを設定します。
• pbr フラグの説明では、デフォルトのPBRオンではテクスチャのパラメーターが無視されると記載されていました。そのメンバーでは、ユーザーが指定したテクスチャ設定を反映するには pbr: false が必要です。選択したメンバーの説明を確認し、どちらの設定が優先されたかを伝えてください。
• ジオメトリとテクスチャには別々のシード（seed、textureSeed）を使います。seed と画像を固定し、textureSeed だけを変えると、同じ形状のテクスチャ違いを生成できます。
• autoSize は出力を実寸のメートル単位にスケーリングする設定で、デフォルトはオフです。実寸スケールでエンジンにインポートするには true に設定してください。そうしない場合、メッシュは元のサイズのままです。アセットの dimensions には引き続き、単位正規化されたメッシュ（最長辺が1.0）が表示されます。メートル単位のスケールはGLBのノードスケールに含まれているため、dimensions の値だけでは失敗したとは判断できません。

結果の確認

MCP Appsに対応していないホストでは、asset_display ビューアーの代わりに app_url ダッシュボードへのリンクが表示されます。ビューアーのキャプチャボタンは、アプリ専用ツールの capture_3d_view を呼び出します。このツールは現在のカメラビューを新しい画像アセットとしてアップロードし、asset_id を会話に投稿します。このキャプチャを、後続の生成や類似性の search の参照として使ってください。capture_3d_view は自分で呼び出さないでください。ビューアーしか持っていないPNGキャンバスデータが必要です。

メッシュの調整

3Dから3Dへのユーティリティでは、再テクスチャリング、リメッシュ、UV展開、パーツのセグメンテーションに対応しています。recommend に capability="3d23d" と、ユーザー自身の言葉で操作内容を指定してください。多くの場合、ソースの asset_id は kind: "3d" のファイルフィールドに渡します。通常は model（ほかに mesh、file3d、sceneFile）という名前です。400 エラーの Input model is required または Provide a reference image or a 3D model は、メッシュを別の名前のフィールド（画像フィールドや URL など）に渡していることを示します。ツールが別のものを要求しているわけではありません。

ステップ2のLLMベースの機能は、既存のメッシュ、プロップ、キャラクターも編集します。sceneFile にはその asset_id（同じ形式で返される任意の3Dモデル）を渡し、images は空のままにして、prompt に変更内容を指定します。buildEffort は対象物ではなく変更内容に合わせます（色変更なら standard、パーツの追加や形状変更なら high または maximum）。GPT-6 Astra 3Dの説明には、Mixamo形式のリグ、ARKitのフェイスシェイプ、アニメーションループ、UVの再展開、モジュラーキットも記載されていたため、これらの recommend 呼び出しでも候補になります。作成時点では recommend に編集料金は表示されませんでしたが、料金はメッシュではなく buildEffort に応じて決まるため、プロジェクト内の任意のメッシュを使って dry_run を実行すれば、最初の有料ステップの前に料金を確認できます。色変更ではすべてのパーツ名と面数が維持されました。形状変更には上限がなく（faceBudget は無視されます）、三角形が4,817個の猫のメッシュが788,954個になったため、エンジンに渡す前にリメッシュする計画を立ててください。置き換えたマテリアルの名前は以前のままです。新しい名前が付くのは追加したパーツだけです。編集は生成によるものです。プロンプトで指定していない部分をソースと比較してください。

完成したメッシュをパーツに分割する機能は競合がある分野のため、引き続き recommend で候補を選びます。作成時点では、複数のベンダーが粒度を調整できるメッシュセグメンテーションを提供しており、分割とPBR再テクスチャリングを組み合わせたものもありました。また、画像からパーツを作る機能は、画像をもとにパーツを生成します。見栄えのよいメッシュが、そのままゲームで使えるとは限りません。パーツの分離、関節の配置、マテリアル、アニメーションはそれぞれ別の工程です。また、両方の上限を提供する機能では、ポリゴン数の上限がトポロジーによって異なります（ある機能では、四角形ポリゴンの上限が三角形ポリゴンの上限を大きく下回っていました）。そのため、対応数を約束するのではなく、スキーマでスライダーの max を確認してください。名前の付いたプロバイダー機能は有効な search 対象ですが、検索結果が空だったり、ある機能のボディプランの列挙値が見つからなかったりしても、プラットフォーム全体でその機能が存在しないとは言えません。ヒンジ付きプロップなど、満たされていないニーズには、そのニーズを指定して recommend を使い、返されたスキーマを確認してください。該当する機能がなければ、プロバイダー自身のサイトを根拠に呼び出し方を作り上げず、確認したモデルでは未検証であると報告してください。

ゲームで使えるデータを作る段階的なチェーン

1回の画像からの3D生成では、ジェネレーターが選んだUVにテクスチャがベイクされます。そのため、エンジンに渡すメッシュは通常、実行ごとに処理を進め、各出力の asset_id を次のツールの kind: "3d" フィールドに渡します。まずジオメトリを生成します（対象の複数アングルがある場合はマルチビュー対応のものを使います。スキーマで指定できる場合は、テクスチャは後で適用するため texture: false にし、pbr のデフォルト値がテクスチャ設定を無視するメンバーでは、併せて pbr: false にします）。次にUVを展開し、展開済みのメッシュにプロンプト、画像、またはスタイル参照を使ってテクスチャを適用し直し、最後に、実際に出荷するトポロジーにリグを設定します。UVを再構築する設定がないか、各再テクスチャリングのスキーマを確認してください。その設定を使うと、UV展開が失われます。また、同じ pbr のデフォルト値にも注意してください。作成時点では、TripoのテクスチャリングメンバーはデフォルトでPBRに設定されており、テクスチャのオプションが無視されました。スキーマにUVについての記載がない場合は、既存のUVを保持する設定が明示されたメンバーを優先してください。最初のステップ以降は各ステップで 3d23d の recommend の選択肢（「メッシュの調整」を参照）を使い、それぞれ別途料金の発生する実行が必要です。そのため、実際の入力で dry_run を実行してから開始してください。チェーン処理の前に、入力の上限を確認してください。作成時点では、あるUV展開ツールが最大30,000面のメッシュに対応していました。スキーマに設定項目がある場合は、それに合わせてジェネレーターの面数上限を下げてください（Tripoのマルチビューメンバーには faceLimit と smartLowPoly トポロジー切り替えが用意されていました）。または、先にリメッシュして面数を減らしてください。次の処理に渡す前に、各出力を asset_display で確認してください。ホストにビューアーがない場合は、asset_get で面数、UV、dimensions を読み取り、ステップごとに比較します。また、レコードのサムネイルアセットも確認してください。ジョブ完了からサムネイルの更新まで、数秒かかる場合があります（hasUVs が証明するのはUVが存在することだけで、レイアウトがきれいであることではありません。UV展開ツールの「albedo」PNGも、アトラスではなくプレビューの場合があります）。暗く見える面や裏返しに見える面は法線が反転しており、後続のステップにも引き継がれます。また、同じベンダーのチェーン内でも、各ステップでスケールやピボットが変わる場合があります（前述の autoSize を参照）。そのため、リグを設定する前に、DCCで両方を確認してください。1つのステップから兄弟形式のファイル（GLBとOBJなど）が返された場合は、次のスキーマで別の形式が要求されているか、メッシュがクワッドである場合を除き、GLBを次の処理に渡してください。クワッドはFBXのままにします（「リギングとアニメーション」を参照）。GLBがない場合は、次のスキーマでサポートされていればOBJまたはFBXを渡します（dry_run はファイル形式を確認せずに料金を見積もる場合があるため、対応形式は実際の実行で確認してください）。それ以外の場合は、asset_download の format で変換してください。法線、原点、名前を手作業で修正するのはDCCでの作業であり、MCP呼び出しではありません（scenario-blender-expert スキルでBlenderを操作できます。このスキルはローカルにインストールするもので、MCP経由ではインストールされないため、skill_get では取得できません）。

リギングとアニメーション

リギングは、完成したメッシュに対して行う独立した 3d23d ステップであり、ジェネレーターのフラグではありません。その機能を備えたものを recommend で選び、ユーザー自身の言葉で示されたリギングの要望と組み合わせます。

ボディプランによってモデルを選びます。ヒューマノイドモデルはメッシュ以外にほとんど入力を必要とせず（モデルに応じて、正面を向かせる指示やおおよその身長を指定します）、二足歩行のスケルトンを推定します。二足歩行以外の作業では、rigType を公開しているモデルを使います。その値には quadruped、hexapod、octopod、avian、serpentine、aquatic があります。静的な小道具にはリギングするボディプランがありません。recommend が ask_user を返す場合は、パーツ分割のほうが適したステップです。

リギングするキャラクターは、コンセプトの段階からその用途を考慮して作成します。リガーはポーズから関節を推定するため、コンセプトはTポーズかAポーズ（全身、正面向き、腕が胴体から離れている、背景は無地）で生成します。ユーザーがクワッドを希望する場合、スキーマでクワッドトポロジーを提供する画像から3Dへのモデルを選び、それを設定します。デフォルトは三角形です。Tripo P2および3.1のメンバーでは、作成時に面数の上限を低くした quad スイッチを使います。一方、scenario-rodin と scenario-meshy では、それぞれのファミリー独自のコントロールが指定されています。クワッド出力はFBX形式で、glTFは三角形のみを保存します。asset_download の format: "glb" で変換するか、GLBのみを受け付けるステップに渡すと、再び三角形化されます。FBXを保持し、ファイルフィールドにFBXが記載されたメンバーでリギングし、クワッドであることを約束する前に、DCCですべての出力の面タイプを確認してください。GLBで返されたリグは三角形化されています。クワッドのFBXも一緒に納品し、その旨を伝えてください。

出力が使えるかどうかは、次の3つのスキーマ上の詳細で決まります。

• 形式。 リギングモデルはGLBを受け付け、OBJ、FBX、STLも受け付けることがよくあります。出力形式のフィールドを公開しているモデルはないため、リグはGLBかFBXで返されますが、どちらかを記載していない説明がほとんどです。エンジンが別の形式を必要とする場合は、DCCでの作業が必要になると見込んでください。
• サイズ上限。 ファイル入力に max_size があるモデルは例外的であり、一般的ではありません（ヒューマノイドのリギングモデルのうち1つは30 MBを上限としています）。大きなメッシュのデシメーションが必要だと決めつける前に、スキーマを確認してください。
• アニメーションとリグ。 リガーが animation を公開している場合、プリセットクリップをリターゲットします。allowed_values はリグタイプを接頭辞に持つ形式（quadruped:walk）なので、推測せずに確認してください。デフォルトではリターゲット済みファイルのみが返されます。通常のリグ済みメッシュも保持するには includeRiggedModel を設定します（2つは metadata が同じ別々のアセットとして返されるため、asset_get で区別できます。リターゲット済みのほうは properties.hasAnimations が true で animationFrameCount があり、通常のリグ済みメッシュは false で null です。また、返される順序は保証されません）。

モーションだけが必要な場合、モーション転送の動画モデルはスケルトンなしで静止キャラクター画像をアニメーション化します。scenario-video を参照してください。アップロードしたメッシュを自動でリギングする動画からモーションへのモデルでは、outputFormat 列挙型でエンジンのターゲットを選択できます。

よくある間違い

• model_schema_get を使わずに model_run を実行すること。3Dモデルのパラメーターは、画像モデルのものよりモデル間の差がはるかに大きくなります。
• ローカルファイルのパスを画像入力として渡すこと。まず upload_asset を使い、返されたアセットIDを渡してください。
• モデルIDをハードコードすること。カタログは入れ替わります（deprecated:<replacement_id> タグに後継モデルが示されます）。各セッションでモデルを再検索し、用途には recommend、モデル名には search を使ってください。
• asset_display を呼び出さずに、アセットのURLをそのままチャットに貼り付けること。
• 選択したメンバーの説明にない、名前付きのスケルトン、影響を与えるボーン数、翼や追加の手足のボーンを約束すること。最も近いボディプランを選び、残りはDCCで仕上げてください。
• 二足歩行モデルを rigType モデルに送ること。ヒューマノイドには専用のリギングモデルがあるため、列挙型に二足歩行の値はありません。