エフェクト オーバーライド

MShaderInstance の使用

オーバーライドでシェーダ インスタンスを使用している場合、オーバーライドごとに 1 つのシェーダ インスタンスを保持するのではなく、固有のグローバル セットを使用する必要があります。詳細については、「シェーダ インスタンス」の「統合に関する考慮事項」を参照してください。

統合

統合が必要でない場合、次をオーバーライドすることによってこれを示すことができます。

MPxShaderOverride::handlesConsolidatedGeometry() 仮想メソッド

これを設定しない場合、項目を統合できるかどうかの判断に、シェーダ オプションが使用されます。

dx11Shader、glslShader、および hwPhongShader Developer Kit プラグインを参照してください。また、最初の 2 つの例では、セマンティックとして公開されています。「ビューポート 2.0 の dx11Shader および glslShader プラグインでサポートされるセマンティックと注釈」を参照してください。

シェーダ キーの独自性以外に、カスタム データの使用も、MRenderItem の独自性を決めるため、レンダー項目の統合に影響します。つまり、異なるデータ ポインタを持つレンダー項目は、項目の統合が起こらないことを意味します。統合のサポートが必要な場合、これを考慮する必要があります。

統合情報を抽出する

シェーダでは、描画時に Maya オブジェクトごとの情報抽出が必要になることがあります。

これを実現する方法の 1 つは、シェーダを使用するレンダー項目が統合されないように強制することです。その結果、シェーダ セットアップと描画の呼び出しが、オブジェクト単位でセットになります。この動作は、シェーダ キー、カスタム データの使用、または MPxShaderOverride::handlesConsolidatedGeometry() オーバーライドによって、統合されないものとして項目にマークを付けることで実現できます。

統合時に分離を強制する代わりの方法は、レンダー項目が統合されることは許可して、描画時にパスおよびジオメトリの情報を抽出するというものです。

シャドウ マップ パスのように、オブジェクトごとの抽出を必要としないパスでは、統合されたジオメトリ全体を描画する既定の動作は維持できます。

抽出を必要としないパスでは、まず MRenderItem::isConsolidated() メソッドを使用して、統合されたジオメトリがレンダー項目に含まれているかどうかを確認する必要があります。含まれている場合、MRenderItem::sourceIndexMapping() を使用して、Maya DAG パスのリスト、および関連するインデックス範囲を取得できます。インデックス範囲は、描画時に使用できる、統合されたジオメトリ データ バッファ内で、パスごとのジオメトリがある場所を示します。

MRenderItem::sourceDagPath() メソッドでは 1 つのパスしか返すことができないので、統合されたジオメトリ パスの抽出には適していません。

hwPhongShader プラグインからの次のサンプル コードでは、基本的なロジックを示しています。

const MHWRender::MRenderItem* renderItem = renderItemList.itemAt(renderItemIdx);
const MHWRender::MGeometry* geometry = renderItem->geometry();

MHWRender::MGeometryIndexMapping geometryIndexMapping;
if (renderItem->isConsolidated())
{
    renderItem->sourceIndexMapping(geometryIndexMapping);

    // Extract information if the geometry was consolidated
    for (int i=0; i<geometryIndexMapping.geometryCount(); i++)
    {
        // Pull out the dag path, any component, and the start and end   
        // indexing into the geometry buffers.
        MDagPath path = geometryIndexMapping.dagPath(i);
        MObject comp = geometryIndexMapping.component(i);
        int indexStart = geometryIndexMapping.indexStart(i);
        int indexLength = geometryIndexMapping.indexLength(i);
    }
}
else
{
    // Have unconsolidated geometry. The indexing thus spans the entire
    // range of the buffers returned.
    MDagPath sourceDagPath = renderItem->sourceDagPath();
}

具体的な例として、pPlaneShape1 および pPlaneShape2 の 2 つのオブジェクトがあるシーンを考えます。これらには同じプラグイン シェーダ(hwPhong)が割り当てられています。次のイメージでは、各オブジェクトのトポロジ(頂点およびフェースの ID)が示されています。三角形分割は点線で示されています。

オブジェクトごとのジオメトリ データにアクセスするには、最初にインデックス情報を抽出する必要があります。インデックス情報は、描画時に返されるレンダー項目(MRenderItem)のジオメトリ(MGeometry)を調べることにより返されます。

MRenderItem renderItem; // Passed at draw time.

// Get the geometry 
const MHWRender::MGeometry* geometry = renderItem->geometry();

// Get the index type
MHWRender::MGeometry::Primitive indexPrimType = renderItem->primitive();
MString indexPrimTypeName = MHWRender::MGeometry::primitiveString(indexPrimType);
const MHWRender::MIndexBuffer* buffer = geometry->indexBuffer(0);

// Get the data type
MString dataType = MHWRender::MGeometry::dataTypeString(buffer->dataType()); 

// Get the size of the index buffer
int indexCount = geometry->indexBufferCount();  

// Dump the indexing for debugging purposes. Note that when geometry is consolidated, the
// index can be unsigned short.
MHWRender::MIndexBuffer* nonConstIB = const_cast<MHWRender::MIndexBuffer*>(buffer);
if (buffer->dataType() == MHWRender::MGeometry::kUnsignedInt32)
{
    const unsigned int *ptr = (const unsigned int*)nonConstIB->map();
    for (unsigned int i=0; i<indexBufferCount; i++)
    {
        const unsigned int index = ptr[i];
        fprintf(stderr, "-- index[%d] = %d\n", i, index);
    }
    nonConstIB->unmap();
}
else
{
    const unsigned short *ptr = (const unsigned short*)nonConstIB->map();
    for (unsigned int i=0; i<indexBufferCount; i++)
    {
        const unsigned short index = ptr[i];
        fprintf(stderr, "-- index[%d] = %d\n", i, index);
    }
    nonConstIB->unmap();
}	

