DG ノードまたは DAG オブジェクトのアタッチメント モデルは、登録インタフェース MDrawRegistry によってサポートされています。レンダリング ループ オーバーライドのアタッチメント モデルは、「3.6 レンダリング ループ オーバーライド」のセクションで詳細に説明されています。
描画、シェーダ、シェーディング ノード、ジオメトリ、およびサブシーン オーバーライドでは、ノード分類文字列の使用によって関連付けが黙示的に提供されます。オーバーライド分類と Maya ノード/オブジェクト分類の一致により、この黙示的なリンクが形成されます。一致は、「サブ分類」の使用により、広範なものから特定のものへ階層的に実行されます。
“drawdb/<object classification>/[<sub-classification>]/<override classification>”
<sub-classification>: 分類の便利な追加レベルを提供します。オーバーライドのグループ化と管理に必要な場合があります。特に、サーフェス シェーダとして使用されるシェーディング ノード(Maya シェーディング エンジンに接続)は、「drawdb/shader/surface/」で始まる分類を使用する必要があります。DAG オーバーライドでは、sub-classification がオプションです。
一般的に、sub-classification が多く指定されると、特定のエントリ ポイントに関連付けられたオブジェクト/ノードのタイプがより詳細になります。2 つの例を次に示します。
最初の分類文字列が使用された場合、より一般的な 2 番目の文字列の場合よりも少ないオブジェクト/ノードが一致します。
既存または新しいプラグイン ノード タイプの場合、プラグインの作成者は、オーバーライドおよびノード自体に対して適切な分類を使用し、正しい分類文字列一致(関連付け)が実行されるようにする必要があります。
ライトの分類
分類が “light” の場合は、内部の Maya ライトに使用できるサブ分類のみを使用できます。これには “ambientLight”、“pointLight”、“directionalLight”、“spotlight”、および “volumeLight” が含まれます。
ライトのサブ分類は、イルミネーションの計算中に使用される内部ライティング フラグメントを示します。ノード上に適切なアトリビュートが見つかると、これらのフラグメントのパラメータが更新されます。これらのアトリビュートは、1 対 1 の完全一致の場合もあれば、あいまい一致の場合もあります。
たとえば、分類 “drawdb/geometry/mynode” のノードに次のアトリビュートがあるとします。
また、ライト フラグメントに次のアトリビュートがあるとします。
intensity アトリビュートは相互にマップされますが、「use dmap shadows」アトリビュートおよび「use rtrace shadows」アトリビュートはいずれも同じ「shadows enabled」パラメータにマップされます。
一致する可能性がある場合は、マップされていない(接続されていない)値が使用されます。アトリビュートの一致が見つからない場合は、アトリビュートに適した既定値が使用されます。
light 分類を使用する場合、ライトを Maya のライトと同様に動作させるには、intensity、color、emitDiffuse、および emitSpecular のライト アトリビュートを含める必要があります。アトリビュートは静的または動的に設定できます。
"light" 分類を使用する場合は、内部の Maya ライトに使用できるサブ分類のみを使用できます。
exposure アトリビュートも内部ライト評価のために解析されます。
開発キットのサンプルに含まれている apiDirectionalLightShape と Arnold for Maya プラグインのライトには、exposure を含むさまざまな分類とアトリビュート処理をサポートする表示機能が実装されています。
指定したライト タイプの内部描画が自動的に実行されるため、描画オーバーライドは不要です。
図 35: 各オーバーライド タイプについて、分類は、分類で指定されたオブジェクトまたはノードを一致させます。
図 36: 分類の詳細度に応じて、異なる一致の結果を示す例です。“drawdb/geometry/parametricSurface/B-spline” DAG オブジェクト分類は、より一般的な “drawdb/geometry/parametricSurface” 文字列ではなく、まったく同じ分類文字列を使用してオーバーライドにより厳密に一致させます。最も近い一致の分類が使用されます。
getClassification コマンド マニュアルには、ビューポート 2.0 によって認識される分類の一覧が含まれています。
ビューポート 2.0 でライティングを実行するカスタム オブジェクトを描画する
ライティングに影響を及ぼす、カスタム描画を含む DAG オブジェクトには、2 つの “drawdb” 分類を指定できます。1 つは “light” で始まる分類、もう 1 つは “geometry” で始まる分類です。この分類は、ノードおよび対応するジオメトリ オーバーライドの “drawdb/geometry/light/myLight” 分類、および “light” や “drawdb/light/directionalLight” 分類と一緒に表示されます。
シンプルな例を apiDirectionalLightShape サンプル プラグインに示します。このプラグインは、次のカスタム ジオメトリ(青色)をディレクショナル ライトの既定の内部描画と比較して描画します。
“drawdb/light” と一緒に登録できるのは、描画およびジオメトリ オーバーライドの分類のみです。たとえば、“drawdb/subscene” などのオーバーライドは登録できません。
プラグイン ノードのオーバーライドでライトの描画を表すには、オーバーライドの登録時に分類文字列 “drawdb/geometry/light” を使用する必要があります。たとえば、“drawdb/geometry/light/myLight” などの分類文字列を使用できます。この分類を使用すると、表示タイプ フィルタのサポートが使用可能になるので、このようなプラグイン ノードの描画は、ライトがフィルタされるときにフィルタされます。
トランスフォーム ノード プラグインを登録する
プラグインの作成者は、ビューポート 2.0 でプラグインの変換が認識されるようにするには、変換を登録する際に適切な分類文字列 drawdb/geometry/transform を追加する必要があることにご注意ください。この処理は次の操作のために必要となります。
たとえば、rockingTransform プラグインの場合、コードは次のようになります。
// Classify the node as a transform. This causes Viewport // 2.0 to treat the node the same way it treats a regular // transform node. const MString classification = "drawdb/geometry/transform"; status = plugin.registerTransform("rockingTransform", rockingTransformNode::id, &rockingTransformNode::creator, &rockingTransformNode::initialize, &rockingTransformMatrix::creator, rockingTransformMatrix::id, &classification);
これが実行されないと、他の drawdb 分類が指定されていない場合に、registerTransform() によって自動的に drawdb/geometry/transform 分類が追加されます。
登録インタフェースを介して、新しい表示フィルタ タイプをプラグイン オブジェクトに追加できます。使用した分類文字列が描画オーバーライドの登録に使用した分類文字列に一致する場合は、可視性チェックが実行されるときにオーバーライドがフィルタ アウトされる可能性があります。フィルタの UI 名は、3D ビューポートとバッチ レンダリングの表示フィルタ インタフェースのオプションとして表示されます。
MFnPlugin::registerDisplayFilter() は、新しい表示フィルタ タイプを登録するインタフェースです。gpuCache SDK プラグインには、その使用法を例示するコードが含まれます。