mcpField
B
blender-rendering-workflow

blender-rendering-workflow

github.com/ifbarsクリエイティブ・メディア9792 回インストール5 日前に更新
リポジトリ

blender-rendering-workflow について

3D シーンを制作・納品するエージェント向けに、再現可能な Blender レンダリング手順をまとめたスキルです。シーン設定、レンダリングの反復、ノイズ除去、画像検証を扱い、出力マニフェストの確認も定めています。

主な機能

  1. 01再現可能なレンダリング設定
  2. 02カメラと照明の確認
  3. 03プレビュー・最終ノイズ除去の指針
  4. 04レンダリング証拠とマニフェストの確認
  5. 05納品と完了の基準

活用シーン

  1. 01最終静止画向けのシーン準備
  2. 02マテリアル、照明、構図の問題診断
  3. 03アニメーションフレームのレンダリングと確認
  4. 04クリーンな Blender プロセスでのシーン検証

MCP 対応

MCP Apps 対応ホストで、制作済みシーンのレンダリングに `blender_render_scene`、標準化されたジオメトリ確認に `blender_render_evidence` を使う方法を説明します。インライン画像の結果とビューアーの動作も扱います。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ifbars/blender-agent-studio --skill blender-rendering-workflow

インストール後、Claude Code で/blender-rendering-workflowを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

agents/
openai.yaml
references/
astra-workflow.md
interiors-and-atmosphere.md
modeling-timelapse.md
poly-haven-materials.md
scripts/
fixture_modeling_timelapse.py
modeling_timelapse.py
poly-haven-cli.ts
poly-haven.ts
render_authored_evidence.py
render_scene.py
render_timelapse.py
test_denoise_capability.py
test_denoise_policy.py
test_modeling_timelapse.py
test_render_scene.py

詳細

Blender レンダリングワークフロー

自律的な判断、エビデンスの収集頻度、長時間タスクの継続性については、タスクごとに一度、 共通の実行ガイダンスをお読みください。

レンダリングは、一度だけたまたま見栄えよくできたスクリーンショットではなく、再現可能な成果物として扱ってください。

看板やグラフィックの面が読み取りにくい場合は、利用できるなら 看板の統合ガイドを参照してください。ライティングを変更する前に、フラットなアートワークと作成したカメラからのビューを比較してください。レイアウト、投影されたテキストのサイズ、UV の歪み、テクスチャのフィルタリングが原因である可能性があります。印刷面、バックライトパネル、スクリーンを区別し、すべての面を発光させないでください。

モデリングや構築のタイムラプスを依頼された場合は、 チェックポイントのキャプチャと動画の納品に従ってください。モデリングを始める前に、実際の空またはデフォルトのシーンの録画を開始し、実際の作業段階を記録してから、完了後にレンダリングとエンコードを行います。これは任意で、依頼がない限り無効です。最終シーンだけでは、モデリングの履歴を復元できません。

シーン全体を装飾する場合は、モデリングワークフローの シーン全体のワークフローもお読みください。作成したカメラの構図とマテリアルのレビューは、標準化されたジオメトリのエビデンスとは分けてください。プレゼンテーションの仕上げに入る前に、弱い形状や二次的な箇所を修正してください。

建築、光の筋、または布地の多いシーンについては、 インテリアと雰囲気をお読みください。 フォトリアルなマテリアルや環境ライティングには、 スキャンマテリアルと HDRIを使用してください。同梱の Poly Haven 検索・ダウンロードツールを使うと、検証済みの CC0 マップを最大 8K で取得できます。シーンの重要な形状は自ら作成してください。ただし、リアリズムを損なうような「一からのみ作成する」という制約は設けないでください。

作成済みシーンを活用する

