オブジェクトのオーバーライド用にカスタムのレンダリング可能項目を処理する

ビューポート 1.0 のみのインタフェース

ビューポート 2.0 API では、レンダリング/描画インタフェースのみが提供されます。

既に存在するビューポート 1.0 インタフェースが、選択とコンポーネントの処理に使用されます。これは、MPxSurfaceShapeUI::select() および MPxSurfaceShapeUI::snap() などのメソッドを含んでいます。

UV エディタへの描画は変更されません。既存のビューポート 1.0 の方法を使用する必要がありますが、ビューポート 2.0 には UV エディタでの描画を行う特定のインタフェースがないため、MPxSurfaceShapeUI::drawUV()/MPxSurfaceShapeUI::canDrawUV() を使用します。

関連するマテリアルをオーバーライドするビューポート 1.0 の方法には、ビューポート 2.0 のレンダリングには必要ありません。 これには、MPxSurfaceShapeUI::material() および MPxSurfaceShapeUI::materials() が含まれます。

レンダリング可能項目(レンダー アイテム)

レンダリング可能項目は主要な要素です。

ビューポート 1.0 では、レンダリング可能項目は描画要求(MDrawRequest)として表されます。ビューポート 2.0 では、これに最も近いコンストラクトはレンダー アイテム(MRenderItem)です。これらの集合が、オブジェクトのレンダリング可能項目の合計セットを表すものと考えられます。

ビューポート 1.0 では、定義済みの MDrawRequest はありません。

ビューポート 2.0 では、オブジェクトに対して割り当てられたマテリアルを使用する描画を表す MRenderItem が提供されます。これらのマテリアルをレンダー アイテムと呼びます。 レンダラによって事前定義されていない項目は、「カスタム」と見なされます。

ビューポート 1.0 の手法では、描画要求を作成して適切なコレクションに返し、描画時に要求を明示的に描画します。ビューポート 2.0 の手法では、既存のレンダー アイテムを作成、更新、または選択的にオーバーライドして、ジオメトリ更新と最終的な内部描画に適したコレクションに返します。

レンダー アイテムには永続的な性質があるため、使用する予定のレンダー アイテム全体を事前に作成しておくことを検討する必要があります。

提供されるレンダー アイテム

ビューポート 2.0 レンダラは、マテリアルおよびバウンディング ボックスのレンダー アイテムを保持します。

• マテリアルのレンダー アイテムの場合は、ジオメトリ要件を満たすことのみが必要です。
• バウンディング ボックスのレンダー アイテムの場合、追加のコードは必要ありません。

マテリアル レンダー アイテムに使用されるシェーダをオーバーライドすることは可能ですが、必須ではありません。これらのレンダー アイテムを無効にして、カスタム レンダー アイテムに置き換えることもできます。

シェーダの割り当てがまったくないオブジェクトの処理は、プラグインに委ねられることに注意してください。ビューポート 1.0 では、マテリアル インタフェースが既定のマテリアルを返します。ビューポート 2.0 では、プラグインでないオブジェクトのフォールバックとしてワイヤフレームが表示されます。既定値のワイヤフレーム レンダー アイテムを提供できないため、これ(または、フォールバックとして適切なもの)をプラグインによって明示的に提供する必要があります。

カスタム レンダー アイテム

マテリアルとバウンディング ボックスのレンダー アイテムのみが提供される場合、追加の「カスタム」レンダー アイテムがいつ必要になるのかについての疑問が発生します。 これは、書かれているプラグインの種類に大きく依存しますが、1 つの共通する状況は非マテリアル レンダー アイテムのレンダリング、もう1つは既存のマテリアルまたはバウンディング ボックスの描画の上書きです。

変更の処理

選択状態の変更は、一般にレンダー アイテムのカラーの変更を意味します。 これには 2 つのアプローチが考えられます。つまり、各選択状態のために複数のレンダー アイテムを作成するか、あるいは十分なシェーダ パラメータを備えた単一のレンダー アイテムを使用することができます。 ジオメトリが一般に共有される場合、複数のアイテムを持つことによる自明のコストは小さくなります。 描画モードが異なる場合は、異なるレンダー アイテムが必要です。 たとえば、休止状態とアクティブのワイヤフレームでは異なるアイテムが使用されます。前者はワイヤフレーム モードでのみ描画されますが、後者はすべての描画モードで描画されます。