2 つのオブジェクトの間で統合が可能な場合、返される情報は次のようになります。プレーン テキストおよび太字は、インデックスが元のオブジェクトとどのように関係しているかを示すために使用されています。太字は pPlaneShape1 を示すために使用されています。

Indexing Primitive Type = Triangles,

Index type = Unsigned Int 16,

Index count = 18

Index array:

index[0] = 0

index[1] = 1

index[2] = 3

index[3] = 3

index[4] = 1

index[5] = 2

index[6] = 4

index[7] = 5

index[8] = 7

index[9] = 7

index[10] = 5

index[11] = 6

index[12] = 8

index[13] = 9

index[14] = 11

index[15] = 11

index[16] = 9

index[17] = 10

ジオメトリについて提供される統合情報は次のとおりです。

• 最初のジオメトリでは、パス = |pPlane2|pPlaneShape2、開始インデックス = 0、インデックスの長さ = 12 となっています。このジオメトリには 2 つの四角形(または 4 つの三角形)があるため、こちらのインデックスの方が長くなっています。

• 2 番目のジオメトリでは、パス = |pPlane1|pPlaneShape1、開始インデックス = 12、インデックスの長さ = 6 となっています。このインデックスは、1 つの四角形(2 つの三角形)に対するものです。

次に示すのは、頂点およびフェースの識別子情報のダンプ結果です。

各データ バッファの最初の 8 つのエントリは pPlaneShape2 に関するものであり、各データ バッファの最後の 4 つのエントリは pPlaneShape1 に関するものです。

データ バッファの検索用に提供されたインデックスをたどることにより、次のような三角形ごとの頂点 ID が得られます。

[0,1,3], [3,1,4], [1,2,4], [4,2,5], [0,1,2], [2,1,3]

最初の 4 つの三角形は pPlaneShape2 のものであり、最後の 2 つの三角形は pPlaneShape1 のものです。

対応するフェース ID の検索からは、次のように結果が得られます。

[0,0,0],[0,0,0],[1,1,1],[1,1,1], [0,0,0], [0,0,0]

最初の 2 つの三角形(pPlaneShape2)はフェース 0 に属し、次の 2 つの三角形(pPlaneShape2)はフェース 1 に属し、最後の 2 つの三角形は pPlaneShape1 のフェース 0 に属しています。

旧式の既定ビューポート(ビューポート 1)とビューポート 2.0 の描画ロジック

ビューポート 1 では、ジオメトリの統合と同等のものがありませんが、各シェーダの描画のために一連のジオメトリを送り返そうとすることがあります。これは、常にシェーダをバインドおよびバインド解除することを避けるための最適化です。

MPxHwShaderNode インタフェースの呼び出しパターンは、次のようになります。

1. glBind() により、シェーダをバインド
2. glGeometry()
   1. パス A のストリームをバインド
   2. パス A のインデックスをバインド
   3. 描画(Draw)
3. glGeometry()
   1. パス B のストリームをバインド
   2. パス B のインデックスをバインド
   3. 描画(Draw)
4. さらに、オブジェクトのインスタンスごとに glGeometry() の呼び出し
5. glUnbind() により、シェーダをバインド解除

一方、ビューポート 2.0 の MPxShaderOverride インタフェースの呼び出しパターンは、次のようになります。

1. activateKey() により、シェーダ インスタンスをバインド
2. draw()
   1. 統合されたジオメトリのストリームをバインド
   2. インデックス範囲ごとの描画が必要な場合:
      1. インデックス範囲を設定
      2. 描画(Draw)
   3. それ以外の場合、カスタム描画ロジックを選択
3. terminateKey() により、シェーダをバインド解除

ビューポート 2.0 では、すべての情報について描画は 1 回だけなので、次のようになります。

• オブジェクトごとのバインドではなく、統合されたジオメトリのバインドが 1 回だけとなります。

• これにより、ビューポート 1 のロジックとは対照的に、プラグインでジオメトリの描画方法を最終的に決定する際の柔軟性が得られます。ビューポート 1 のロジックでは、予め設定された、インデックス バッファとデータ バッファ ストリームのセットを使用して、一定回数プラグインを呼び出します。

フレームごとの作業

すべてのシェーダに共通するフレームごとの作業を存在させることが可能です。この場合、いくつかのオプションが使用できます。

• MPxShaderOverride のコンテキスト内で、フレーム スタンプを取得するための呼び出しが使用できます(MDrawContext::getFrameStamp())。たとえば、シェーダを複数回呼び出すときの、コストがかかるライティングの再計算を避けるために、glslShader および dx11Shader プラグインでは、フレーム スタンプの変更時のみ計算を実行します。

• ビューポート 2.0 の通知コールバックは、グローバル レベルで使用できます。(MRenderer::addNotification(MHWRender::MPassContext::kBeginRenderSemantic))。

• ビューポートごとの MUiMessage コールバック(add3dViewPreRenderMsgCallback())は、引き続きビューポート 2.0 でグローバル レベルの使用が可能です。