グラフィック プログラミングの概要

作業を開始する

Unreal Engine 4 (UE4) にはレンダリング コードが数多くあるため、概要を把握するのは大変です。コードを使った読み取りは、新規フレームがレンダリング スレッド上でレンダリングされる FDeferredShadingSceneRenderer::Render から開始するのが良いでしょう。profilegpu コマンドを実行し、描画イベントを調べるのも便利です。Visual Studio で描画イベントに対して [Find in Files (ファイルを検索)] を実行して、対応する C++ インプリメンテーションを検索します。

• シェーダの操作方法の詳細は、シェーダー開発 を参照してください。

• UE4 で使用する座標空間用語の説明については、 座標空間の専門用語 を参照してください。

レンダリング処理に便利はコンソール コマンドです (? をパラメータとして使用し現在のステートにパラメータがない場合は通常ヘルプがでます)。

レンダリング作業時に便利なコマンドラインです。

モジュール

モジュール内に存在するレンダリング コードは、非モノリシック ビルド用に dll にコンパイルされます。そのため、アプリケーション全体を再度リンクする必要がなくなり、コード変更のレンダリング時のイタレーションが速くなります。レンダラのモジュールはエンジンへの呼び戻しが多いのでエンジンに依存します。ただし、エンジンがレンダラの中でコードの呼び出しが必要な場合、通常は IRendererModule か FSceneInterface のインターフェース経由で行われます。

シーンの表現

Unreal Engine 4 では、レンダラが見るシーンは、Fscene に格納されている様々な種類の他の構造体のプリミティブ コンポーネントとリストによって定義されます。プリミティブの octree は空間クエリを加速するために更新されます。

主要なシーン クラス

UE4 にはゲーム スレッドと平行して動く レンダリング スレッド があります。ゲーム スレッドとレンダリング スレッド間のギャップを埋めるクラスのほとんどは、そのステートのオーナーシップをどちらのスレッドが保有するかによって 2 つに分かれます。

主要なクラスは以下のとおりです。

以下は、属するモジュール別に整理した主要クラスのリストです。リンカー問題の解決方法を探す場合に重要になります。

同じクラスをステートのオーナーシップを所有するスレッド別に整理しました。競合状態を避けるために 、コードを書いたステートを所有するスレッドがどれかを常に覚えておくことが重要です。

マテリアル クラス

プリミティブ コンポーネントとプロキシ

プリミティブ コンポーネントは、可視性と関連性を判断する基本ユニットです。例えば、オクルージョンと視推体カリングはプリミティブごとに行われます。従って、システム作成時に、作成するコンポーネントの大きさを考えることが重要です。それぞれのコンポーネントには、カリング、シャドー キャスティング、ライトの影響の判断などの各種操作に使用するバウンドがあります。

コンポーネントは登録された場合のみ、シーン (つまりレンダラ) で可視化されます。コンポーネントのプロパティを変更するゲーム スレッド コードは、コンポーネント上で MarkRenderStateDirty() を呼び出し、レンダリング スレッドに対して変更を伝搬しなければなりません。

FPrimitiveSceneProxy と FPrimitiveSceneInfo

FPrimitiveSceneProxy は、コンポーネントの種類によってサブクラス化されることになる UPrimitiveComponent のレンダリング スレッド版です。エンジン モジュールに存在し、レンダリング パス中に呼び出される関数を持っています。FPrimitiveSceneInfo は、レンダラ モジュールに対して private なプリミティブ コンポーネント ステートです。

重要な FPrimitiveSceneProxy メソッド

シーン レンダリングの順序

レンダラは、データを合成したい順序でレンダラ ターゲットに対してシーンを処理します。例えば、深度のみのパスはベース パスの前にレンダリングされるので、ベース パスのシェーディング負荷を減らすために Heirarchical Z (HiZ) がエントリされます。この順序は C++ で呼び出される order pass 関数によって静的に定義されます。

関連性

FPrimitiveViewRelevance は、エフェクト (従ってパス) とプリミティブとの関連性に関する情報です。プリミティブは関連性の異なる複数のエレメントをもつ場合があるので、FPrimitiveViewRelevance は効果的にロジカルな関連性あるいは全てのエレメントの関連性となります。つまり、プリミティブは不透明および透過な関連性、あるいは動的と静的な関連性を併せ持つことが可能であり、相互排他的ではないということになります。

さらに FPrimitiveViewRelevance は、プリミティブが bStaticRelevance や bDynamicRelevance で動的または静的レンダリング パスを使う必要があるかどうかを示します。

描画ポリシー

描画ポリシーには、パス専用シェーダーでメッシュをレンダリングするためのロジックが含まれます。メッシュタイプの取得には FVertexFactory インターフェースを、マテリアルの詳細の抽出には FMaterial インターフェースを使用します。詳細レベルで、メッシュ マテリアル シェーダーセットと頂点ファクトリを受け取り、頂点ファクトリのバッファを Rendering Hardware Interface (RHI) に結合し、メッシュ マテリアル シェーダーを RHI に結合し、適切なシェーダー パラメータを設定し、 RHI ドロー コールを発行します。

描画ポリシー メソッド

レンダリング パス

