threejs-image-pipeline について
単一の HDR シーンパスと出力変換を中心に、因果関係のある Three.js 描画グラフを構築・検証するスキルです。信号とエフェクトの所有権、時間履歴、リソースコスト、グラフのライフサイクルを扱います。
主な機能
- 01単一 HDR シーンパスと出力所有者
- 02信号の一覧化とアタッチメント採用
- 03時間履歴とリセット要件
- 04描画エフェクトの順序付き合成
- 05リソースサイズとライフサイクル管理
- 06グラフの診断と検証
活用シーン
- 01ポストプロセスグラフの計画
- 02アタッチメント追加の要否判断
- 03リセット処理を伴う時間方向の再構成
- 04グラフのコストとリソース使用量の計測
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ linegel/ threejs-complete-set-of-skill --skill threejs-image-pipelineインストール後、Claude Code で/threejs-image-pipelineを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSEagents/openai.yamlexamples/rebuild-traa-node.mjsreferences/production-image-pipeline.md詳細
画像パイプライン
因果関係のある画像グラフを1つ構築します。深度を含むHDRシーンパス、選択した共有シグナル、最終出力変換をそれぞれ1つずつ用意します。シーンの再走査やアタッチメントは、計測した結果、代替手段より優れている場合にのみ追加します。
採用する各エフェクトには、個別の担当を割り当てます。
- GTAOと間接光の合成には
$threejs-ambient-contact-shadingを使用します。 - グレアソースの選択と
BloomNodeの制御には$threejs-bloomを使用します。 - 測光、適応、トーンマッピング、LUTのドメインには
$threejs-exposure-color-gradingを使用します。 - 機能ごとの画面履歴には
$threejs-dynamic-surface-effectsを使用します。 - キャプチャ、タイミング、ライフサイクルの証拠には
$threejs-visual-validationを使用します。
1. ベースラインを決める
物理キャンバスのピクセル数、対象のブラウザー/GPU、フレーム予算、主要なビジュアル要件、ポスト処理なしでも見やすい表示を定義します。WebGPURendererを1つ初期化し、renderer.backend.isWebGPUBackendを確認して、RenderPipelineを1つ作成します。pass(scene, camera)を1つ用意し、シーンリニアHDRとその深度テクスチャを所有させます。GPU計測を行う場合は、renderer.init()の前にtrackTimestampを設定します。
このステップの完了条件は、オプションのポスト処理なしでベースラインが描画され、HDRと深度の生成元が明示され、表示を担当するコンポーネントがちょうど1つであることです。
2. シグナルを棚卸しする
候補となるシグナル(HDRカラー、深度、法線、エミッシブ、速度、ディフューズ/ベースカラー、ID、履歴、露出、UI)ごとに、次の項目を記録します。
writer | readers | mathematical/color domain | physical format and extent
first write -> last read | history/reset owner | disable path
深度はMRTのカラー出力ではなく、パスの深度テクスチャとして扱います。実際の読み取り側があるシグナルだけを要求します。
このステップの完了条件は、グラフの各エッジに書き込み元が1つだけあり、すべてのコンシューマーがドメインと範囲について合意し、各オプションシグナルに動作する無効化経路があることです。
3. アタッチメントを採用する
まず、シグナルに宣言されたドメイン、精度/誤差上限、空間カバレッジ、時間的安定性、または破棄セマンティクスを満たせない再構成、アタッチメント、縮小再描画の候補を除外します。残った正しい候補を、対象グラフ上で比較します。
costMRT(a) = export + store/resolve + all later reads
costAlt(a) = reconstruction or narrow rerender + its traffic
正しい候補の中で、組み合わせた証拠によりcostMRT(a) < costAlt(a)が示され、ピーク常駐メモリの予算にも収まる場合は、アタッチメントを維持します。コンパイル済みの物理フォーマットを確認してください。r185の名前付きPassNodeアタッチメントはデフォルトでパス出力を複製するため、コンパクトな法線や速度の格納形式を利用するには、明示的な設定と検証が必要です。
このステップの完了条件は、維持するすべてのアタッチメントに名前付きの読み取り側があり、ドメインと物理フォーマットが検証済みで、誤差/カバレッジ要件が宣言され、正しい代替手段の中で優位であることが計測され、ピークバイト数が計上されていることです。
pass()、MRT、コンパクトなフォーマット、または深度分岐を実装する場合は、グラフの構築とシグナルフォーマットをお読みください。
4. 時間履歴を導入する
レンダリングされるすべてのモーションに、有効な前フレームと現フレームの状態が揃ってから、時間方向の出力を有効にします。
- 剛体のトランスフォーム、インスタンス、ボーン、プロシージャル変形
- 履歴に含めるパーティクルがある場合は、安定したパーティクル/スロットの識別情報
- ジッターなしの前フレーム/現フレームのカメラトランスフォームと、ジッターの適用主体を1つにすること
- 深度、速度、近傍、画面範囲外の棄却
- リサイズ/DPR、カット、投影または原点の変更、シーンの読み込み、生成/消滅、テレポート、再ペアレント化、LOD/トポロジーの変更、不連続な変形に対するリセット
- 現フレーム、履歴、棄却された履歴、速度、ジッター、リセットの診断情報
r185 の速度は currentNDC - previousNDC です。TRAA はこれを Y スケールが負の UV に変換します。標準の TRAANode では、カラー/深度/速度/入力の各エクステントが一致し、MSAA がオフである必要があります。通常の分岐では、既存のカメラビューポートオフセットや任意に指定されたテクスチャの所有者を保持できません。リサイズのロジックで両方が保証されると想定せず、初回フレームと境界の動作を明示的に確認してください。合成した時間方向の入力は、別のテクスチャとフルスクリーン描画を生成します。標準の TRAA には、汎用のリセット用パブリック API もリアクティブマスク入力もありません。そのため、カットや不連続への対応には、根拠のある再構築またはバイパス/再シードのポリシーが必要です。
水平方向と垂直方向のモーションが正しく再投影され、レンダリングされるすべての表現に速度の方針があり、不連続のたびに実行可能なリセットが行われ、時間方向の割り当てすべてに所有者がいる状態になったら、この手順は完了です。
時間方向の再構成を行う場合は、速度ノードまたは履歴ノードを作成する前に、 時間履歴の導入とリセット を参照してください。
サポート対象のリセットに対して標準の TRAANode を再構築する場合は、
最小限の再構築例
を参照してください。この例では、パブリック API で検証済みの置き換え、パブリック設定の保持、出力の再バインド、ガード付きロールバック、グラフの無効化、旧/新リソースの明示的な所有権を示しています。
返された前のノードを破棄するのは、置き換え後のグラフのコンパイルとレンダリングが正常に完了し、前の GPU 世代の処理が完了してからにしてください。
5. 合成は一度だけ行う
デフォルトでは、次の順序を使用します。
HDR scene pass + depth + admitted MRT
-> effect-local lighting histories
-> lighting/AO/atmosphere with valid temporal inputs
-> temporal scene-radiance resolve, when admitted
-> excluded transparent or refractive layers
-> meter tap from resolved pre-bloom HDR, when admitted
-> bloom and other scene-linear optical effects, when admitted
-> fixed or adapted exposure, when admitted
-> tone map, when admitted
-> LUT in its declared domain, when admitted
-> one output conversion
-> display-domain AA, dither, diagnostics, and UI
デフォルトでは、履歴を露出適用前の安定したシーン放射輝度で保持します。ブルームの所有者が不透明、カバレッジでクリップ、またはハローを保持するアルファ分岐を適用します。元のアルファを変更しないだけでは、サーフェス外のハローは保持されません。renderOutput() がプレゼンテーションを担う場合は、
renderPipeline.outputColorTransform = false を設定してください。出力ノードを変更した後は、
renderPipeline.needsUpdate = true を設定してください。
表示されるすべての測光処理、ブルーム、露出、トーンマップ、LUT、アルファ演算、出力変換にそれぞれ1つの所有者があり、透明/屈折レイヤーすべてに明示的な配置が定義されていれば、この手順は完了です。
LUT/出力の終端を選ぶ場合、または透明アルファを扱う場合は、 カラー、アルファ、適切な終端 を参照してください。
6. トグル、サイズ、ライフタイムの管理
組み込みの BloomNode、GTAONode、TRAANode、PassNode が所有する、永続的なプライベートターゲットの数を把握します。getTextureNode() で以前に要求したアタッチメントを解放するには、パスを再構築します。論理的な MRT トグルでは解放されません。リサイズまたは DPR の変更時には、明示的に指定したすべてのサイズを更新し、影響を受けるすべての履歴を再シードします。ノードやパイプラインを破棄しても、グラフが再帰的にクリーンアップされるわけではありません。所有するハンドルを明示的に保持し、処理に失敗した場合は try/finally で借用した状態を復元します。最終的な GPU 使用後に、削除したノード、パス、ターゲット、マテリアル、ストレージを破棄します。
固定 DPR のグラフで安定したタイミングを継続して計測できた後にのみ、適応型 DPR を追加します。増減で異なる滞留時間とクールダウンを設け、固定サイズの処理とピクセルスケールに応じた処理を区別し、サイズ変更後はすべての品質ティアを再計測します。
このステップは、サポートするすべてのトグル、サイズ、ティア、許可されたリソースについて、サイクルを繰り返してもリソース数が安定し、グラフへの変更のたびにパイプラインがダーティ状態になるときに完了です。
トラフィック、プライベートターゲットの常駐、限界コスト、適応型 DPR を見積もる際は、 メモリ、タイミング、適応型解像度を参照してください。
7. グラフを検証する
ポスト処理なしのベースライン、許可された各シグナル、許可された各時間的処理/メーター/ブルーム/カラー分岐の診断、最終出力、物理ターゲットのインベントリーをキャプチャします。ウォームアップ済みのグラフ全体と、許可された代替案に限ったペア比較の限界差分を、シーン状態を同一にして計測します。該当するネガティブコントロールを実行します。サポート対象の各オプションエフェクトを無効にし、許可された履歴が管理する各リセットクラスを強制し、許可されたサイズ依存リソースをリサイズし、グラフを破棄して再作成します。
キャプチャ、タイミング範囲、リセット、出力分離、ライフサイクルの制御で問題が発生した場合は、診断と障害の兆候を参照してください。
サポート対象のすべてのリリース用ティアでビジュアル契約が保たれ、グラフ全体と常駐ターゲットが宣言された予算を満たし、出力分離によって出力変換が 1 回、許可されている場合はトーンマッピングが 1 回であることが確認され、許可されたすべての時間的分岐と軸で診断に合格し、破棄後のライフサイクル数が一定値に達すると、パイプラインは完成です。