polyModifierCmd の例

doModifyPoly()

doModifyPoly() は最も複雑で、polyModifierCmd の中核といえるものです。ここではすべてのデータが分析され、適切な処理が実行されます。doModifyPoly() では、プロセス全体を 1 つのメソッドで実装するのではなく、ノード状態を迅速にスキャンして、状態に基づいて適切なメソッドに制御を渡します。

MStatus polyModifierCmd::doModifyPoly()
{
    MStatus status = MS::kFailure;
    if( isCommandDataValid() )
    {
        // Get the state of the polyMesh
        //
        collectNodeState();
        if( !fHasHistory && !fHasRecordHistory )
        {
            MObject meshNode = fDagPath.node();
            // Pre-process the mesh – Cache the old mesh
            //
            cacheMeshData();
            cacheMeshTweaks();
            // Call the directModifier
            //
            status = directModifier( meshNode );
        }
        else
        {
            MObject modifierNode;
            createModifierNode( modifierNode );
            initModifierNode( modifierNode );
            connectNodes( modifierNode );
        }
    }
}

doModifyPoly() のスケルトン(プログラム)では、ある状態での polyShape ノードとのインタフェースを取る方法の概念がわかります。コンストラクション ヒストリが存在せず、コンストラクション ヒストリの記録がオフになっている場合、元に戻す操作に備えてメッシュ データがキャッシュされ( undoModifyPoly() を参照)、directModifier コールバックが呼び出し処理します。その他の場合は modifierNode を介する方法が取られます。コールされると、モディファイア ノードが作成されてコールバックによって初期化され、ノードの接続を試行するために渡されます。

doModifyPoly() プロセスでは、コンストラクション ヒストリの状態のみが処理されることに注意してください。一連の処理の中では微調整が大きな役割を果たしますが、微調整はコンストラクション ヒストリから独立しているので、このプロセス以降の別プロセスでは別個に考慮されます。以下の表は、ノードのコンストラクション ヒストリの状態に基づいて何が呼ばれるかを示しています。

directModifier のコードは、コマンドによって実装されており、注意すべき複雑な側面はありません。コマンドはメッシュ ノードに渡され、そこで直接動作します。すべての制御は、コマンドに残ります。

これとは対照的に、コンストラクション ヒストリに関するその他 3 つのケースはより複雑です。modifierNode の作成から説明します。

MStatus polyModifierCmd::createModifierNode( MObject& modifier )
{
    MStatus status = MS::kFailure;
    if( fModifierNodeTypeInitialized ||
        fModifierNodeNameInitialized )
    {
        if( fModifierNodeTypeInitialized )
        {
            modifier = fDGModifier.createNode(fModifierNodeType,
                &status);
        }
        else if( fModifierNodeNameInitialized )
        {
            modifier = fDGModifier.createNode(fModifierNodeName,
                &status);
        }
        // Check to make sure that we have a modifier node of the
        // appropriate type. Requires an inMesh and outMesh
        // attribute.
        //
        MFnDependencyNode depNodeFn( modifier );
        MObject inMeshAttr;
        MObject outMeshAttr;
        inMeshAttr = depNodeFn.attribute( "inMesh" );
        outMeshAttr = depNodeFn.attribute( "outMesh" );
        if( inMeshAttr.isNull() || outMeshAttr.isNull() )
        {
            displayError("Invalid Modifier: inMesh/outMesh needed");
            status = MS::kFailure;
        }
    }
    return status;
}

createModifierNode() では、モディファイア ノード タイプかモディファイア ノード名の初期化済みデータを使用し、ローカル DG モディファイアを通してモディファイア ノードを作成します。元に戻すとやり直しを比較的単純にするには、DG モディファイアの使用が不可欠です。DG モディファイアはノードを作成していませんが、接続などそのノードのアクションを待ち行列に入れられるため、DG モディファイアの doIt() がコールされるとすべてが順番に実行されます。これによって、エラーが発生した場合のロールバックの問題が緩和されます。また、createModifierNode() では、inMesh アトリビュートと outMesh アトリビュートがノードに存在するかどうかを確認するためのチェックが行われます。名前だけで判断すると限定的に思えますが、モディファイア ノードのチェーンでは標準的です。polyModifierNode というヘルパー クラス(後のセクションで説明)では、この 2 つの主要アトリビュートが自動的に生成されます。

createModifierNode() の後で initModifierNode() のコールバックが行われ、作成されたクラスでは、これによってノード データが初期化されます。これも、コマンドの制御下で行われます。そこから、最終ステージの connectNodes() に入ります。