カラーの実際のコントロールは、一般に MGeometryUtilities::wireframeColor() などのユーティリティによって扱うことができ、現在のオブジェクトの状態を考慮して、正確なカラーが返されます。

オブジェクトの可視性については、マテリアル レンダー アイテムは UI レンダー アイテムと同様に自動的に扱われます。 ただし、テンプレートの状態変更は特定のレンダー アイテムに関しては可視性の変更と考えることができます。 たとえば、コンポーネントのレンダー アイテムは Maya の内部の振る舞いと一致するように手動で無効にする必要があります。 MGeometryUtilities::displayStatus() は状態の確認に役立つユーティリティです。

描画オーバーライド(アトリビュート エディタ(Attribute Editor) 描画オーバーライド(Draw Overrides)タブに公開)の場合は、カスタム カラー オーバーライドとともにテンプレート コントロールを扱う必要があります。 上記と同じユーティリティを使用できます。

ディスプレイ レイヤは、テンプレート化およびカラー オーバーライドのために更新を呼び出すことができます。

Maya によってコントロールされない追加の項目には、それぞれ内部プラグイン ロジックと対応する更新ロジックがあります。 たとえば、フェース センターの表示を追加することを、カスタム レンダー アイテムの表示を駆動してこれらのセンターを表示するノード上のアトリビュートにすることができます。

ジオメトリの処理

カスタムのレンダー アイテムには名前が付いているため、管理する名前付きレンダー アイテムのセットがあります。 また、セマンティックは同じで名前が異なるジオメトリ ストリームの要件が存在する可能性もあります。

たとえば、マテリアルのレンダー アイテムの描画と、面法線を描画するレンダー アイテムが必要となる場合には、位置の 2 つのストリーム(セマンティック)が必要となる場合があります。 前者を「My shaded item」、後者を「My face center item」のように命名することができます。 後者は、「フェース センター」のカスタムのストリーム名を使用して MRenderItem::setShader() を呼び出すことができました。

さらに、ストリームとレンダー アイテムの間には明示的な関連性が存在しないため、特定のカスタムのレンダー アイテムで使用する必要がある場合には、ストリームに名前をつけると役に立つ場合があります。 ただし、ストリームごとに名前を付けることによって、追加のジオメトリ データが発生し、インデックスの割り当ても必要になるため、一概にメリットがあるとはいえません。 また、ジオメトリの更新では、ストリームの名前付けはレンダー アイテム単位で行われるという事実を考慮する必要があります。 すなわち、名前は １ つのアイテムのすべてのストリームに適用されます。 使用例を「4.4.5.5 基本コンポーネントの処理」に示します。

図 80

上の図は、左側の 3 つのレンダー アイテムを示します。 一番上のアイテムはフェース センターの描画に使用されます。 これは位置のみを必要とし、「フェース センター」のカスタム名を持っています。 次はアクティブな頂点を描画するためのアイテムで、位置を必要とし、「アクティブな頂点」のカスタム ストリーム名を持っています。 最後はマテリアル レンダー アイテムで位置と法線を必要とします。 カスタム名はありません。 オーバーライドがジオメトリを供給しなければならない要件が累積した最終的な一式が戻ってきたときに、必要なデータのストリーム 4 つ(位置ストリームが 3 つで法線ストリームが 1 つ)に関する説明(MVertexBufferDescriptor)があります。位置ストリームは、マテリアルとアクティブな頂点の表示に共通のものを使用することができます。

データがいつ必要になるかについての想定はされないため、すべての要件が常に満たされるようにする必要があります。 適切なデータが提供されない場合、レンダラは、既定のデータを提供しようとする場合があります。しかし適切なデータを提供できるという保証はありません。 たとえば、ビューポートの構成において、1 つのパネルがシェーディング モードでもう 1 つのパネルがワイヤオン シェーディング モードを有効にしている場合、1 つのビューポート パネルは、シェーディング レンダー アイテムに加えてワイヤフレーム レンダー アイテムを必要とします。 シェーディングされたレンダー アイテムでは、接線が必要になる場合があります。

