シェーダ インスタンス
各レンダー項目(MRenderItem)には、シェーダとの 1 対 1 の関係があります。全体のフレームワークはプログラマブル シェーディングに基づいていますが、MShaderInstance はハードウェア プログラマブル シェーダのラッパーです。このセクションでは、既にハードウェア エフェクトを使い慣れているものと仮定して説明を進めます。
この特定のインタフェースは、レンダリング フレームワークと共にエフェクト ベースのシェーダを使用するための、最も統合されたソリューションを提供することを目的としています。このインタフェースにおける重要なプロパティは、簡易化、柔軟性、管理性、相互運用性です。
古いインタフェースで最も一致するものは、ハードウェア シェーダ プラグイン インタフェース(MPxHwShaderNode)です。次に示す一覧表で、MPxHwShaderNode と MShaderInstance との比較を示します。
それぞれの「エコ システム」を図で示します。
 図 24 |  図 25 |
左の図では、MShaderInstance がフレームワークの一部として組み込まれています。MShaderManager クラスが表示されています。これは、内部リソース管理システムによって保持されているシェーダ リソースへの API インタフェースです。右の図では、MPxHwShaderNode の有効な設定を示しています。すべての「カスタム」ボックスは、プラグイン ライタで記述する必要があります。
ここではシェーダ インスタンスとシェーダという異なる用語を使用していることに注意してください。この 2 つは次のように区別しています。シェーダはアルゴリズムの定義と入力/出力パラメータの定義を提供します。これに対しシェーダ インスタンスは、シェーダの特定のインスタンスに対してパラメータ入力値やバインドを定義します。
シェーダ インスタンスを取得するには、マネージャのインタフェースを使用して、ディスクからエフェクト ファイルをロードするか内部的に作成されたインスタンスを取得します。マネージャの重要なプロパティは次の通りです。
- ディスクからエフェクト ファイルを使用した場合、シェーダ コンパイラ マクロが定義されている場合があります。
- 内部キャッシュ メカニズムの使用は必須ではありません。キャッシュが有効になっている場合、ディスク上のエフェクトが変更されると、それが自動的にリロードされます。
- エフェクト ファイルに検索パスを追加することができます。
- シェーダ インスタンスを取得する場合、特定のテクニックを指定する必要があります。別のテクニックを使用する場合、別のシェーダ インスタンスを取得する必要があります。テクニックが指定されない場合は、エフェクト ファイルで指定されている既定のテクニックが使用されます。
MShaderManager::getEffectsFileShader()やMShaderManager::getEffectsBufferShader()などのMShaderManagerでさまざまなインタフェースのいずれかを介してシェーダを取得する際に、シェーダ コンパイルの失敗が発生すると、Windows および Linux の場合は出力ウィンドウ(Output Window)に、Mac の場合はコンソールにエラーが出力されます。これはシェーダ開発者のデバッグ プロセスに役立ちます。シェーダを返せない場合、NULL 値が返されます。
各シェーダ インスタンスのプリ/ポスト コールバック関数を指定することができます。これは、たとえば、現在の図面のコンテキストに基づいてパラメータを更新する場合などに便利です。 MShaderInstance::DrawCallback インタフェースから、カスタム コールバックを派生させることもできます。
パラメータは、コールバックの内側または外側のいずれかにいつでも設定できます。サポートされているパラメータ タイプには、ブール、整数、浮動小数点のタプル、行列、テクスチャとテクスチャ サンプラ、レンダー ターゲットがあります。パラメータを更新するには、一般的に、パラメータ リストを照会してから、必要なパラメータごとに MShaderInstance の適切なメソッドを使用して値を設定します。
パラメータに関連付けられているセマンティックも照会することができます。 一般的に、システム定義のセマンティックを持つパラメータはすべて自動的に更新されます。これには object-to-world 行列などのユニフォームが含まれます。サポートされるセマンティックのリストについては、「ビューポート 2.0 でサポートされるシェーダのセマンティック」を参照してください。
MShaderInstance::requiredVertexBuffers() メソッドを使用すると、指定したシェーダ インスタンスの頂点バッファ記述子のリスト(MVertexBufferDescriptorList)を照会できます。特に、サブシーン オーバーライドは、カスタムのレンダー項目にシェーダ インスタンスを使用する際にこのメソッドを利用できますが、このメソッドはこのオーバーライドのコンテキスト外で呼び出すことができます。
シェーディングとレンダリング ジオメトリの間には自然な分離があります。このため、変更パラメータ(ジオメトリ アトリビュート)は、シェーダ パラメータとして公開されていません。パイプラインのレンダリング フェーズが自動的にジオメトリ データのバインドを処理して、レンダリング用の描画呼び出しを行います。
変更パラメータのバインドがセマンティックに依存しているため、カスタムのエフェクトはすべて、変更パラメータ用の適切なセマンティック タグで記述される必要があります。下記にサンプルの頂点シェーダ入力構造を示します。位置および法線の要件タグが記述されています。
struct VS_INPUT {
float4 Pos : POSITION; // Position semantic to bind positional data streams
float4 Norm : NORMAL; // Normal semantic to bind normal data streams
};
シェーダ インスタンスの統合の一部として、インスタンスは任意の透明度で描画するかどうかを指定することができます。 これは、パイプラインの流れの中で、レンダー項目(MRenderItems)の分類に役立ちます。
更新フェーズを再考すると、主な部分は次のようになります。
図 26
「シェーダ」の代わりに、MShaderInstance インスタンスは、MRenderItem によって参照されます。MShaderInstance で表現されるシェーダのジオメトリ アトリビュートは、頂点記述とインデックス記述のセットを提供し、これにより更新時に使用される要件が指定されます。
更新フェーズと描画フェーズが存在するパイプラインは次のようになります。
図 27
上記の図では、前の図にあった抽象的な構成要素の一部は、API で公開される構成要素に置き換えられています。更新フェーズでは MRenderItems (および、それらに関連付けられた MShaderInstances)を生成します。レンダー項目が「透明度」レンダー項目リストに転送されるようにするために、統合フェーズおよび分類フェーズ中は MShaderInstance 上の透明度インジケータが考慮されます。描画フェーズ中に、MRenderItem が検査されます。対応する MShaderInstance はシェーダを設定し、MShaderInstance のパラメータ値に基づいて実際のハードウェア シェーダを更新します。MGeometry 内で参照されるジオメトリはバインド、描画されます。MShaderInstance に関連付けられたすべてのプリ/ポスト コールバックは、適切な時間に呼び出されます。
固定関数のマテリアル設定に使用される古いインタフェースが 1 つ存在します。これは MMaterial インタフェースといい、UI DAG オブジェクト インタフェース(MPxSurfaceShapeUI)と連携して使用されます。プログラマブル シェーダと固定関数の古い描画フレームワークが混在することはないので、MShaderInstance と UI オブジェクトの間には何も接続がありません。
統合に関する考慮事項
レンダー項目に割り当てられたシェーダ インスタンスは、統合に影響する場合があります。異なるシェーダ インスタンスは、関連するレンダー項目の間で統合が起こらないことを意味します。
シェーダ インスタンスを使用する場合、プラグインでは、独自の設定の数を最小限に保つ必要があります。たとえば、2 つのカラー シェーダが必要な場合、プラグインでは、同じシェーダの定義を使用し、異なるパラメータ値(カラー)を使用する 2 つのシェーダ インスタンスを保持できます。逆に、プラグインでは、同じシェーダ パラメータを持つ 2 つのシェーダを保持してはいけません。