connectNodes()

connectNodes() は大きなメソッドで、polyShape ノードとモディファイア ノードのすべての変数を処理し、polyShape とモディファイアを接続します。高いレベルから connectNodes() を調べて、制御内容を確認してください。

MStatus polyModifierCmd::connectNodes( MObject& modifierNode )
{
    MStatus status;
    // Declare our internal processing data structure
    //
    modifyPolyData data;
    // Get the mesh node attrs and plugs
    //
    status = processMeshNode( data );
    MCheckStatus( status, "processMeshNode" );
    // Get the upstream node attrs and plugs
    //
    status = processUpstreamNode( data );
    MCheckStatus( status, "processUpstreamNode" );
    // Get the modifierNode attributes
    //
    status = processModifierNode( modifierNode, data );
    MCheckStatus( status, "processModifierNode" );
    // Process the tweaks on the meshNode
    //
    status = processTweaks( data );
    MCheckStatus( status, "processTweaks" );
    // Connect the nodes
    //
    if( fHasTweaks )
    {
        status = fDGModifier.connect( data.upstreamNodeShape,
            data.upstreamNodeSrcAttr,
            data.tweakNode,
            data.tweakNodeDestAttr );
        MCheckStatus( status, "upstream-tweak connect" );
        status = fDGModifier.connect( data.tweakNode,
            data.tweakNodeSrcAttr,
            modifierNode,
            data.modifierNodeDestAttr );
        MCheckStatus( status, "tweak-modifier connect" );
    }
    else
    {
        status = fDGModifier.connect( data.upstreamNodeShape,
            data.upstreamNodeSrcAttr,
            modifierNode,
            data.modifierNodeDestAttr );
        MCheckStatus( status, "upstream-modifier connect" );
    }
    status = fDGModifier.connect( modifierNode,
        data.modifierNodeSrcAttr,
        data.meshNodeShape,
        data.meshNodeDestAttr );
    MCheckStatus( status, "modifier-mesh connect" );
    status = fDGModifier.doIt();
    return status;
}

connectNodes() は複数のサブセクションに分けられます。最初のサブセクションでは、一般的な処理データの構造が構築されます。この構造には、それぞれの処理メソッド間で必要となる、すべての処理変数が含まれます。この構造は、処理メソッド間で渡される引数の数を減らすために作成されます。そこから処理メソッドのセットがコールされ、ノードの接続に必要なデータが収集されて、ノード stat が処理されます。その後で、収集されたデータを使用してノードを接続します。

これに続く各処理メソッドの詳細については、完全に文書化された polyModifierCmd.cpp のソース コードを参照してください。

processMeshNode()

connectNodes() が実行する最初の処理メソッドは processMeshNode() です。この処理メソッドでは、ノード シェイプ、ノード変換、接続データ(inMesh プラグとアトリビュート)など、polyShape ノードで必要なすべてが処理されます。このデータは、渡された modifyPolyData データ構造に格納され、その他の処理メソッドでさらに使用されます。重要なことは、この処理メソッドが実行される順序です。

processUpstreamNode()

次の処理メソッド processUpstreamNode() では、コンストラクション ヒストリが存在するケースとコンストラクション ヒストリが存在しないケースで違いがあります。connectNodes() は、コンストラクション ヒストリが存在するケース、またはコンストラクション ヒストリは存在しないがコンストラクション ヒストリの記録がオンになっているケースでのみコールされます。このケースでは、いずれもコンストラクション ヒストリの追加が許され、より安定して柔軟に処理できるためです。

コンストラクション ヒストリが既に存在する場合、processUpstreamNode() は processMeshNode() で取得した inMesh プラグを使用し、polyShape ノードのすぐ上のノードを取得します。すぐ上のノードを取得したら、polyShape ノードからそのノードを切断し、モディファイア ノード挿入の準備をします。すべての DG 接続は、メッシュ ノードと上流ノードの間で行われるので、後で接続するために outMesh プラグとアトリビュートのみを取得します。

