Blender Asset Studio
リファレンスおよび意図された視聴条件と厳密に比較できる編集可能なモデルを生成します。作業の受け入れから納品までを管理し、ユーザーが繰り返し依頼する必要のある重要なレビューを担当します。
これは自己完結型のプロダクションスキルです。実行のために別の 3D プロダクションスキルやグラフィックスパイプラインスキルを呼び出さないでください。必要なワークフロー手順はすべてこことリンクされたリソースに含まれています。特定のツールに関するホストが指示する手順は引き続き適用されます。
現在のステージのみをロードする
| ステージ | 読み込むもの |
|---|---|
| 開始またはスコープの変更 | 受け入れとブリーフ |
| ビジュアルターゲット、コンセプトのルートまたは品質基準の選択 | アートディレクションと品質ゲート |
| リファレンスの分析またはビジュアルギャップの埋め合わせ | リファレンス準備 |
| ジオメトリの構築、隠れているサーフェスの簡略化、接触箇所または不要な交差の確認 | モデリング規律 |
| すべてのビジュアル承認パス | レビューと修復プロトコル |
| 予算、マテリアル、トポロジ、または変形要件の設定 | テクニカルプロファイル |
| ヘルパーの使用、エクスポート、または引き渡し | プロダクションとデリバリー |
| このスキルの維持/評価 | 評価シナリオ |
既存のタスクブリーフと台帳を再利用します。ワークブリーフ、オプションのコンセプトブリーフ、およびレビュー台帳の例はフォーマットを提供しますが、承認を認定するものではありません。
譲れない動作
- ユーザーのスコープ、プライマリリファレンス、および保護された機能を保持します。プロジェクトの指示と確立されたアセット契約は、このスキルのフォールバック選択よりも優先されます。
- 該当するプロジェクトガイダンスを読み、実際のリファレンスピクセルを検査します。ファイル名、要約、またはビルダーの説明は視覚的証拠ではありません。
- 新しいデザインの場合、実質的なモデリングの前に受け入れを実施します。ユーザーにリファレンス/例を明示的に要求し、Imagegen を通じて初期コンセプトアートを提供します。ユーザーのリファレンス状況とコンセプトの選択を記録します。サイズの質問に答えることで、そのサイズの質問のみがクローズされます。以前の明示的な回答を再利用します。
- 初期のアートディレクションと後続のギャップフィリングを区別します。初期コンセプトは、ユーザーが選択したレビュー/自律モードでターゲットを確立し、サポート生成はユーザーに繰り返し質問することなく特定の不確実性を解決します。可能なすべてのビューを自動生成しないでください。
- 生成されたビューを、提供されたリファレンスよりも強い証拠として扱わないでください。発明された構造は推論として記録します。
- メーカーとレビューアのパスを分離します。成功したスクリプト、低い三角形数、または洗練されたナラティブは、ビジュアルゲートを通過できません。
- 芸術的な品質をビジュアルターゲット/品質ベンチマークと比較し、エクスポートの忠実度をソースと比較します。ソースとエクスポートの類似性は、忠実度のみを証明します。すべての技術チェックに合格しても、平らなフィル、ランダムなカット、または一般的なノイズを持つ基本形状は不合格になる可能性があります。
- すべてのマテリアル批判は、実行可能な修復につながる必要があります。ターゲットオブジェクト/領域、観察された証拠、測定可能なターゲットまたは注釈付き形状、操作、保護された制約、および受け入れ観察。
- 修復は、修正されたモデルの新しい証拠からのみ検証されます。レタッチされた画像は提案であり、3D 変更の証明ではありません。
- 許可されたビューと状態全体での表示または機能的な貢献によってジオメトリを割り当てます。モディファイア適用後の実際の結合とサポートを確認します。可視性/接触診断は検査の候補を提供しますが、削除の許可や品質証明書ではありません。
- サポート/接触とは別に、不要な相互浸透を確認します。これには、相互作用するアセットと必要なポーズが含まれます。壁を通る手やテーブルトップを通る椅子は、たとえ接触グラフがパーツを接続されていると呼んでも欠陥です。ドキュメント化されたペア、範囲、目的に対してのみ、設計された埋め込みを許可します。すべての交差を禁止または自動的に許可として扱わないでください。
- 最良のチェックポイントを保持します。予算の枯渇は、名前付きの欠陥がある不完全な納品を意味し、自動的な受け入れを意味しません。
1. ブリーフを発見して確立する
関連するプロジェクトの指示、スタイルリファレンス、既存のアセット、テクスチャライブラリ、ターゲット寸法、規則、および予算を検査します。それらのパスと各制約の起源を記録します。あるプロジェクトのスタイルや数値制限を無関係な作業にコピーしないでください。
受け入れ を使用します。不完全な新規デザインリクエストの場合、通常は、欠落している芸術的および機能的な選択をカバーする、4~6 個の意味のある質問を 1 つのコンパクトなバッチで行います。数を満たすために重複した質問を生成しないでください。質問が少ないか、またはゼロであることは、記録された回答によってのみ正当化されます。これには、リファレンスステータスと初期アートルートが含まれますが、プロジェクトスタイルやエージェントの仮定だけでは正当化されません。エンジン情報が欠落していても、スタンドアロンモデルはブロックされません。
高価な作業の前に、コンパクトな受け入れ契約を設定します。
- リファレンスの権限、必要なビュー、および検査するセマンティック領域。
- ユーザーのリファレンスステータス、初期の Imagegen の選択、コンセプトレビュー/自律モード、および解決されたビジュアルターゲット。
- 品質ベンチマークと、完成したアセットがそれを満たすべき観察可能な理由。
- 形状/プロポーションのターゲットと、許可されるデザインの自由度。
- 技術的制限、そのソース、およびカウント基準。
- 必要なエクスポート形式とアプリケーション検証範囲。
- 労力予算と停止/回復ルール。
「AAA 級」を具体的なビジュアルターゲットに変換します。信頼できる構築、意図的なシルエット、説得力のあるマテリアル応答、制御されたディテール、クリーンな仕上げ、および意図されたスケールでの一貫性。業界ラベルを約束したり、数値的な美しさスコアで代用したりしないでください。
2. 機能を確認し、シーンを保存する
インストールされている Blender MCP サーフェスとその実際のコントラクトを発見します。読み取り専用のステータス/シーン検査から開始します。アクティブファイル、Blender バージョン、コレクション、ユニット、既存の作業、ツール、および利用可能なレンダリング/画像生成機能。
主要なオーサリング接続として MCP を使用します。利用できない場合、インストールされているローカルの Blender は、別のプロセスで検査済みのビルダーを実行できます。フォールバックを開示します。Blender を実行できない場合は、独立したブリーフ/リファレンス作業を完了し、モデルステージを未実行として明確に識別します。
安定したコレクションと出力フォルダを所有します。ユーザーのシーンをリセットしたり、無関係なファイルを上書きしたり、他のタスクのオブジェクトを削除したりしないでください。変更を共有の Blender インスタンスにシリアル化します。ヘビーなベーク/レンダリングは、制御された CPU/GPU 使用率で分離されたバックグラウンドプロセスを使用できます。同じファイルに対して競合するジョブを開始しないでください。
有料ジェネレーター、新しいサービス、権利が不明確なダウンロード、インストール、または外部公開については、ユーザーの承認とホストポリシーに従ってください。クレジットを黙って消費したり、プロバイダーを追加したりしないでください。利用可能なリファレンスが十分な場合、画像ジェネレーターがなくてもモデリングはブロックされません。
3. アートディレクションを確立し、特定のギャップを埋める
アートディレクション と リファレンス準備 を読んでください。初期アートルートは次のとおりです。十分に提供されたリファレンスから作業する。ユーザーが選択するコンセプトを生成する。委任された場合は自律的に生成して選択する。または明示的に委任された直接 3D デザイン。未回答のアートの選択は承認ではありません。要求されたコンセプトレビューの場合は、ユーザーに選択を求める前に具体的なアートを生成して表示します。その選択が行われるまで、依存する詳細なモデリングを停止します。ユーザーがすでにデザインを選択したか、選択を委任した場合、このチェックポイントは追加しないでください。
オブジェクト全体とその意味のある領域をインベントリします。シルエット、主要なマス、構造、アタッチメント、マテリアル、および特徴的なディテール。可視性/ディテールマップを定義します。これには、簡略化できる隠れているサーフェスも含まれます。家族を増殖させたり、アセット全体を仕上げたりする前に、代表的な困難な領域を内部でターゲットに対して承認します。
各重要な事実を、観測、測定、推論、または暫定として分類します。一貫性のある既知の寸法と構造で、見えない領域を推論します。その推論がアイデンティティやコストのかかる機能インターフェースを変更する可能性がある場合は、ディテール作業の前に解決します。
方向性が解決された後、合意されたスコープと生成予算内で、名前付きの質問に答えるために、追加のビュー/クロップ/マテリアルスタディを自律的に要求します。新しく生成されたビューを不変リストに対してチェックします。コンセプトは、寸法的に信頼できる設計図ではありません。
4. 段階的に構築して受け入れる
- ブロックアウト: プロポーション、シルエット、スケール、開口部、接触面、主要パーツ。リファレンスに一致したビューと反対側のビューをチェックします。
- コンストラクション: 厚み、サポート、ジョイン、ネガティブスペース、可動部品、アタッチメントポイント、および要求されたアクションによって露出した内部サーフェス。モデリング規律 を読んで、スクリーンサイズの決定、隠れサーフェスのルール、接触、および貫通/クリアランスチェックを行います。アセンブルされたコンテキストと必要なポーズを検査します。分離されたパーツは互換性を確立できません。ジオメトリを削除する前に、許可されたカメラ/状態範囲を確立します。
- マテリアルとディテール: 適切なプロジェクトリソースを使用し、ライブラリがターゲットを満たせない場合は、欠落しているディテールを適応/ベークまたは作成します。スケールに適したマテリアル応答と目的のあるコンディションを開発します。ライブラリテクスチャやノイズノードは、それ自体では完成したマテリアルではありません。可視形状や必要な変形を変更する場所にジオメトリを追加します。
- プロダクション: UV、適切なベーキング、テクスチャ、マテリアルの統合、および保護された機能や機能構造を失わずにトポロジを削減します。
- デリバリー: 最適化とエクスポートによって引き起こされた変更を含め、実際にエクスポートされたアーティファクトを検査します。
コストのかかる下流ステップの前に、関連する受け入れパスを実行します。ブロッキングシルエット、構造エラー、または主要なマテリアル/品質の不一致があると、アセットは現在のステージに留まります。技術的に有効なブロックアウトを完成アセットとしてラベル付けしないでください。別の問題が解決されている間、独立した有用な作業を続行できます。
大規模なセットをベークする前に、代表的なパーツで難しいマテリアル/エクスポートパスを証明します。ファミリーの場合、拡張する前に代表的なパイロットを受け入れ、その後、マテリアル的に異なるすべてのメンバーとファミリー全体をレビューします。
5. 自律的なレビュー/修復ループを実行する
レビューと修復 を読んでください。すべての意味のあるリビジョンにこのシーケンスを使用します。
- 一意に識別された候補を保存し、そのソース/エクスポートリビジョンを識別します。証拠としてすでに使用されているリビジョンを上書きしないでください。
- 比較可能な概要ビュー、ターゲットスケールの画像、および必要なディテールクロップをキャプチャします。該当する場合、レビュープロトコルのシルエット、値、ターゲットサイズ、スケール、接触、ワイヤーフレーム、およびニュートラルライトチェックを適用します。テストが実行されたという事実だけでなく、結果を記録します。
- ローカルタイルの前に、ビジュアルターゲットに対してオブジェクト全体をレビューします。対応するセマンティック領域とソース/エクスポートの忠実度を個別に比較します。検査された各領域について、実際のターゲットピクセル、候補ピクセル、および具体的な違いまたは合格理由を記述します。観察されなかった領域を明示的にマークします。
- 具体的な修復と証拠を含む、優先順位付けされた欠陥台帳を作成/更新します。
- 最も影響の大きい一貫した欠陥グループを修正します。
- 新しい証拠をキャプチャし、変更された領域、隣接する接触、および保護された機能を再チェックします。
- 改善された候補を保持するか、より良いチェックポイントを復元します。台帳と残りの予算を今すぐ更新します。引き渡し時にのみ合格台帳を再構築しないでください。
レビューアは、メーカーの説明を読む前に、ブリーフ、プライマリリファレンス、現在の画像、および測定値を調べます。個別のエージェントが利用可能で委任が承認されている場合、読み取り専用のレビューアが欠陥台帳を返すことができます。指定されたメーカーのみがアセットを変更します。それ以外の場合は、個別の順次レビューを実行します。自己レビューが独立したレビューであると偽らないでください。
レビューはすべての段階でユーザーの承認を必要としません。ブリーフの範囲内で自律的に続行します。結果的なあいまいさ、新しいコスト/アクセス、必須のリファレンスの欠落、または方向性の変更により、次の有用なアクションが妨げられる場合にのみ質問します。
6. 証拠と予算に基づいて停止する
最初にユーザーの制限を使用します。制限がない場合は、暫定的な標準予算を宣言します。初期候補後の最大 4 回の完全な修復サイクル、2 回の追加のターゲット修復パス、および最大 3 回のサポート画像生成呼び出し。これらはタスク全体の制限であり、各ステージまたは圧縮後にリセットされません。未使用のサイクルを消費する必要はありません。タスクのサイズにより、別の明示的な初期予算が正当化される場合があります。
初期アートが選択されている場合は、開始前にその呼び出しを生成許可に明示的に含めます(デフォルト:最大 2 回の初期コンセプト呼び出し + 3 回のサポート呼び出し)。修復サイクルは、レビュー → 一貫性のある修正グループ → 新しい検査です。その検査後の後続の修正は、クリーンアップと呼ばれたり、同じバージョン名が付けられたりしても、別のパスです。ユーザーの指示によりターゲットが変更される場合があります。変更と影響を受ける予算を明示的に記録し、カウンターをリセットしないでください。
同じ重要な欠陥を改善するための 2 回連続の試行が失敗した場合、診断と、残りの予算内での 1 回の方法変更をトリガーします。同じ効果のないパラメータを調整し続けたり、習慣でオブジェクト全体を再生成したりしないでください。
必要な領域と成果物が検査され、ブロッキング/メジャーな欠陥が解決され、技術ゲートが通過し、許容されるマイナーな逸脱が明示されている場合、正常に停止します。制限に達したか、機能が不十分な場合、不完全として停止します。最良のファイルを保存し、未解決の欠陥を報告し、受け入れターゲットを黙って弱めないでください。
作業を再開するときに失敗した試行を繰り返さないように、ブリーフ、リファレンスの決定、チェックポイント、および台帳をタスク出力ディレクトリに保持します。ユーザーの更新は簡潔に保ちます。現在のステージ、使用された予算、発生したまたは修正された主な問題、および残っている最も重大な欠陥を伝えます。進行中の変更については、次の重要なステップと期待される完了時間を含めます。