カスタムの UI 描画の例

たとえば、プラグインは以下に対するカスタムのレンダー アイテムを作成することができます。

• 休止状態のワイヤフレームの描画
• アクティブなワイヤフレームの描画
• 休止状態の頂点の描画
• アクティブな頂点の描画
• シェーディングされたテンプレート ワイヤフレームの描画
• シェーダが DAG オブジェクトに割り当てられていない場合のプロキシ描画

図 81

緑色のボックスは、プラグインが作成し管理する領域を表します。 白いボックスはレンダラによって提供されます。

以下に、上記のアイテムのパラメータの例と、それぞれのアイテムに適した更新の頻度を示します。

• 深度の優先順位: アイテムの固有性はこのパラメータによって決まります。そのため、これは作成時に設定されます。
• 描画モード: アイテムの固有性はこのパラメータによって決まります。そのため、これは作成時に設定されます。ワイヤフレーム アイテムのアクティブと休止状態がワイヤフレーム モードでの表示のためだけに設定されるのと同様に、シェーディングされたテンプレート ワイヤフレーム アイテムは、シェーディング モードのときにテンプレート ワイヤフレームの描画を処理するために特別に作成されています。
• カラー: これはレンダー アイテムの更新時にダイナミックに設定することができるシェーダ パラメータです。たとえば、カラーは現在のオブジェクトの表示状態に応じて更新されます。

• ポイント サイズ: カラーの場合と同じ理由で、レンダー アイテムの更新時にダイナミックに設定することができます。

三日月の形の「コンテナ」は、ジオメトリとサブシーンのオーバーライド レンダー アイテムの両方が、どれくらい論理的にレンダー アイテムのセットに収集されるかを示します。 主な違いは、サブシーンのオーバーライド コンテナ クラスは明示的に API に公開されるということです。

以下に、ユーザ ワークフローの例、およびプラグインがどのようにそれらのレンダー アイテムを処理することができたかを示します。

1. ユーザは、シェーディング モード中に、コンポーネント選択モードに入ります。
   1. オブジェクトはハイライト モードにあるので、休止中のワイヤフレーム アイテムを有効にして、カラーを適切に設定する必要があります。
   2. 休止中の頂点レンダー アイテムを有効にして、カラーを適切に設定する必要があります。
   3. アクティブなワイヤフレーム アイテムを無効にする必要があります。
   4. アクティブな頂点アイテムを無効にする必要があります。
   5. シェーディングされたテンプレート アイテムを無効にする必要があります。
   6. シェーディングされたプロキシ アイテムを無効にする必要があります。
      注: マテリアルにシェーディングされたアイテムは内部的に有効になり、シェーディング モードになったときに有効化されました。
2. 次にユーザはいくつかの頂点を選択します。
   1. アクティブな頂点アイテムを有効にする必要があります。 アクティブなコンポーネントを解析し、頂点のサブセットを表示するために適切なインデックス処理を設定する必要があります。
3. ユーザはオブジェクト選択モードに戻ります。
   1. 休止中の頂点アイテムとアクティブな頂点アイテムは無効になります。
   2. アクティブなワイヤフレーム アイテムは有効になります。
   3. 休止中のワイヤフレーム アイテムは無効になります。
4. ユーザはワイヤフレーム モードに切り替わります。
   1. シェーディング モードで描画するようにマーキングされたレンダー アイテムは描画パイプライン内でフィルタされるため、プラグインでは何もする必要はありません。
5. ユーザはオブジェクト オーバーライドを設定してオブジェクト テンプレートを作成します。
   1. カスタム マテリアルのレンダー アイテムがある場合は、無効にする必要があります。提供されているマテリアル レンダー アイテムは自動的に無効になります。
   2. 休止中のワイヤフレーム アイテムとアクティブなワイヤフレーム アイテムを無効にする必要があります。
   3. 休止中の頂点アイテムを無効にする必要があります。
   4. シェーディングされたテンプレート アイテムを有効にして、オブジェクトがアクティブかどうかに応じて、適切なカラーに設定する必要があります。