UE4 には、制御能力は大きくトラバース速度が遅い動的パスと、 RHI レベルにできるだけ近くでシーン トラバースをキャッシュする静的レンダリング パスがあります。両者とも詳細レベルでは描画ポリシーを使用するので、違いはほとんど大まかなレベルです。それぞれのレンダリング パス (描画ポリシー) は必要に応じて両方のレンダリング パスに確実に対処する必要があります。

動的レンダリング パス

動的レンダリング パスは TDynamicPrimitiveDrawer を使い、それぞれのプリミティブ シーン プロキシ上に DrawDynamicElements を呼び出してレンダリングします。レンダリングされるために動的パスを使用する必要のあるプリミティブは FViewInfo::VisibleDynamicPrimitives でトラックされます。それぞれのレンダリング パスはこの配列を繰り返し、それぞれのプリミティブのプロキシ上で DrawDynamicElements を呼び出す必要があります。その後、プロキシの DrawDynamicElements は FMeshElements を必要な数だけ集めて DrawRichMesh あるいは TDynamicPrimitiveDrawer::DrawMesh でサブミットする必要があります。その結果、CreateBoundShaderState、DrawShared、SetMeshRenderState、最終的には DrawMesh を呼び出す一時的な描画ポリシーが新規作成されます。

それぞれのプロキシはそのコンポーネント タイプ固有のロジックを実行できる DrawDynamicElements にコールバックがあるので、動的レンダリング パスは非常に柔軟です。さらに、ステートのソート処理がなく、何もキャッシュされないので、挿入負荷は最低限ですがトラバース負荷は高くなります。

静的レンダリング パス

静的レンダリング パスは、静的描画リストによって実装されます。メッシュはシーンにアタッチされると描画リストに挿入されます。挿入されている間にプロキシ上に DrawStaticElements が呼び出されて FStaticMeshElements がコレクトされます。すると、CreateBoundShaderState の結果に合わせて描画ポリシー インスタンスが作成および格納されます。Compare 関数および Matches 関数に合わせて新規の描画ポリシーがソートされ、描画リストの適切な位置に挿入されます (TStaticMeshDrawList::AddMesh 参照)。InitViews では静的描画リスト用の可視性データを含むビット配列が初期化され、描画リストが実際に描画される TStaticMeshDrawList::DrawVisible へ渡されます。DrawShared はお互いに一致するすべての描画ポリシーに対して 1 回だけ呼び出されますが、SetMeshRenderState と DrawMesh は FStaticMeshElement ごとに呼び出されます (TStaticMeshDrawList::DrawElement 参照)。

静的レンダリング パスはかなりの作業をアタッチ時へ移動させるので、レンダリング時のシーン トラバースが大幅に高速化されます。静的描画リストのレンダリングは、スタティックメッシュのレンダリング スレッドで速度が約 3 倍になるので、さらに多くのスタティックメッシュをシーンに持つことが可能になります。静的描画リストはアタッチ時にデータをキャッシュするので、ビューを個々のステートでのみキャッシュできます。再アタッチされることが滅多になく頻繁にレンダリングされるプリミティブは、静的描画リストの候補として最適です。

静的レンダリング パスは、ステート バケットにつき 1 回だけ DrawShared を呼び出す方法なので、バグのエクスポートができます。これらのバグは、シーンでメッシュをレンダリングおよびアタッチする順序に依存するため、検出が難しいです。ライティングのみや、unlit (ライティング無し) などの特別なビューモードは、全てのプリミティブに動的パスを強制的に使用させます。そのため、動的レンダリング パスを強制した結果バグがなくなった場合は、描画ポリシーの DrawShared 関数あるいは Matches 関数の実装が正しくなかったことだと分かります。

レンダリングのおおまかな順序

以下は、 FDeferredShadingSceneRenderer::Render: で始まるフレームのレンダリング時の制御フローの説明です。

かなり簡素化されたおおまかなビューです。詳細は、 'profilegpu' の関連コードかログ出力を調べてください。

Render Hardware Interface (RHI)

RHI は、プラットフォーム専用のグラフィック API 上の薄いレイヤーです。UE4 の RHI 抽出レベルはできる限り詳細レベルになっています。目的は、ほとんどの機能はプラットフォーム非依存コードで書くことができ、要求される機能レベルをサポートする全てのプラットフォームで「動作するだけ」にすることです。

複雑度を低く保つために、機能セットは ERHIFeatureLevel の中で量子化されます。プラットフォームが機能レベルで要求される機能の全てをサポートできない場合は、サポートできるレベルまで落とします。

レンダリング ステートのグループ化

レンダリング ステートは、影響を与えているパイプラインの部分によってグループ化されます。例えば、RHISetDepthState は深度バッファに関連する全てのステートを設定します。

レンダリング ステートのデフォルト

レンダリング ステートは数が多いので、描画のたびに一つ一つ設定するのは大変です。UE4 には、デフォルト設定を前提にした暗示的なステートが入っているので (従って変更した場合はこれらのデフォルトにリストすること)、明示的が設定が必要なステートはかなり少ないです。以下のステートには暗示的なデフォルトがありません。

• RHISetRenderTargets
• RHISetBoundShaderState
• RHISetDepthState
• RHISetBlendState
• RHISetRasterizerState
• RHISetBoundShaderState で設定されるシェーダーの依存

その他のすべてのステートはデフォルト状態を想定します (例えば、関連する TStaticState で定義されているようにデフォルトのステンシル ステートは RHISetStencilState(TStaticStencilState<>::GetRHI()) で設定されます)。