3D アニメーションシーン制作
シーンを、用途、空間関係、時間変化を持つ環境として制作します。何を強調すべきか、どの部分を詳細に作り込むべきか、何を動かすべきかを能動的に判断し、ユーザーが一つ一つ指示するのを待ちません。この能動性は、許可されたシーンを完成させるために用いられ、テーマ、機能、または納品形態を勝手に変更するためには用いません。
実行エントリ
ユーザーから制作または修正の依頼があった場合、ソフトウェア、スキル、実行ルート を読み、納品物に適したルートを選択して実際に実行します。美的アドバイスやプロンプトを出力するだけではいけません。純粋な分析リクエストに対しては、以下の判断原則のみを使用します。
本スキルは scripts/scene_tool.py を提供します:probe は環境を確認、inspect はシーンを読み込み、run は今回の制作スクリプトを実行してプロジェクトを別名保存、render は静止画または連続フレームを出力、encode は通常速度の動画を生成します。これらは Blender/FFmpeg を呼び出しますが、幾何形状やアニメーションを無から決定する責任は負いません。具体的な制作スクリプトは、現在のタスクに応じて以下の判断に基づいて記述され、専門能力は既存のスキルを再利用します。
順序は次の通りです:入力とツールの確認 → デザイン案の作成と確認(既に確認された目標を再利用)→ グレーボックスでの空間確認 → 代表的なシーンの完成と実行検証 → 拡張と各ラウンドでの比較 → ソースファイルと証拠の納品。タスクのフェーズに応じて必要な工程のみを取り出し、既存シーンの部分修正では全工程をやり直しません。
今回の納品物と再利用範囲の確定
まず、既存のシーン、参照画像、カメラ、確認済みの要件、ターゲットデバイスを確認します。コンセプトアート、編集可能な3Dモデル、オフラインアニメーション、リアルタイムシーン、固定視点のレイヤーアニメーションを区別し、ユーザーが依頼したフェーズのみを完了します。
- 確認済みの構図、モデル、マテリアル、アニメーション、プロジェクト構成を再利用します。特定の部分の最適化が、シーン全体の作り直しにならないようにします。
- 視聴者が何をするために来るのか、どこから見るのか、移動できるのか、視聴距離、滞在時間、出力サイズを明確にします。目標を変更したり、明らかな手戻りを引き起こすようなギャップがある場合にのみ質問します。通常の詳細については、根拠に基づいて自律的に選択します。
- 自由な回り込み、パララックス、遮蔽の変化、厳密なマルチビュー一貫性が必要な場合は、共有の3D空間を使用します。固定レイヤーアニメーションは制限された視点にのみ適しており、採用前に納品物の違いを説明し、それを完全な3Dシーンと呼んではいけません。
- まず、現在利用可能なツールと対応するスキルを確認します。モデリング、テクスチャリング、プロシージャル生成、画像編集、エンジン実装のそれぞれに必要な能力を選択し、デフォルトで依存関係をインストールしたり、特定のMCPを使用したり、制作プラットフォームを切り替えたりしません。
デザイン案の確認と完成度の照合
新規シーン作成、大規模なビジュアルリニューアル、またはビジュアルの完成度を確認する必要がある場合、ビジュアル目標と完成度チェック を読みます。新規作成またはアート方向性の再設定時は、まず ImageGen で実際にデザイン案を生成して表示し、確認が取れた後に詳細なモデリングと一括制作を進めます。複数視点の探索は、必要に応じて game-scene-visual-exploration を再利用します。ユーザーが既に確認した目標はそのまま再利用し、再確認を要求しません。ユーザーがデザイン案を明確にスキップした場合、またはグレーボックスや技術検証のみを要求した場合は、その範囲で実行し、まだビジュアル目標のベースラインがないことを説明します。
確認済みの目標画像、前バージョンの実写、今回のバージョンの実写を保持し、比較可能なカメラ位置で照合します。ImageGen による改善案はデザイン提案であり、実際の実行証拠を置き換えたり、確認なしに検収目標を変更したりすることはできません。空間、代表的なシーン、全体の納品物をそれぞれチェックし、すべての単一オブジェクトが完成するまで最初の組み合わせ効果を確認しない、ということを避けます。
制作判断を先に形成し、その後生成またはモデリング
内部で簡潔なシーン判断を形成します。複雑なタスクでは、重要な判断をユーザーに表示しても構いませんが、毎回表全体を出力する必要はありません。
| 判断 | 制作に落とし込む内容 |
|---|---|
| 用途と動作 | 人や他の主体がここで何をするか。操作順序、到達経路、リーチ範囲、接触点 |
| 視覚的中心 | 現在の視点で最初に何が見えるべきか、何がそれを支え、何が背景に退くべきか |
| 空間とカメラ | スケール、隣接関係、視線、遮蔽、被写界深度、カメラ移動、インターフェースの余白 |
| 重要な詳細 | 近くで見たときに、どの構造、マテリアル、配置関係が信頼性を決定づけるか |
| 動きと静態 | 動きの発生源、動きを受けるオブジェクト、固定された拘束、応答の違い、安定したリファレンス |
| 納品の制約 | リアルタイムまたはオフライン、ターゲットデバイス、リソース予算、編集可能性、今回の検収範囲 |
「精巧、荘厳、活発、緊張」などの目標を、観察可能な条件に変換します。単なるスタイルの形容詞を書くだけではいけません。視覚的中心はタスクやカメラによって変化するため、シーン全体に常に一つの焦点を強制しません。
重要なものを可視化する
位置、スケール、シルエット、明暗コントラスト、色彩、マテリアル、余白、動きによって注意を導きます。シーンに適した手段のセットを選択し、すべての主体をより明るく、より大きく、より彩度高くしません。
- まず構図と空間関係をチェックし、その後でマテリアル、ディテール、ライトを追加します。構造や比率の誤りは、ブルーム、被写界深度、フォグ、装飾でごまかせません。
- 主体は実際の視聴距離で認識可能である必要があります。脇役は用途を説明し、背景は空間関係を提供します。すべての領域が同じ詳細密度と動きの強度を持つべきではありません。
- インタラクションが必要な場合、重要なオブジェクトは見え、手が届き、識別可能でなければなりません。インターフェースのオーバーレイ、字幕、セーフエリアが重要な操作を隠してはいけません。
- ユーザーが指定したスタイルに忠実に従います。フォトリアリズムは因果関係と関係の自己無撞着さから生まれますが、すべてのシーンが写実的であったり、ウェザリングテクスチャで埋め尽くされている必要があるわけではありません。
使用プロセスから詳細を導き出す
重要な領域について、頭の中で実際の使用プロセスをシミュレートします:どのように近づき、座ったり立ったりし、物を取り、操作し、戻し、離れるか。人間以外の、または日常的でないシーンでは、そのアクティビティと物理法則に固有のルールを使用し、無理に人体スケールを適用しません。
信頼性に本当に影響を与えるこれらの関係をチェックします:
- 構造:接続、厚み、支持、重力、開閉、接触影。浮遊、貫通、使用不可能な配置を避けます。
- 操作:手や操作機構の可動域、オブジェクト間の相対位置、経路、アクセス可能性。根拠なく左右の手の習慣を固定しません。
- マテリアル:マテリアルのスケール、エッジ、粗さ、光透過、液面、接触部分。使用感はシーンの状態に応じて追加し、デフォルトですべてのオブジェクトを汚れや古さで表現しません。
- 意味論:オブジェクトは場所、時代、アクティビティと一致していますか。宗教的、文化的、専門的な器物のルールを想像で追加せず、不確かな場合は信頼できるリファレンスを確認します。
- 視聴距離:予算を、実際に近づいて見つめたり操作したりするオブジェクトに割り当てます。遠景はシルエットとグループ分けを優先し、見えない微細なディテールを作り込みません。
例:礼拝スペースは中心的な調度品と周辺の器物の関係をチェック。筆記エリアは紙、ペン、インク、腕の置き場所をチェック。作業台は工具、ワーク、操作余裕をチェック。製品展示は継ぎ目、ボタン、マテリアルをチェック。これらは推論方法を説明するための例であり、すべてのシーンのオブジェクトリストを構成するものではありません。
動きに理由、焦点、境界を持たせる
動的なシーンが関わる場合、動きの識別とチェック を読みます。AI が実際の画像、シーン構造、ゲームプレイに基づいて、あるべき動き、トリガー応答、静止すべきオブジェクトを能動的に識別します。ユーザーが一つずつリストアップするのを待ったり、既に書かれたアニメーションだけをチェックしたりしません。静的なデザイン案が確認された後、制作判断に動的な意図を追加します。画像による確認は、動作の検収を意味しません。
「動くべきものを動かす」とは、すべてのオブジェクトをループアニメーションにすることではありません。風、重力、流体、熱、機械的駆動、キャラクターアクション、ナラティブの意図に基づいて、どの動きが現在のシーンにとって価値があるかを決定します。静止そのものが焦点になり得ることを明確にします。
主要な動きについて決定します:発生源、固定点またはサポート、方向、振幅、リズム、位相、相互影響、可視範囲、ループ方法。タスクの必要に応じて記録し、すべての葉にテーブルを作成することを強制しません。
- 同じ駆動力下のオブジェクトは関連しているが、機械的に同期していない必要があります。質量、剛性、長さ、減衰、遮蔽が異なれば、応答も異なります。
- 変位、変形、マテリアル変化、ライト、パーティクルを区別します。水面、滝、蒸気、煙、火、布、機械はそれぞれ異なる法則を持ち、一つの揺れ公式を適用できません。
- 固定点、剛体、接触関係は合理的に保たれます。吊るされたオブジェクトは吊り点の周りを移動し、付随するテキストや装飾品も追従します。布の上部と自由端は同じ振幅で動くべきではありません。
- 動きの包絡線内での貫通、分離、変形、遮蔽、ループの不連続をチェックします。複数のカメラは共有シーンと一貫した時間関係を使用し、互いに矛盾するアニメーションを個別に生成しません。
- 注意の競合を制御します:環境の動きは主体をサポートします。タスクが操作やイベントを強調する必要がある場合にのみ、対応する動きの顕著性を高めます。
- リアルタイムシーンは、ホストのニーズに応じて、一時停止、再開、バックグラウンド処理、動きの低減をサポートします。オフライン映像は、フレームレート、時間サンプリング、ループの継ぎ目をチェックし、アプリケーションのライフサイクルインターフェースを強制しません。
固定視点のレイヤーまたはシェーダーアニメーションは、マスクエッジ、サンプリング範囲、反射、遮蔽もチェックする必要があります:変位の追加により、背景の建物の色が空に混入したり、固定オブジェクトのエッジが引き伸ばされたりする可能性があります。画面全体の揺れでオブジェクトの動きを代用してはいけません。
リアルタイムゲームのアクション制作と組み込み
キャラクター、生物、仕掛け、またはインタラクティブアニメーションが関わる場合、リアルタイムアニメーションの制作と組み込み を読みます。これには、動作、移動、姿勢の役割、アニメーション切り替え、ソースファイルと出力物の一貫性、ターゲットデバイスでの検証が説明されています。純粋な静的なシーンやオフラインアニメーションでは読む必要はありません。
- プレイヤー操作と観察可能なフィードバックからアクション要件を決定し、まず「入力 → 状態変化 → アクション/フィードバック → 終了または中断」という代表的な断片を完成させ、その後で同様のコンテンツを拡張します。環境ループに勝敗、戦闘、ステートマシンを強制しません。
- アニメーションはゲームプレイとスタイルにサービスします。アクションゲームは予備動作、接触、回復、割り込み可能なタイミングに焦点を当てます。探索、パズル、経営ゲームは操作フィードバック、可読性、状態の連続性に焦点を当て、統一されたリズムを適用しません。
- 本スキルはシーンとアニメーションを担当し、完全なゲームプレイ開発を置き換えるものではありません。ユーザーが完全なゲーム制作を要求した場合、既存のプロジェクト内で対応するゲームプレイと検収スキルを接続し、シーンプレビューに留まらず、実際にプレイ可能なフローを納品します。具体的なルートは execution.md を参照してください。
生成と実装
まず空間、構図、主体を解決し、その後で重要な詳細とアニメーションを完成させます。既に完成した部分の修正は直接行い、機械的に全フェーズをやり直しません。
画像生成が必要な場合、プロンプトは以下の内容で構成し、実際のタスクに応じて取捨選択します:
参照と用途。必ず保持する内容。今回の明確な変更。主体の位置、比率、空間関係。重要なオブジェクトの構造と使用の詳細。マテリアル、ライト、ビジュアル階層。カメラ、出力、インターフェースの余白。許可されない変更。
- まず入力画像を実際に確認し、それがスタイル参照用か、レイアウト用か、編集用の原図かを明確にします。部分的な修正は、確認済みの原図を編集することを優先し、生成後にターゲット以外の領域が変化していないか確認します。
- 小さな器物、細い棒、紙面、テキスト、関節、建築の継ぎ目を近くで確認し、ぼやけた疑似ディテールや異常な形状を発見したらすぐに修正します。
- 動的、編集可能、またはビジネスロジックで駆動されるテキストは、通常、実際のテキスト/シーンオブジェクトで描画され、生成された背景に焼き込まれません。
- コンセプトアートのみの場合、幾何学的な一致、編集可能なモデル、実行パフォーマンスを約束してはいけません。実装が効果を出せない場合は、具体的な制限を説明し、プロンプト、静止画、パラメータテーブルでアニメーション成果を偽装してはいけません。
- リアルタイムパフォーマンスはターゲットデバイスで測定します。発見されたボトルネックに対しては、インスタンシング、LOD、ベイクなどの既存の機能を優先的に使用し、一般的なポリゴン数やフレームレート予算を事前に想定しません。
検収と停止
技術的な実行とビジュアル効果を分けてチェックします。ピクセルの変化、時間の進行、レンダリング成功は、実行を証明するだけであり、アニメーションが知覚可能であることやシーンが信頼できることを証明しません。今回のフェーズに応じて、内容、空間構図、アート、動的インタラクション、実行の再現性をそれぞれチェックします。結論には PASS / PARTIAL / FAIL / BLOCKED を使用し、対応する証拠を提示します。未検証の項目は合格とみなされません。詳細は 照合方法と完了条件 を参照してください。
- 実際の視点、サイズ、通常の再生速度でチェックします:最初の視線の焦点、近くのディテール、動きの可視性、主体が遮蔽されていないか。比較が必要な場合は、同じカメラ、同じ照明、同じ再生時間のベースラインを保持します。
- 重要なオブジェクトを参照して、機能、サポート、接触関係をチェックします。動くべきでないオブジェクトとアニメーションのエッジをチェックします。自由視点シーンでは、必要な側面、背面、移動チェックを追加します。
- 動きのスペシャルチェック に従い、あるべき動きの欠落、実際のアクションと静止リファレンスを確認し、その後完全なアクション/ループとトリガー遷移を観察します。一律の再生秒数を設定せず、高速再生で通常速度での可視性を証明しません。
- 納品物に応じて検証します:オフライン出力は完全なエクスポートクリップを確認。リアルタイムシーンはターゲットデバイス上の実際のロード、操作、一時停止・再開、パフォーマンスをチェックします。テストされていないデバイスやプロセスは明確に注記します。
- 開くことのできるソースファイルまたは実行成果物、および必要な依存関係、バージョン、リソースリスト、プレビューを納品します。ネイティブ機能とシーンのレイヤーを分ける場合は、リソースと制御インターフェースを説明し、オーディオ、テキスト、ビジネス状態の重複を避けます。
修正は、使用感や見た目を変える最大の問題を最初に解決し、装飾を追加し続けて修正を代替しません。今回の目標に達したら停止し、検証範囲と残りの制限を報告します。環境全体を自動的に拡張したり、プロジェクトアーキテクチャをアップグレードしたりしません。