図 82

上記の 5 つのアクションを上から下に、そして左から右に図で表しています。 どんな場合でも、すべてレンダー項目の保持は、基本的な有効と無効の発生、およびカラーなどの起こりうるパラメータの変化によって行われます。 有効なアイテムは緑色で表示され、それ以外のすべてのレンダー アイテムは無効になります。

カスタム マテリアル

カスタム マテリアルのレンダリングが必要な場合、統合のレベルは使用されるインタフェースに依存します。 以下の表は、それぞれのインタフェースに関する主なトレードオフをまとめたものです。 柔軟性を高めるには、プラグイン作成者はより多くの作業を行う必要があります。 ある程度は、より単純なシェーダをジオメトリ ハンドラ/オーバーライド内部で維持することができます。

フラグメント(Fragment)、エフェクト(Effects) およびストック(Stock) は、シェーダ マネージャを介して利用可能なオプションです。そのため、サポートされるオプションは内部レンダラによって決定されます。シェーダのオーバーライド(Shader Override) は MPxShaderOverride です。

マテリアル アイテムを扱う場合、一般に、「シェーディング」または、「シェーディングとテクスチャ」描画モードがオーバーライドにパスされるレンダー アイテムがあります。 DAG オブジェクトに割り当てられたマテリアルの数に応じて、このようなパスされるアイテムのセットの数は 0 またはそれ以上になります。

図 83

この例では、DAG オブジェクトは DAG オブジェクト上の異なるコンポーネントに 2 つのシェーダを割り当てます。 4 つの「マテリアル」レンダー アイテムを持つことができます。1 つは「シェーディング」描画モードで描画される各コンポーネント シェーダ、1 つは「シェーディングとテクスチャ」モードで描画される各コンポーネント シェーダに対するものです。

これらのレンダー アイテムのパラメータはそのまま使用することも、修正したり、無効にすることもできます。 無効にした場合、プラグインは代わりのパラメータを提供しなければなりません。 代わりのパラメータが提供されない場合、オブジェクトはシェーディングまたはテクスチャ モードのときに「消えた」ように見えます。 代わりのパラメータのタイプに応じて、統合のレベルは異なったものになります。

あるレンダー アイテムのシェーダ処理の複雑さが MPxShaderOverride が必要となるレベルに達すると、ジオメトリ ハンドラの複雑さが低減され、これらのレンダー アイテムのジオメトリ要件のみを満たすようになります。

たとえば、プラグインは完全に統合されたいくつかのプリセット シェーディング構成を持つビルトインの Blinn シェーダのみを必要とする場合があります。 この場合はストック フラグメント シェーダを使用することができます。 別の例では、ヘア シェーダのためのテッセレーションが必要になる場合があります。 この場合の最善の対応は、ジオメトリ ハンドラの内部からこれを制御せず、代りにカスタムの MPxShaderOverride の「ヘア シェーダ ノード」を作成し、レンダー アイテムをカスタムの「ヘア ジオメトリ ノード」オーバーライドに「フィードする」ことです。

図 84

各種の利用可能なオプションがすべて一度に表示されます。

レンダラが提供する(マテリアル)レンダー アイテムは、カラーなしで表示されます。 内部シェーダとプラグイン シェーダの組み合わせによってこれらのアイテムを派生させる場合もあります。 ノードには、カスタムのフラグメント シェーダを提供するもの、あるいはシェーダ オーバーライドが関連付けられるものがあります。 ジオメトリ ハンドラ(オーバーライド)は、これらを非カスタムのレンダー アイテムとして受け取ります。

カスタムのレンダー アイテム(緑色で表示)は、フラグメント、ストックあるいはエフェクト ファイル インタフェースを使用して、シェーダ マネージャを介して作成されるシェーダ インスタンスを用いてインスタンス化することができます。

UI 描画マネージャ

