ジオメトリック データ(MGeometry)

頂点バッファと GPU データ

頂点バッファは、MVertexBuffer クラスにより API で表されます。頂点バッファは、論理的には単なるバイナリ データのブロックです。

このデータの形式は、頂点バッファ記述子で表され、この記述子は API では MVertexBufferDescriptor クラスによって表されます。バッファ記述子は、次のプロパティを表します。

• 名前: データを一意に識別するユーザ名です。
• スケマティック: 頂点アトリビュートとしてのデータの解釈方法です。基本のセマンティックには、位置、法線、テクスチャ座標、カラー、接線、複接線、および巻上げ方向記号を含む接線が含まれます。
• データ型: 数値データ型です。
• 寸法: データの長さです。

一意の名前によって、同じセマンティックを使用する複数のデータ セットを使用できます。たとえば、名前が異なるテクスチャ座標を 2 セット使用することができます。

たとえば、トーラスの例では、それぞれ名前が異なる(たとえば、位置バッファの 1 つの名前を「P1」とする)頂点バッファのセットを使用できます。

図 20

前のシステムと異なり、レンダリング フレームワークでは、GPU 側(CPU側はありません)のデータのみリソース管理システムで維持されます。

頂点バッファ(および実際にはすべての GPU 側リソース)については、次のプロパティに該当します。

• データは、リソース管理システムで管理および所有されます。
• プラグインはアクティブな GPU デバイスまたはコンテキストを使用せずにデータにアクセスして更新することができなくなります。
• データは管理システムから取得する必要があります。データが GPU に存在する場合、修正を行うには CPU データにマッピングし直す必要があります。
• CPU の更新が完了したとき、またはこれが初めてのデータ作成である場合は、GPU にコミット(転送)する必要があります。
• 説明は GPU 側の説明にマッピングされます。リソースを最初に作成した後に説明を変更することはできません。
• GPU リソースごとに、描画 API 固有の GPU ハンドルへ直接アクセスすることができます。このハンドルを使用すると、内部管理システムの知識がなくてもリソースに対するすべての更新を実行できます。

インデックス バッファ

インデックス データは、MIndexBuffer クラスによって表されます。インデックス データは、論理的には単なるバイナリ データのブロックです。

インデックスの解釈と形式は、MIndexBufferDescriptor クラスによって提供されます。記述子には、一意に識別するための文字列名、プリミティブ タイプ、データ型など、基本のプロパティがあります。内部オブジェクト タイプから現在返される唯一のデータ型は、32 ビットの整数です。プリミティブ タイプには、ポイント、ライン、三角形などの基本のハードウェア タイプが含まれますが、カスタム インデックスによって作成可能な、より高度なプリミティブの列挙も含まれます。

記述子では、インデックスに対してセマンティックの意味を指定することもできます。このセマンティックの意味は、インデックス タイプと呼ばれます。一連の定義済みセマンティックを使用することができますが、インデックスを「カスタム」で生成されているものとしてマークすることもできます。

カスタム インデックスの詳細については、「高度なトピック」セクションを参照してください。

インデックスは、レンダリング可能なオブジェクトに対して特定のプリミティブ タイプのすべての要素を表す必要はありません。たとえば、フェース単位のシェーディングのメッシュ上のフェースのコンポーネント インデックスを表したり、NURBS サーフェス上の選択された CV ­を表すために使用できます。対応付けのため、Maya DAG オブジェクト コンポーネントをインデックス記述子に関連付ける場合があります。

頂点バッファと同様に、インデックスは GPU データとして格納され、リソース マネージャによって管理されます。

MGeometry 管理

MGeometry のすべての部分をまとめるために、以下の図 20 に、MGeometry、MIndexBuffer、MVertexBuffer、MRenderItem および内部リソース マネージャのインスタンスを示します。

図 21: MRenderItem は、MGeometry インスタンスを参照します。MGeometry インスタンスは 1 つまたは複数の MVertexBuffer インスタンス、およびゼロ以上の MIndexBuffer インスタンスを参照します。MRenderItem では、使用している特定の MVertexBuffers と MIndexBuffer に関する情報が保持されます。どの Maya DAG コンポーネントも、特定の MIndexBuffer に対応付けることができます。MVertexBuffer および MIndexBuffer のデータは、GPU データと直接対話する内部リソース マネージャによって管理されます。

この図には、接続ラインで表される一連の従属が示されています。矢印の方向は、従属の方向を示します。各従属は参照を表し、参照のコレクションは寿命管理の処理方法を示します。リソース マネージャは常に実際のジオメトリック データを参照します。MVertexBuffer および MIndexBuffer インスタンスは、対応する GPU データへの参照を保持します。MGeometry には、レンダリング可能なオブジェクトのすべての MVertexBuffer および MInd­exBuffer インスタンスへの参照が保持されます。MRenderItem は、使用している特定の MVertexBuffer および MIndexBuffer インスタンスを参照します。

