URPのScriptableRendererFeatureとRenderGraphを「旅行ツアー計画」で例えてみる

はじめに

URPのカスタムレンダリングに触れたとき、初見のときはどのコードがどこでいつ実行されるのかよくわからず混乱しました。
本記事では、 旅行ツアー計画 に例えて、仕組みを整理してみます。

全体像

各概念、旅行ツアー計画に例えると、以下のようなイメージです。

• ScriptableRendererFeature = 行程表（当日のプランを作る）
• ScriptableRenderPass = 観光スポット訪問枠（観光スポットでなにをやるか決める）
• RenderGraph = ツアーガイド（当日に観光の順番や内容を最適化する）

ScriptableRendererFeature

実際の仕組み

初めて触れたときは「シーン開始時だけ動くのか？」「毎フレーム呼ばれるのか？」と迷いました。

実際には以下のような動きです。

• Create() … 初期化処理。Rendererの生成時に1回だけ呼ばれる
• AddRenderPasses() … 毎フレーム・各カメラごとに呼ばれ、そのフレームの処理を組み立てる

旅行ツアーでたとえると

• Create() … ツアー準備
• AddRenderPasses() … 当日の行程表づくり（どの観光地を回るかリスト化）

ScriptableRenderPass

実際の仕組み

描画処理の単位です。シェーダー実行を含む具体的な処理を担当します。
実際には、Execute() メソッドが呼ばれることでコマンドバッファに処理が積まれ、必要に応じてShaderが走ります。

旅行ツアーでたとえると

各パスは「美術館で展示を鑑賞する予定」「神社で参拝する予定」といった予定に相当します。
そして実際に現地で行動（シェーダー実行）するのが、GPUでの処理です。

RenderGraph

実際の仕組み

RenderGraphはもともとHDRPなどで使われていた仕組みで、URP 2023以降にも導入されました。
リソースの読み書き関係を解析し、実行順序や無駄なコピーを最適化します。

代表的なメソッド：

• AddRasterRenderPass() … パスをRenderGraphに登録し、依存関係に組み込む

旅行ツアーでたとえると

RenderGraphはツアーガイドのような存在です。
混雑や移動時間を考慮して、効率的なルートを提案してくれます。

おまけ：cameraColor で混乱した話

UniversalResourceData.cameraColor という名前を初めて見たとき、
「カメラから取得したピクセルの色そのもの」を扱っているように思いました。

実際にはそうではなく、RenderGraph管理下の仮想的なテクスチャ（ハンドル）への参照でした。
実際のピクセル配列ではなく、描画処理を構築するためのリソース参照です。

誤解と整理（早見表）

誤解	正しい理解
Featureはシーン起動時だけ動く？	毎フレーム・各カメラごとに処理を組む
RenderGraphは新しい描画API？	パス/リソースの依存を最適化する実行計画エンジン
C#でGPUの色計算を書いている？	C#は命令の組み立て、色計算はShader
cameraColorはピクセル色そのもの？	仮想テクスチャ（ハンドル）の参照

おわりに

この記事は「過去の自分へのハンドブック」です。
同じ地点で迷子になった人への“地図”として役立てばうれしいです。