MUIDrawManager クラスは、一般にはオブジェクトの一部としての関連性をもたない追加の UI 描画をキューに入れるための簡易インタフェースを提供します。 キューに入れることのできる「描画可能項目」は、レンダー アイテムとほぼ同じであると考えることができます。

マネージャを使用することの直接的な意味は、「描画可能項目」は永続的ではないので、このインタフェースを介してキューに入れられる描画可能項目の数は比較的少なくすることができるということです より多くのアイテムが必要な場合、またはデータ コンテンツが大きい場合、mesh() 呼び出しなどのインタフェースを使用することができます。 そうでなければ、カスタムのレンダー アイテムが推奨されます。

たとえば、プラグイン オブジェクト上に大量の頂点を描画する場合は、描画マネージャ内で個々の点を描画するよりも、カスタムのレンダー アイテムを使用することが推奨されます。 ただし、オブジェクト上で 3D または 2D のラベルを描画する場合は、描画マネージャが推奨されます。

検討が必要なもう 1 つの側面は、マネージャを使用して描画された UI は、パイプライン全体の中の固定された場所に描画され、より厳密な定義済み描画プロパティのセットを持つ場合があるということです。

エフェクトおよびコンテキストのインタラクション

既定では、UI 描画(ライン、ポイント)に使用されるレンダー アイテムは、スクリーンスペース アンビエント オクルージョン、モーション ブラーおよび被写界深度のようなシーン エフェクトから除外されます。 また一般に、それらはシャドウの投影や受像を行いません。 内部マテリアル シェーダ インスタンスを使用するレンダー アイテムは、これらのエフェクトの要素となります。

エフェクトの描画は、いくつかの描画コンテキスト内で実行されます。

ジオメトリ オーバーライドにはコンテキスト情報は渡されず、その動作はほとんどの場合コンテキストに依存しません(シェーダ コールバックは例外)。 サブシーンのオーバーライドにはコンテキストが提供されますが、これはフレーム コンテキストであり、パス コンテキストへのアクセスを提供しません。 したがって、どのアイテムも、呼び出し元のパスに関係なく動作します。

ビューポート 1.0/ビューポート 2.0 の比較チャート

サンプル コード

apiMeshShape Developer Kit サンプルは、UI の処理およびプロキシ シェーダの処理に関連する多くのワークフローを考慮に入れます。

図 85

ワイヤフレーム モードにおける apiMeshShape のシーンのサンプル。

図 86

シェーディング モードにおける apiMeshShape のシーンのサンプル。

上のスナップショットは、使用されている多くの異なるカスタムのレンダー アイテムを示します。 プレーンと IK チェーンを除くすべてのオブジェクトは、同じプラグインを使用して描画されます。 以下が含まれます。

• 休止中のワイヤ アイテム:
  • 既定である休止状態のカラーを使用する青のワイヤフレーム
  • ディスプレイ レイヤ カラーを使用する赤と緑のワイヤフレーム
  • 「描画オーバーライド」カラーを使用する黒のワイヤフレーム
  • ワイヤフレーム モードでのテンプレート オブジェクトの灰色のワイヤフレーム
  • アクティブが作用したオブジェクト(IK チェーンの影響を受ける)のピンクのワイヤフレーム
• アクティブなワイヤ アイテム:
  • リード オブジェクトの白のワイヤフレーム。
• シェーディングされたテンプレート アイテム:
  • シェーディング モードでの灰色のワイヤフレーム
• 提供されるマテリアル:
  • 赤、緑、青、ピンクの Blinn および灰色の Lambert シェーディング アイテム
• プロキシのシェーディング アイテム:
  • 「虹」色の頂点ごとのカラーを持つ破線ワイヤフレーム アイテム

// Utility to set the color on a shader instance.
void setSolidColor(MHWRender::MShaderInstance* shaderInstance, const float *value)
{
  if (!shaderInstance)
	return;
  const MString colorParameterName = "solidColor";
  shaderInstance->setParameter(colorParameterName, value);
}

