フォトリアルアセット は何をしますか?
ブリーフを調査し、1回の単独ビルドを実行し、写真と比較して結果を報告します。 インストール済みのBlenderとホストが利用可能なエージェントツールを使用します。特定のエージェントプロバイダー、 モデル、Blenderのインストールパス、プロジェクトの場所は必要ありません。
セットアップ
{SKILL}をこのファイルが含まれるディレクトリに、{SCRIPTS}をそのscripts/ディレクトリに解決します。{PROJECT}をユーザーが選択したプロジェクトディレクトリに解決します。コマンド内のパスは引用符で囲みます。 例ではフォワードスラッシュを使用しています。これはWindows、macOS、LinuxのPythonで受け入れられます。- Python 3と
numpyおよびPillowを使用します(python -m pip install -r "{SKILL}/requirements.txt")。 SciPyはオプションで、UVチェックを高速化します。BlenderはbpyスクリプトにバンドルされたPythonを使用します。 blenderをPATHから見つけるか、PHOTOREAL_BLENDERに実行可能ファイルのフルパスを設定します。値に引用符は含めません。 ビルドスクリプトとハーネスには同じ実行可能ファイルを使用します。 バージョンを確認し、サポートされているbpyAPIに合わせてビルドコードを適応させます。固定バージョンを想定しないでください。- Cyclesは利用可能なGPUバックエンドを選択し、フォールバックとしてCPUを使用します。
PHOTOREAL_CYCLES_DEVICEをCPU、OPTIX、CUDA、HIP、METAL、ONEAPIのいずれかに設定すると、自動選択をオーバーライドできます。 レンダリングは順次実行します。オプションの外部gpu_slot.pyキューをPHOTOREAL_GPU_TOOLSを通じて提供できます。 これはバンドルされておらず、必須でもありません。 asset.json内のパスは、そのファイルからの相対パスです。空のhdriはプロシージャルな昼間の空を使用します。 それ以外の場合は、既存のHDRIを指定します。ビルドが開始されたら、照明とカメラは固定します。- デフォルトの納品物は、画像とレビューレンダリングがパックされた編集可能な
.blendファイルです。ゲーム用のエクスポートは 要求された場合のみ追加し、templates/GAME_READY.md に従います。
プロジェクトレイアウト
<project>/
asset.json カメラ、照明、コレクションプレフィックス、批評家用参照
BRIEF.md リサーチブリーフと記入済みのRULES.mdテンプレート
ref/SOURCES.md 写真の出典情報。参照画像は同梱されません
research/ layout.py, blockout.py, blockout.blend, NOTES.md
rounds/r01-build/ TASK.md, build.py, NOTES.md, tex/, renders/, final/, DONE.txt
<Title>.md ラウンド表とプロジェクトログ
ユーザーが提供する場合は、既存のアセットライブラリを使用します。外部画像とテクスチャのソースURLとライセンスを記録します。 不明なライセンスは不明のままにし、所有権を創作したり、参照写真を納品物とともに再配布したりしないでください。
1. リサーチ
- templates/asset.json をプロジェクトにコピーし、被写体、
collection_prefix、空、地面を適応させます。ヒーロー、サイド/フロント、トップスリークォーター、最も難しい部分のクローズアップビューをフレーミングします。 批評家のためにrender_as、photo_kind、scope_noteを設定します。 - templates/TASK_research.md に記入します。
{ASSET}、{PROJECT}、{PREFIX}、{SUBJECT_PLURAL}、{SKILL}、{SCRIPTS}を置き換えます。research/TASK.mdとして保存します。 ホストのエージェントツールを通じて1人のリサーチャーを実行するか、直接リサーチを実行します。 - 出典情報付きの参照写真、
BRIEF.md、パーツごとに1つのゾーンとオーナーコレクションを持つresearch/layout.py、 ブロックアウト、およびasset.json内のowner_refs/overall_refsを納品します。 - ホストの画像ビューアでブロックアウトレンダリングを検査します。各カメラが被写体をフレーミングするまで調整し、ロックします。
提供されたデザインシートの場合、変更せずに ref/ にコピーし、提供された出典情報(指定がない場合は不明)を記録し、詳細なクロップを作成します。
そのビューを審査対象のカメラに使用します。写真として合格することが目標ではなく、スタイライズされたデザインに合わせることが目標の場合は critic_goal を設定します。
タスクの文言と追加の納品物をそれに応じて調整します。
2. ビルド
- templates/TASK_build.md から
rounds/r01-build/TASK.mdを作成します。{ROUND}、{ASSET}、{PROJECT}、{ROUND_DIR}、{FILE}、{SCRIPTS}を記入します。 - Blender専用アセットの場合は
{GAME_READY}を空のままにします。それ以外の場合は、記入済みの templates/GAME_READY.md を挿入し、Godot、Unreal Engine、またはその両方を選択します。 - 1人のビルダーにタスクを渡します。ユーザーが別のモデルを要求しない限り、現在のモデルを使用します。 ホストがセッション識別子を公開している場合は、それを保持します。1人のビルダーがジオメトリを所有します。 独立した批評家はそれをレビューするだけです。
3. 各ラウンドのレビュー
- 最終シーンをレンダリングします。
python "{SCRIPTS}/run.py" --asset "{PROJECT}/asset.json" --parts "{ROUND_DIR}/final/{FILE}.blend" --out "{ROUND_DIR}/final/renders" NOTES.mdと最新のcritique.mdを読みます。難しい部分のフル解像度クロップを写真と並べて検査します。 必要に応じて明るくしたクロップも含めます。重大度カウントはノイズが多いです。実際の視覚的な違いを使用して進捗を判断します。- 前のラウンドが存在する場合は、それと比較します。
結果のpython "{SCRIPTS}/compare_rounds.py" --asset "{PROJECT}/asset.json" --rounds <前のラウンド> <現在のラウンド> --focus <ゾーンID> --refs "<写真>:x0,y0,x1,y1" --out "{PROJECT}/compare_rounds"_all.jpgと_focus.jpgシートを検査します。compare_rounds.py --helpで期待されるラウンドパスを使用します。 - ゲームエクスポートの場合、
GAME_READY.mdでターゲット固有の検証を実行します。 GodotのGLBチェッカーで検証されたものとしてUnrealインポートを説明しないでください。 - サポートされているトランスクリプトが利用可能な場合、オプションで以下を実行します。
この監査はAntigravityとClaude Codeのログを理解しますが、すべてのホストを理解するわけではありません。python "{SCRIPTS}/audit_round.py" "{ROUND_DIR}" --root "{PROJECT}"--sessionでAntigravity会話を指定し、--allowで追加の許可ツールディレクトリを指定します。 そのファイルパススキャンはWindowsドライブパスを認識します。他のパススタイルは個別にレビューします。 ログルートはPHOTOREAL_ANTIGRAVITY_LOGSとPHOTOREAL_CLAUDE_LOGSでオーバーライドできます。 - ラウンドとレポート画像、改善点、後退点、検証結果、1つの推奨事項を記録します。コストは測定された場合のみ報告します。 要求されたラウンドで停止します。ユーザーが要求した場合のみ、新しいリファインメントを開始します。 その宛先とアクションが要求された場合にのみ、外部ライブラリにコピーまたは取り込みます。
4. リクエストに応じたリファインメント
- 指定されたパーツのより良い写真を関連するビュー(着席、空、横、審査カメラのアングル)から入手します。
ref/SOURCES.mdに出典情報を記録します。 - 最も強力な参照をオーナーの
owner_refsリストの先頭に配置します。各グループは最大6つまでです。 - 前のビルドスクリプト、
tex/、final/{FILE}.blendを新しいrounds/rNN-<focus>/フォルダにコピーします。 そのノートをNOTES_<previous>.mdとして、最後のチェックをrenders/<previous>_check/として、最終レンダリングをrenders/<previous>_final/として保存します。 - templates/TASK_refine.md に記入します。パーツ、ゾーンID、新しい参照を含めます。 変更をそれらのパーツに限定します。ただし、他の場所の重大度3の欠陥は除きます。 写真が矛盾する位置や角度(接続されたパーツを含む)に勝つというルールを維持します。
- 1人のビルダーを実行し、上記のようにレビューし、前回と今回の結果を写真と並べて表示します。
エージェントの引き継ぎと独立した批評
ツール名やモデルのエイリアスを想定せずに、ホストのネイティブエージェントインターフェースを使用します。
リサーチャーまたはビルダーに作業ディレクトリと完全なタスクファイルを渡します。書き込みは割り当てられたプロジェクトまたはラウンドディレクトリ内に保持します。
タスクは DONE.txt を書き込んで終了します。
ビルダーの委任が利用できない場合は、同じタスク境界を維持しながら直接ビルドします。
ルール11の批評家はビルダーから独立している必要があります。photo_check.py はプロンプトと critic_jobs.json マニフェストを準備します。
各プロンプトを新しいレビューアに送信します。レビューアは画像/ファイル読み取りのみが可能で、ネットワークや編集ツールは使用できません。
JSON応答をマニフェストの response_file に保存し、マージします。ホストがサポートする場合のみ、批評家を並行して実行します。critic.parallel を尊重します。
プロンプトが画像/ファイル読み取りを参照する場所では、ホストの画像ビューアを使用します。
独立したサブエージェントが利用できない場合、--runner claude を使用して、インストール済みで認証済みのClaude Code CLIを使用できます。
それ以外の場合は、レンダリングと準備されたレビュージョブを納品し、独立した批評は不完全として報告します。
ビルダー自身のレビューを代用し、それを独立したものと呼ぶことはしないでください。
チェック
| スクリプト | 目的 |
|---|---|
run.py / render.py | ロックされたCyclesシーンでプレフィックスに一致するコレクションをレンダリング。カメラPNGと sheet.jpg を書き込みます。 |
photo_check.py | レイアウトゾーンをクロップし、独立した批評家ジョブを準備し、JSON応答を critique.md にマージします。--from でレンダリングを再利用。--groups でオーナーを選択。 |
game_check.py / game_check_bl.py | GodotのLODメッシュ、UV、凸コリジョン、埋め込みGLBテクスチャを検証。LODターンテーブルを生成します。Unreal検証については GAME_READY.md を参照。 |
compare_rounds.py | ラウンド間の比較と、参照行を含むフォーカスクロップの比較。 |
audit_round.py | オプションで、サポートされているトランスクリプトを検査し、ファイルアクセス、兄弟ラウンド、Web呼び出し、測定されたトークン使用量を確認します。 |
レビューの原則
- 弱点部分のより良い写真は、通常、ブリーフにルールを追加するよりも効果的です。
- 各リファインメントを前のラウンドと比較します。修正が以前の改善を消してしまうことがあります。
- プロポーションの不満は、ジオメトリを変更する前にスケール一致のオーバーレイで確認します。
- 暗い空洞には、目に見えるリップハイライト、壁の厚さ、内部の減衰が必要です。明るくするのは検査のみを目的としています。審査用の照明は固定したままにします。ハイキー画像をクリッピングする場合は明るくするのをスキップします。
- 批評はラウンド内の修復リストとして使用し、ラウンド間の数値スコアとしては使用しません。