最終的な美しいレンダリングやライティングの診断には、blender_render_sceneを使用します。 カメラ名、依存関係、レンダリング設定が不明な場合は、まずinspectOnly: trueを指定して呼び出します。その後、既存のcamerasから正確な名前で選択し、必要に応じてframesを指定します。カメラとフレームの組み合わせは最大12個までです。デフォルトではアクティブなカメラとフレームを使用し、最長辺を1280、Cyclesのサンプル数を64に制限します。また、利用可能なGPUを自動選択し、明示的に記録されたCPUへのフォールバックを使用します。再現性が必要な場合は、device: "cpu"または特定のバックエンドを選択してください。デスクトップを共有している場合は、Blenderコマンドを一度に1つだけ実行し、検証済みのGPUバックエンドを優先してください。CPUの余力を確保するには、--threads 2、scene.render.threads_mode = 'FIXED'、scene.render.threads = 2を使用します。モデリング、依存関係の更新、エクスポートは引き続きCPUを使用します。スレッド設定だけでは、CPU全体の使用量は制限されません。リポジトリの比較キューでは、これに加えてWindowsのプロセスツリーに上限を設定します。フォールバックが必要な場合は、GPUの初期化失敗を記録し、CPUスレッド数を少ないまま維持してください。 GPUレンダリングを有効にしても、GPUによるデノイズは自動的に有効になりません。サポートされているOpenImageDenoiseのGPUアクセラレーションを優先し、denoising_use_gpuを明示的に有効にしてください。それ以外の場合は、サポートされているOptiXのGPUデノイズを使用します。実際に使用されたデノイザーとGPUフラグを記録し、作成時の品質設定を維持して、二重のデノイズを避けてください。 MCP Apps互換のホストでは、ビュー選択、全体表示/100%ズーム、展開可能な詳細情報を備えたコンパクトな画像ビューアーが表示されます。それ以外のホストでは、インライン画像と構造化された結果がそのまま表示されます。ビューアーに表示されるのは完了したレンダリングであり、進行状況は表示されません。 単体で納品する画像のサイズを明示するには、--render-edge 1536を指定すると、作成時のサイズを超える場合も含め、アスペクト比を維持したまま最長辺をそのサイズにしてレンダリングします。--max-edgeのみを指定した場合は上限として機能し、作成時の解像度は引き上げられません。実行ごとに新しい出力ディレクトリを使用してください。インラインPNGとrender-manifest.jsonを確認してください。エラーは正常に完了したことの証拠にはなりません。

単体で実行できる同等のスクリプトは、このスキルに同梱されています。

& $env:BLENDER_EXECUTABLE --background --factory-startup --disable-autoexec `
  --python-exit-code 1 --python "<skill-root>/scripts/render_scene.py" -- `
  --input scene.blend --output-dir renders/preview-01 --max-edge 1280 --samples 64

これにより、作成済みのライト、ワールド、ボリューム、カメラ、マテリアル、カラー管理が維持されます。blender_render_evidenceはカメラとライティングを意図的に置き換えます。標準化されたジオメトリの確認には使用できますが、室内シーンの最終画像には使用しないでください。

証拠画像を開く前に、出力されたマニフェストを読み、正確な画像パスを確認してください。render_evidence.pyはcontact_sheet(通常はcontact_sheet.png)を含むevidence.jsonを書き出します。render_scene.pyは、renders以下にカメラ/フレーム別のパスを含むrender-manifest.jsonを書き出します。ハイフン入りのコンタクトシートのファイル名を推測したり、画像が見つからないことを正常な目視確認として扱ったりしないでください。 どちらのツールも、永続化できるソースでシーンを作成する作業の代わりにはなりません。

タスクに応じてデノイズを選択する