このスキーマにおける重要な注意事項

1. Maya オブジェクトでは、ジオメトリック データへの直接参照は保持されません。
2. プラグインでは、プラグインで所有されていないジオメトリ クラスのインスタンスへの永続的な参照は維持されません。
3. これには、頂点バッファ記述子とインデックス バッファ記述子が含まれます。これらはリソースそのものとは見なされませんが、リソースを参照できるため、プラグインには保持されません。
4. GPU リソース ハンドルにアクセスするバックドアが存在していても、プラグインはこの方法でデータを試したり、削除しません。

ジオメトリ要件

前のセクションでは、静的ジオメトリ データの構造とそれらの関係について説明しました。更新フェーズ中に、これらの構造のインスタンスをインスタンス化し、塗り潰す必要があります。

この手順をジオメトリ要件の実現と呼びます。

API 内で実現する内容を指定する対応クラスは MGeometryRequirements です。

このクラスのインスタンスは、シェーダと、データが塗り潰される場所の間のハンドシェイク メカニズムを表します。レンダー項目の各シェーダは、その要件を提案します。要件の累積セットは、MGeometryRequirements の 1 つのインスタンスで収集および表されます。

要件は、頂点バッファ記述子(MVertexBufferDescriptor)のセットとインデックス バッファ記述子(MIndexBufferDescriptor)のセットで指定されます。

ジオメトリック データのラウンドトリップ更新を、次の図に示します。一部のジオメトリは、シェーダのセットに対して更新する必要があります。要件が収集されて、満たされると、シェーディングに必要なジオメトリが更新されます。

図 22: この例では、いくつかのレンダー項目が表示されています。それぞれのレンダー項目のシェーダで、記述子(インデックスまたはデータ)のセットを指定し、記述子は 1 つの MGeometryRequirements インスタンスに累積されます。更新が必要な場合は、これらの要件が満たされると、結果のデータが MGeometry インスタンスによってキャッシュおよび参照されます。このような特定のケースでは、すべてのレンダー項目がこの MGeometry インスタンスを参照し、このデータをレンダリング フェーズ中に使用します。

一般的なジオメトリの抽出

レンダー項目の更新のコンテキスト外またはレンダリング パイプライン自体のコンテキスト外でリソース マネージャからジオメトリを抽出できると便利な場合があります。

これを実行するには、MGeometryExtractor インタフェースを使用します。このインタフェースは、Maya DAG オブジェクトから非レンダー固有のジオメトリ データを提供するために使用されます。

これは、(MGeometryManager と呼ばれる)古いインタフェースに代わる優先メカニズムです。古いまたは新しいインタフェースのいずれかを使用したり、オブジェクトの機能インタフェース(MFn *)を使用することもできますが、既存のインタフェースでは、次のような新しいインタフェースのすべてのプロパティは利用されません。

• 抽出インタフェースは、(*MFn インタフェースとは異なり)すべてのオブジェクト タイプに対して同一です。
• ジオメトリック データはキャッシュされて必要な場合にのみ更新されるため、DG または DAG の評価のオーバーヘッドが削減されます。
• データ形式は、高速のハードウェア描画を提供するように最適化されています。
• 返されたデータは CPU に置かれ、レンダラと GPU リソースへの従属関係はありません。
• データは、呼び出し元によって所有されます。
• データ「要件」(MGeometryRequirements)を指定するために共通の一貫したメカニズムが使用されます。
• インデックス バッファと頂点バッファの両方を返すことができます。定義されたカスタム データにもこのインタフェースからアクセスできます。

現在は、ポリゴン オブジェクト タイプのみがサポートされています。

図 23: 指定した DAG パスで、ジオメトリ要件のセットが抽出機能に渡されます。関連付けられた DAG オブジェクトから、インデックスまたは頂点データ ブロックのセットを抽出することができます。

ジオメトリ クラスの比較

プラグイン作成者が既存のジオメトリ クラスを使用している場合、古いインタフェースと新しいインタフェースの間で混乱が生じる可能性があります。この混乱は特にいくつかの名前が再利用されている場合に生じます。注意すべき重要事項の 1 つは、新しいすべてのインタフェースは同じネームスペース(MHWRender)内にあるということです。

ここでは、古いクラスと新しいクラスの主な相違点を表で比較して説明します。2 つのインタフェースは、互いに互換するように設計されていないため、クラスの使用を試したり、組み合わせることはお勧めできません。

既に説明したように、大きな違いの 1 つは、すべての古いインタフェースは CPU 側のデータを管理し、新しいインタフェースは GPU 側のデータを管理するという点です。