// ************************** Update during updateRenderItems() ******************
…
// Unique name for active wireframe
MString fSelectedWireframeItemName = “selectedWireframeName”;
// Create the item once. Use enable/disable toggle to control when it should
// be drawn (below)
MHWRender::MRenderItem* selectItem = NULL;
int index = list.indexOf( // list = MRenderItemList passed as an input argument
	fSelectedWireframeItemName,
	MHWRender::MGeometry::kLines, // Type of primitive is lines 
	MHWRender::MGeometry::kAll); // Draw in all display modes
if (index < 0)
{
	static const bool raiseAboveShaded = true;
	selectItem = MHWRender::MRenderItem::Create(
		fSelectedWireframeItemName,
		MHWRender::MGeometry::kLines,
		MHWRender::MGeometry::kAll,
		raiseAboveShaded);
	// This is the same as setting the argument raiseAboveShaded = true,
	// since it sets the priority value to be the same. This line is just
	// an example of another way to do the same thing after creation of
	// the render item.
	selectItem->depthPriority( MHWRender::MRenderItem::sActiveWireDepthPriority);
	list.append(selectItem);

	// Choose an line shader to match primitive type
	MHWRender::MShaderInstance* shader = 
		shaderMgr->getStockShader( MHWRender::MShaderManager::k3dSolidShader );
	if (shader)
	{

		// Assign shader
		selectItem->setShader(shader);
		// Once assigned, no need to hold on to shader instance
		shaderMgr->releaseShader(shader);
	}
}
else
{
	selectItem = list.itemAt(index);
}

// Perform updates on the render item parameters. In this case
// update the shader instance.
//
MHWRender::MShaderInstance* shader = NULL;
if (selectItem)
{
	shader = selectItem->getShader();
}

// Check the current display status of the object and color to use for this
// instance of the object.
MHWRender::DisplayStatus displayStatus = 
	MHWRender::MGeometryUtilities::displayStatus(path);
MColor wireColor = MHWRender::MGeometryUtilities::wireframeColor(path);

// It is not necessary to use the colors provided and instead a custom color could be 
// used if (fUseCustomColors) is set.
bool fUseCustomColors = false;
switch (displayStatus) {
case MHWRender::kLead:
	selectItem->enable(true);
	if (shader)
	{
		static const float theColor[] = { 0.0f, 0.8f, 0.0f, 1.0f };
		setSolidColor( shader, !fUseCustomColors ? &(wireColor.r) : theColor );
	}
	break;
case MHWRender::kActive:
	if (shader)
	{
		static const float theColor[] = { 1.0f, 1.0f, 1.0f, 1.0f };
		setSolidColor( shader, !fUseCustomColors ? &(wireColor.r) : theColor );
	}
	selectItem->enable(true); // Enable if the object is active
	break;
case MHWRender::kHilite:
case MHWRender::kActiveComponent:
	if (shader)
	{
		static const float theColor[] = { 0.0f, 0.5f, 0.7f, 1.0f };
		setSolidColor( shader, !fUseCustomColors ? &(wireColor.r) : theColor );
	}
	selectItem->enable(true); // Enable if the object is hilite, or 
                                  // its components are active.

	break;
default:
	// Otherwise make sure to disable it. The item is still present, it will just
	// not be sent down the rendering pipeline to draw.
	selectItem->enable(false);
	break;
};

/***** Call in MPxGeometryOverride::updatedDG() to perform any DG operations ****/
void updateDG()
{
	fActiveVertices.clear(); // fActiveVertices is an MIntArray 
	
	MObjectArray clist = // Get the active vertex components – plug-in specific ;
	if (clist.length())
	{
		MFnSingleIndexedComponent fnComponent( clist[0] );
		if (fnComponent.elementCount())
		{
			// Cache the vertex identifiers for later usage.
			fnComponent.getElements( fActiveVertices );
		}
	}
}