通常の低解像度レンダーでは、Blender のビューポートプレビュー設定ではなく、レンダーデノイズ設定が使われます。ルック開発用のレンダーには denoise: "preview" を、残留ノイズが見える最終静止画には denoise: "final" を選択してください。CLI では --denoise preview または --denoise final が該当します。

  • プレビュー:対応している場合は GPU の OpenImageDenoise Fast と Fast プリフィルターを優先します。それ以外の場合は、対応していれば GPU OptiX、次に CPU OIDN Fast を使います。構図とマテリアルを確認する間は、控えめなサンプル上限(例:16-32)と 512-800px を使用します。
  • 最終:OpenImageDenoise High、Accurate プリフィルター、Color + Albedo + Normal を使用し、対応していれば GPU アクセラレーションを使い、それ以外の場合は CPU にフォールバックします。シーンに適したサンプル予算から始め、最終レンダーだからという理由だけでサンプル数を増やさないでください。
  • denoise: "off" は、すでにノイズのない画像や、ノイズやディテールをそのまま確認する場合に、レンダーデノイズを無効にします。作成済みのコンポジターデノイザーは無効にしません。
  • denoise: "preserve" は、意図的に作成された設定や再現性のある比較のための、後方互換性を保つデフォルトです。

Blender ビルドにコンパイル済みの OpenImageDenoise がなく、対応する OptiX デノイザーもない場合は、プレビュー/最終レンダーをデノイズなしで行い、マニフェストに理由とともに effectivePolicy: "off" を記録してください。ノイズを確認し、上限のあるサンプル予算を増やすか、必要に応じて公式 Blender ビルドを使用してください。このフォールバックによって、preserve モードや作成済みのコンポジターデノイザーが暗黙に変更されることはありません。

納品サイズでテクスチャ、細いエッジ、接地影、反射を確認してください。表面がぼやけて見える場合は、サンプル数を増やす前に、小さな未処理の切り抜き、または対応するデノイズなしのプレビューと比較してください。デノイズ処理は 1 段階にしてください。既存の有効なコンポジターデノイザーがある場合、プレビュー/最終ポリシーは作成済みの設定に従います。マニフェストで実際の設定とフォールバックの理由を確認してください。デノイズでは、不十分なジオメトリ、欠けているテクスチャ、または不適切なライティングは修正できません。また、これらのポリシーがピクセルベースのノイズ検出を示唆するものではありません。アニメーションでは、シーケンスを確定する前に連続するフレームを確認し、ちらつきがないか調べてください。

ローカルのマグカップ/リネンのテストでは、低コストなプレビューにおいて CPU OIDN より GPU OIDN が適していました。これは特定のハードウェアとシーンでの結果であり、速度の普遍的な順位ではありません。デノイザー、プリフィルター、品質のトレードオフについては、Blender のサンプリングに関するドキュメントを参照してください。

レンダリングの要件を明確にする

シーンを変更する前に、以下を記録してください。

  • 想定する視聴者、視距離、参考にする雰囲気、必要なストーリー展開。
  • 静止画、ターンテーブル、画像シーケンス、または動画のいずれを納品するか。解像度、フレーム範囲、フレームレート、出力形式。
  • レンダーエンジン、デバイスの前提、時間/ノイズの予算、および後続のエンジンやコンポジターとの一致が必要かどうか。
  • 必要なカメラ、メインビューと診断用ビュー、レンダーパス、アルファ、カラー管理の要件。
  • 作成済みの成果物に含まれるライト、ワールド、マテリアル、ボリューム、コンポジターノード。

これらの設定は、シーン生成用の永続的なスクリプト内で名前付き定数として保持してください。レンダリング済みの成果物が求められている場合、ビューポートのスクリーンショットを最終的な証拠として使用しないでください。