コンストラクション ヒストリが存在しない場合は、コンストラクション ヒストリ チェーンを作成する必要があります。各コンストラクション ヒストリ チェーンの最初には、コンストラクション ヒストリが作成された時点での polyShape ノードの初期状態を表す非表示の中間(Intermediate)ノードがあります。これは、processUpstreamNode() から polyShape ノードで MFnDAGNode::duplicate() をコールすることで作成されます。duplicate() メソッドは、新しい複製シェイプ ノードのために新しいトランスフォーム ノードを作成してから、この新しいシェイプ ノードを複製元のシェイプ ノードと同じトランスフォーム ノードに再ペアレント化します。DAG モディファイアで複製によって作成されたトランスフォーム ノードを削除します。DG に対しては、この複製シェイプ ノードは、ヒストリが存在する場合に処理される上流ノードと同じように動作します。つまりすべての接続は、この複製シェイプ ノードと元のシェイプ ノードの間で実行されます。したがって、複製シェイプ ノードに上流ノード情報を設定し、後で接続するために outMesh プラグとアトリビュートを取得します。

processModifierNode()

processMeshNode() と同じように、3 番目の処理メソッドである processModifierNode() は、connectNodes() でノードを接続するために、モディファイア ノードの inMesh アトリビュートと outMesh アトリビュートを取得します。

processTweaks()

コンストラクション ヒストリのため、微調整は、操作順序を維持するためにモディファイア ノードを追加する前に抽出する必要があります。このため、微調整が存在する場合は、以下の 2 つのステージが実行されます。

• 微調整抽出
• 微調整適用

tweak ノードの作成(polyTweak)から始まり、微調整を格納して、pnts アトリビュートで微調整が解析されます。微調整は元に戻す操作に備えてクラスの配列メンバーに個別にキャッシュされ、tweak ノードに転送するためにローカルの MObject 配列にキャッシュされます。微調整は、抽出したベクトル配列から構成されますが、抽出中に考慮すべきことはほかにもあります。微調整は pnts アトリビュートに格納されます。DG のアトリビュートとして、接続も含まれることがあります。DG 構造を維持するため、この接続は保存して tweak ノードに転送する必要があります。

それぞれのベクトル配列の他に、pnts アトリビュートに接続されている、それぞれのノードのプラグ配列と接続されている pnts アトリビュートのそれぞれのプラグを抽出します。pnts 配列アトリビュートのそれぞれのアトリビュートが、複合アトリビュートであることに注意してください。複合アトリビュートのそれぞれのアトリビュートは、特定の頂点微調整ベクトル(x、y、z)の 1 つの軸移動に関連します。

データを抽出したら、polyTweak ノード上で微調整ベクトルを適用し、それぞれの微調整ベクトル上で再接続します。これで tweak ノードができ、ヒストリ ストリームに接続する準備が整いました。しかし現状のままで接続すると、結果としてメッシュでは微調整の重複が予想されます。これは、メッシュ ノードから微調整が除去されていないためです。このため、tweak ノードから 1 回、メッシュ ノードから 1 回、合計 2 回の微調整が適用されます。しかし、MObject 配列を使用してプラグを取り出したことに注意してください。配列アトリビュートに含まれる複合プラグへの MObject 参照を抽出しました。これを tweak ノードに設定することで、それらは tweak ノード上に移動されます。processTweaks() には、コメントになっている大きなコード セグメントがあり、そのセグメントはメッシュ ノードから微調整を除去します。このコードを実行しても結果は同じですが、明らかな利点もなくパフォーマンスも低下します。

その他の処理メソッドと同じように、processTweaks() は tweak ノードの接続データを取得し、connectNodes() がすべてのノードを接続できるようにします。

connectNodes() のやり直し

必要なすべてのノードがセットアップされ、接続データが抽出されました。ノード接続は、MDGModifier::connect calls() コールでセットアップされます。すべての操作は、最後の MDGModifier::doIt() コールで実行されます。そこから、DG モディファイアを実行した反対の順序で undoIt() をコールして元に戻すをサポートし、前と同じ順序で doIt() をコールしてやり直しをサポートできます。これは、DG モディファイアが、行ったすべての実行をキャッシュしているために実現できます。同じように polyModifierCmd は、doModifyPoly() をコールして必要なすべてのデータをキャッシュします。このため、undoModifyPoly() と redoModifyPoly() が比較的単純になります。

undoModifyPoly()

undoModifyPoly の構造と抽象化レベルは、doModifyPoly() メソッドに非常によく似ています。これは、コールされたノード状態を調べて、適切なメソッドに制御を渡します。