/* Test to see if active components should be enabled.
           Based on active vertices + non-template state
*/
bool enableActiveComponentDisplay(const MDagPath &path) const
{
	bool enable = true;

	// If no active components then disable the active
	// component render item
	if (fActiveVertices.length() == 0)
	{
		enable = false;
	}
	else
	{
		// If there are components then we need to check
		// either the display status of the object, or
		// in the case of a templated object make sure 
		// to hide components to be consistent with how
		// internal objects behave
		//
		MHWRender::DisplayStatus displayStatus = 
			MHWRender::MGeometryUtilities::displayStatus(path);
		if (displayStatus == MHWRender::kTemplate ||
			displayStatus == MHWRender::kActiveTemplate)
		{
			enable = false;
		}
		else
		{
			// Do an explicit path test for templated
			// since display status does not indicate this.
			if (path.isTemplated())
				enable = false;
		}
	}
	return enable;
}

…
// Unique name identifier for the render item
MString fActiveVertexItemName = “activeVertexItemName”;
MHWRender::MRenderItem* activeItem = NULL;
int index = list.indexOf(
	fActiveVertexItemName,
	MHWRender::MGeometry::kPoints,// Primitive type is points.
	MHWRender::MGeometry::kAll); // Render item should display in all display modes.
if (index < 0)
{
	activeItem = MHWRender::MRenderItem::Create(
		fActiveVertexItemName,
		MHWRender::MGeometry::kPoints,
		MHWRender::MGeometry::kAll,
		false);
	// Set depth priority to be active point. This should offset it 
	// to be visible above items with "dormant point" priority.
	activeItem->depthPriority( MHWRender::MRenderItem::sActivePointDepthPriority );
	list.append(activeItem);

	MHWRender::MShaderInstance* shader = shaderMgr->getStockShader(
		MHWRender::MShaderManager::k3dFatPointShader );
	if (shader)
	{
		// Set the point size parameter. Make it slightly larger for active
		// vertices
		static const float pointSize = 5.0f;
		setSolidPointSize( shader, pointSize );

		// Assign shader. Use a named stream if we want to supply a different
		// set of "shared" vertices for drawing active vertices
		bool fDrawSharedActiveVertices = true;
		MString fActiveVertexStreamName = “activeVertexStreamName”;
		if (fDrawSharedActiveVertices)
		{
			activeItem->setShader(shader, &fActiveVertexStreamName );
		}
		else
		{
			activeItem->setShader(shader, NULL);
		}

		// once assigned, no need to hold on to shader instance
		shaderMgr->releaseShader(shader);
	}
}
else
{
	activeItem = list.itemAt(index);
}

// Update the color and enable / disable the render item as appropriate.
// Just using a fixed color and not checking display status.
bool enableActiveDisplay = enableActiveComponentDisplay( <dagpath> );
if (activeItem)
{
	MHWRender::MShaderInstance* shader = activeItem->getShader();
	if (shader)
	{
		// Set active color
		static const float theColor[] = { 1.0f, 1.0f, 0.0f, 1.0f };
			setSolidColor( shader, theColor); // See code for active 
					// wireframe for this code utility.
	}

	activeItem->enable( enableActiveDisplay );
}

const MHWRender::MVertexBufferDescriptorList& descList =
		requirements.vertexRequirements();
int numVertexReqs = descList.length();
MHWRender::MVertexBufferDescriptor desc;
for (int reqNum=0; reqNum<numVertexReqs; reqNum++)
{
	if (!descList.getDescriptor(reqNum, desc))
	{
		continue;
	}

	// Fill in vertex data for drawing active vertex components 
	//
	if (fDrawSharedActiveVertices && (desc.name() == fActiveVertexStreamName))
	switch (desc.semantic())
	{
		case MHWRender::MGeometry::kPosition:
		{
			if (!activeVertexPositionBuffer)
			{
				activeVertexPositionBuffer = data.createVertexBuffer(desc);
				if (activeVertexPositionBuffer)
				{
				   // Allocate a position buffer to fit the # of active vertices
				   unsigned int activeVertexCount = fActiveVertices.length()
				   activeVertexPositions =
				      (float*)activeVertexPositionBuffer>acquire(
				              activeVertexCount, 
				              true 
				              /*writeOnly*/				
				}
			}
		}
		break;

		default:
			break;
	}
}