再現性を確保して作成する

  1. カメラ、ライト、ワールドノード、ビューレイヤー、レンダー設定、出力ノードには、意味が明確な名前を付けます。
  2. エンジン、解像度、フレーム範囲、サンプリング、デノイズの方針、透過フィルム、カラー管理を明示的に設定し、スタートアップファイルのデフォルト設定に頼らないでください。
  3. サンプル数を増やしたり、ポストプロセスを追加したりする前に、意図した焦点距離とカメラの高さで被写体をフレーミングします。
  4. 形状が伝わるようにライティングします。装飾的な効果を加える前に、キーライト、フィルライト、リムライト/背景との分離、接地影、露出を整えます。交差部分やテクスチャの不具合がわかるよう、十分なニュートラルな検証用ライティングを確保します。
  5. 要求された結果の改善につながる場合に限り、レンダーパスとコンポジターノードを使用します。診断用に、コンポジット前のビューティー出力も利用できる状態にしておきます。
  6. ターンテーブルやアニメーションを出力する場合は、まず低コストの短いプレビューをレンダーします。その後、最終フレーム範囲をレンダーする前にカメラとライティングを固定します。
  7. レンダーファームや外部エンジンに引き渡す場合は、Blender のバージョン、エンジン、デバイスの前提条件、アセット、フォント、キャッシュパス、フレーム範囲、出力設定を記載した、自己完結型の引き継ぎマニフェストを出力します。

根拠を確認しながら反復する

通常のアセット引き渡しでは、デフォルトで洗練されたヒーロー向けプレゼンテーションを含めます。アセットのシルエットが際立つ背景、柔らかなキーライト/フィルライト、制御されたハイライト、見える接地影を使い、細部が読み取れるようにフレーミングします。マテリアルの色に合わせ、白地に白、または露出オーバーのスタジオ設定は避けます。距離とエミッターのサイズを同時に拡大する場合は、シーン寸法の二乗に応じてライトのパワーを調整します。

検証レンダラーの auto、neutral、dark、light のプレゼンテーションを出発点として使用します。最初の画像を確認し、コントラスト、透過性、発光、テクスチャに応じてプリセットまたは作成したスタジオを調整します。用途の異なる2つのプレゼンテーションが適している場合は、明確なラベルを付けて両方を納品します。最初に有用な結果を作成する前に、ユーザーにプリセットを選ばせないでください。固定の診断ビューをヒーロー画像と併せて保持し、明示的に指定されたアートディレクションを維持します。スタジオレンダーは、必要なインコンテキストのショットの代わりにはなりません。

  1. 必要なカメラごとに、サンプル数を抑えた診断フレームをレンダーします。
  2. ファイルの存在を示すログを見るだけでなく、レンダー画像を開いて確認します。
  3. 構図、シルエットの分離、露出、スペキュラーの制御、影の接地感、色バランス、テクスチャのスケール、ノイズ/ファイアフライ、クリッピング、要求されたマテリアルが正しく見えるかを確認します。
  4. デノイズ、ブルーム、被写界深度、カラーグレーディングで不具合を隠すのではなく、シーン、マテリアル、カメラ、ライティングに起因する問題を先に修正します。
  5. 最終静止画、または範囲を限定したプレビューシーケンスをレンダーします。コンタクトシートを開き、モーションの場合はエンコード済みの動画またはサンプリングしたフレームを確認します。

完了の判定

クリーンな Blender プロセスでソースから同じ結果を再現でき、最終出力を目視で開いて確認するまでは、レンダーを完了としないでください。正確な出力パス、Blender とエンジンのバージョン、解像度、フレーム範囲、サンプル数/デノイズ、カラー管理、パス、レンダー所要時間、マシン固有の制限を報告します。固定マルチビューによる形状の証拠には $blender-agent-studio:blender-asset-validation を使用します。この証拠はアートディレクションに沿った最終レンダーを補足するものであり、置き換えるものではありません。 発光する被写体をガラスで囲む場合は、ノードグラフだけでなく、最終エンジンで検証します。透過率、アルファ/ブレンドの挙動、屈折、露出、ブルームを制御し、囲いがガラスとして認識できると同時に、発光する被写体の色のシルエットがはっきり残るようにします。マテリアルが技術的に透過性を持っていても、囲いが不透明、または白飛びしていればレンダーの失敗です。

コメント