MStatus polyModifierCmd::undoModifyPoly()
{
    MStatus status;
    if( !fHasHistory && !fHasRecordHistory )
    {
        status = undoDirectModifier();
    }
    else
    {
        fDGModifier.undoIt();
        // undoCachedMesh() must be called prior to
        // undoTweakProcessing() because undoCachedMesh()
        // copies the original mesh without tweaks back
        // onto the existing mesh. Any changes made before
        // the copy will be lost.
        //
        if( !fHasHistory )
        {
            status = undoCachedMesh();
            fDagModifier.undoIt();
        }
        status = undoTweakProcessing();
    }
    return status;
}

undoDirectModifier()

undoDirectModifier は、directModifier のように単純ではありません。polyModifierCmd は directModifier が実行する内容を認識しないので、undoDirectModifier がメッシュ全体を元の状態に戻す必要があります。undoDirectModifier は、MObject の動作方法の知識を利用して、MObject ハンドルをそれぞれの MObject ごとに実行します。

MObject は、Maya が所有する内部オブジェクトのハンドルであると言われています。しかしこれは部分的にしか合っていません。MObject はハンドルですが、Maya が常に MObject を所有しているわけではありません。Maya には、参照をカウントするオブジェクトがあります。つまり、オブジェクトの参照ごとにカウントに 1 が加算されます。参照が削除されるたびに、ゼロに達してオブジェクトが削除されるまで、カウントから 1 が差し引かれます。これは、使用されている場合に限って有効であるオブジェクトのようなものです。MObject は、リファレンス数のオブジェクトを参照することがあります。このため、Maya がオブジェクトを所有していても、オブジェクトの MObject ハンドルを維持して、オブジェクトの存続期間を制御できます。その他のタイプのオブジェクトでは、プラグインのコール間にデータが変更される可能性があるため(ノードの削除など)、MObject を維持しないという一般的なヒントが有効で強く推奨されます。

参照がカウントされるタイプのデータは、MFnData クラスと MFnComponent クラスの階層で分類されるオブジェクトです。MFnData オブジェクト タイプには、メッシュの内容全体が組み込まれています。メッシュのバックアップの基礎としてこの概念を使用すると、ダイレクト モディファイアを適切に元に戻すことができます。

cacheMeshData()

cacheMeshData() は、directModifier() の前に、メッシュの使用に関するデータをキャッシュします。メッシュ データのキャッシュには、MObject 概念が使用されます(undoDirectModifier() を参照). データをバックアップする場合は、現行オブジェクトの参照を取得しないように注意してください。dirty になっている可能性があるデータの参照を維持することになってしまいます。これを避けるには、現行メッシュを複製し、複製メッシュの outMesh アトリビュートから MObject を抽出して MFnData オブジェクトを取得します。取得した MObject は、元のメッシュ データの参照なので、参照カウントに 1 が加算されます。ユーザにこれを意識させないようにするには、複製で作成したノードを削除して仕上げます。ノードを削除しても、参照があるので、メッシュ データは削除されません。

cacheMesh Tweaks()

このメソッドは、tweak ノードを処理しないことを除けば、processTweaks() メソッドと同じです。pnts アトリビュートを分析し、微調整キャッシュ データ メンバーに微調整ベクトルを抽出します。

undoDirectModifier() のやり直し

メッシュのバックアップに必要なデータをキャッシュして undoDirectModifier() で使用できます。微調整がある場合とない場合では、polyShape ノードのデータ フローが異なります。これは、バックアップ メッシュを再適用する方法に直接的な影響を与えます。

微調整は、ノード内のデータ フローのため、バックアップ メッシュの再適用に影響します。微調整がないノードでは、outMesh の値をバックアップ メッシュに設定できます。

微調整があるノードでは、バックアップ メッシュを cachedInMesh にコピーしてノードの同期を維持する必要があります。この場合は、polyShape ノードを複製して複製シェイプの outMesh をバックアップ メッシュに設定し、複製した polyShape ノードを元のノードに接続します。(DG)評価を強制実行した後で、複製した polyShape ノードを切断して削除します。これで、outMesh にはバックアップ メッシュが維持されます。次に undoTweaksProcessing で初期微調整をノードに再適用し、ノードで cachedInMesh にバックアップ メッシュをコピーして、内部ノードの同期化を実行します。

undoModifyPoly() のやり直し

connectNodes() を元に戻す必要がある場合、MDGModifier::undoIt() メソッドは、connectNodes() によって作成されたすべての接続とノードを元に戻します。最初にヒストリがなかった場合、processUpstreamNode() も DAG モディファイアを使用したことに注意してください。この場合は、MDagModifier::undoIt() をコールする前に別の操作を実行する必要があります。

