レンダー ループ

パイプラインは、バッチまたはビューポート レンダリングのいずれかの要件に基づいて設定することができます。各設定は呼び出すことができる場合とできない場合があり、一連の設定はレンダーごとに呼び出すことができます。したがって、レンダー ループのロジックは、単一フレーム内で実行されるすべての設定で構成されます。

このスキームでは、レンダー項目を設定で定義されているとおりに、さまざまなレンダリング コンテキストに基づいて更新および描画することができます(またこれは一般的な動作です)。

レンダリング コンテキストは、使用可能なデータに基づいて論理的に 2 つのパーツに分割することができます。描画時に使用できるデータの使用可能なセットは、描画コンテキストと呼ばれます。

描画コンテキストには、基になる GPU コンテキストや状態が反映されます。一般的に、状態の最も大きな変化は、レンダー項目の描画中に発生します。状態の変化には、オブジェクトからワールドへの行列、バインドされたシェーダ、現在のブレンド状態、現在バインドされているテクスチャなどがあります。一般的に、カメラの行列やビューポートの寸法などの状態はパイプライン内で一定であるため、描画時にも一定です。

描画時に使用できる情報に加えて、セマンティック分類のレイヤを含むレンダリングの基本設定をトラッキングすることもできます。特に、コンテキストには、表示モード分類およびオブジェクトの論理分類を反映することができます。表示モードには、ワイヤフレーム、シェーディング、テクスチャ、ハイライト、透明などの分類があります。たとえば、レンダー項目は、「透明」であることを示すセマンティックで明示的にタグを付けることができます。後者の例には、塗り潰されたサーフェス、UI、グリッド、オーバーレイなどがあります。

これらの追加の概念により、前のパイプラインの説明をレンダリングおよび描画コンテキストの概念、リストとしてレンダリング可能なオブジェクトのコレクションで拡張し、分類フェーズを追加することができます。

図 9

分類では、セマンティックに加え、シェーダとデータのプロパティを利用して、追加のリストを作成するかどうかを決定します。これらのリストのレンダー項目は、追加のリストにフィルタされない項目と同じようにパイプラインに送られます。

特定の時間に読み取りまたは書き込みできるデータを含むコンテキストがパイプライン全体に存在します。必要ではない場合、描画コンテキストは提供されません。特に、ジオメトリ データの更新中、描画コンテキストは不要です。

具体的な例として、透明度の処理があります。透明度リストは分類によって作成される場合があり、その結果、不透明なレンダー項目を処理する描画フェーズと、透明な項目を処理する描画フェーズが生成されます。多くの場合、古いシステムであっても、プラグインがさまざまなコンテキストで複数回描画される可能性があることは考慮されません。これはレンダリングの設定に基づいて、さまざまな理由で一般的に起こる可能性があります。

以下に示すもう 1 つの例では、シャドウ マップ生成「パス」の後にビューティ「パス」が続いています。各パスには、そのパスに関連するセマンティックがあるといえます。「パス コンテキスト」は、このような情報をグループ化します。それぞれが独自の設定パラメータを使用してパイプラインを実行します。レンダー項目は合計で 2 回以上描画されることがあります。

図 10

シャドウ マップの生成パイプラインでは、レンダー コンテキストに、影付けするライトに基づくカメラがあります。パス コンテキストは、シャドウ マップを作成するためのレンダリングが行われていることを示します。分類によって、「シャドウ キャスタ」以外のすべてが削減され、他のすべてのレンダー項目は破棄されます。

図 11

この例では、ビューティ パス パイプラインで、不透明なオブジェクトと透明なオブジェクトがすべて抽出されて、それらはレンダリング用に 2 つのリストに配置されます。その他のすべてのレンダー項目は破棄されます。ビューティ パス コンテキストは、ビューティ パスが実行されていることを示す情報を提供し、さらに不透明または透明どちらのリストがレンダーされているかを示します。

これらは、単に内部シナリオの例です。API はカスタマイズ可能なレンダー ループに対してオープンであるため、プラグインを呼び出してフレーム レンダーで一度だけ更新または描画されるとは限りません。