これは、ヒストリを作成して操作を元に戻すため、ヒストリを除去する必要があるからです。除去は単純ですが、ノードの outMesh アトリビュートには最終のノード評価が維持される、つまりモディファイアがまだ含まれています。このため、ノードで「キャッシュされている」メッシュを元に戻す必要があります。これには、メソッド undoCachedMesh() をコールします。メッシュ データの復元に続けて微調整を復元し、元のメッシュを残します。

undoCachedMesh()

undoDirectModifier() の場合と同じように、undoCachedMesh() に含まれる操作は、ノードのデータ フローが変化するため、微調整の存在によって決まります。ヒストリがないノードに戻し、ノードと直接インタフェースを取ってメッシュを復元する必要があるからです。

微調整が存在しない場合は、outMesh がノードを表すジオメトリになるため、outMesh を復元するだけで済みます。これを実行するには、ヒストリ チェーンを始めるために作成された複製シェイプ ノードを使用します。最初にヒストリが存在していなかった場合に限ってこれを実行することに注意してください。複製シェイプ ノードの outMesh を取得し、シェイプ ノードの outMesh にそのメッシュ データをコピーして、ノードを初期状態に戻します。

微調整が存在する場合は、undoDirectModifier が微調整を処理する場合と同じ方法でノードにアクセスする必要がありますが、ここではシェイプ ノードを複製する必要がありません。既に複製が存在するからです。複製シェイプの outMesh を元のシェイプの inMesh にローカル DG モディファイアで再接続し、DG 評価を強制実行します。次に、同じDG モディファイアで接続を元に戻します。元のメッシュ データが outMesh に入ってから微調整が再適用されて、outMesh は cachedInMesh にコピーされます。

redoModifyPoly()

redoModifyPoly() は簡単です。操作に必要なものはすべて doModifyPoly() で初期化して設定してあるからです。redoModifyPoly() にも doModifyPoly() と同様の構造が保持されます。directModifier() の場合、doModifyPoly() は、メッシュ データを再びキャッシュすることなくメソッドをリコールします。これは、クラスに既に存在するからです。connectNodes() の場合は、MDGModifier::doIt() をリコールし、doModifyPoly() が以前セットアップした操作を再実行します。

MStatus polyModifierCmd::redoModifyPoly()
{
    MStatus status = MS::kSuccess;
    if( !fHasHistory && !fHasRecordHistory )
    {
        MObject meshNode = fDagPath.node();
        // Call the directModifier – No need to pre-process the
        // mesh data again.
        //
        status = directModifier( meshNode );
    }
    else
    {
        // Call the redo on the DG and DAG modifiers
        //
        if( !fHasHistory )
        {
            status = fDagModifier.doIt();
        }
        status = fDGModifier.doIt();
    }
    return status;
}

polyModifier Fty

polyModifierCmd の内部動作からは、directModifier() とモディファイア ノードの内部の処理部という、冗長コードが潜在する 2 つの場所を確認できます。この 2 つは、入力の取得方法が異なることを除くと、結果的に同じことを実行します。コードの重複を減らすため、ファクトリという概念が導入されました。ファクトリは、メッシュの修正を実装するクラス構造としてだけ存在します。これには、モディファイアをコールできる基本インタフェースがあります。

ファクトリのガイドとして、polyModiferFty というベース ファクトリ クラスが提供されています。このベース ファクトリ クラスからファクトリを派生させることができます。これには特に機能はありませんが、修正する場合のアウトラインとなります。

class polyModifierFty
{
    public:
        polyModifierFty();
        virtual ~polyModifierFty();
        // Pure virtual doIt()
        //
        virtual MStatus doIt() = 0;
};

polyModifierNode

polyModifierFty と同じように、polyModifierCmd に関連して使用する、すべてのモディファイア ノードのフレームワークとなる、別のガイダンス クラスが提供されています。このクラスは、モディファイア ノードが動作するには、inMesh アトリビュートと outMesh アトリビュートが必要であることなどを提案します。

class polyModifierNode
{
    public:
        polyModifierNode();
        virtual ~polyModifierNode();
        // There needs to be an MObject handle declared for
        // each attribute that the node will have. These handles
        // are needed for getting and setting the attribute
        // values later.
        //
        static MObject inMesh;
        static MObject outMesh;
};

polyModifierCmd コマンドの実装についての詳細は、「splitUVCmd の例」 (次のセクション)とソース コードの両方を参照してください。ソース コード内では、それぞれのクラスの一般的なガイドラインが提供されています。