splitUVCmd example

(Source code is located in the Developer Kit \plug-ins directory.)

The splitUV command is a MEL command used to unshare or "split" the selected UVs of a polygonal mesh. A UV is a point on a 2D texture plane that is used to map textures onto a mesh. To properly associate these UVs with a mesh, each face can either be mapped or unmapped. If a face is mapped, each vertex belonging to that face is associated with a UV. This relationship is known as a face-vertex relationship. (For more information, see Face-Vertices.)

For a better understanding of what splitting a UV means, try the following steps in Maya:

  1. Create a square 3x3 face polygonal plane.
  2. With the plane selected, open the UV Texture Editor (Edit UVs > UV Texture Editor).
  3. Change the selection mode to UVs.
  4. Select a UV inside the plane (not along the border).
  5. Select the Move tool.
  6. Drag the UV around and notice that there is only a single UV.
  7. Change the selection mode to Edges.
  8. Select all four edges surrounding the UV you moved.
  9. Select Edit UVs > Cut UV Edges.
  10. Change the selection mode back to UVs.
  11. Click once on the selected UV. (Make sure you do not drag over the UV or you will select them all.)
  12. Turn on the display of unshared UVs (Display > Polygons > Unshared UVs).
  13. Drag the UV around and notice that it is no longer shared among the faces but is a single UV with its own face.
  14. [Optional] Turn on the display of texture borders (Display > Polygons > Texture Border Edges) to reveal the new borders introduced by the cut operation.

The Cut UV Edges command operates on edges of a mesh while splitUV operates on a UV.

UVs are stored in a single linear array, indexed by face vertices. Each face vertex indexes a specific UVId, and in turn each UVId represents a single UV point on a texture map. Thus the same number of faces that share the UV would index a shared UVId. (For more information, see UVs.)

You need to add a number of UVs (at the same 2D coordinates) equal to the total number of faces that share the UV minus one. Subtract one knowing you already have at least one UV already associated to a shared face, which leaves one less face and UV to create and associate. Now associate each of the new UVs to one of the faces that shared the original UV, leaving one of the faces indexing the original UV itself. This leaves each face with an unshared UV at their respective face-vertex location.

Initial implementation

First gather your input—in this case the selected UVs. Obtain the selection list and filter it for the first object you find with selected UVs. For simplicity, only the first object encountered with selected UVs is taken. You can easily extend this to operate on multiple objects. 

// Get the active selection list and filter for poly objects.
// Also create a selection list iterator to parse the list
//
MSelectionList selList;
MGlobal::getActiveSelectionList( selList );
MItSelectionList selListIter( selList );
selListIter.setFilter( MFn::kMesh );
// Declare a dagPath and component to store a reference to the
// mesh object and selected components
//
MDagPath dagPath;
MObject component;
// Now parse the selection list for poly objects with selected
// UVs
//
for( ; !selListIter.isDone(); selListIter.next() )
{
    selListIter.getDagPath( dagPath, component );
    // Check for selected UVs
    //
    if( component.apiType() == MFn::kMeshMapComponent )
    {
        break;
    }
}
// Now we break down the component object into an int array
// of UVIds
//
MFnSingleIndexedComponent compFn( component );
MIntArray selUVs;
compFn.getElements( selUVs );

Now you have the object to operate on and the selected UVs. Before you can perform the operation, you need to collect some preprocessing data—which faces share each selected UV and the UV vertex associations. Finally, you must cover for the possible appearance of multiple UV sets. Since UVs from only one UV set can be selected at any particular time, you only need to access the current active UV set and operate on that set. 

// Declare our processing variables
//
MObject mesh;
MString selUVSet;
MIntArray selUVFaceIdMap;
MIntArray selUVFaceOffsetMap;
MIntArray selUVLocalVertIdMap;
// Make sure our dagPath points to a shape node. That is where
// the topological/geometry data is stored (not on the transform)
//
dagPath.extendToShape();
mesh = dagPath.node();
// Initialize a mesh function set to our mesh
//
MFnMesh meshFn( mesh );
// Get the current UV set name
//
meshFn.getCurrentUVSetName( selUVSet);
// Now parse the mesh for face and vertex UV associations
//
MItMeshPolygon polyIter( mesh );
int i;
int j;
int offset = 0;
int selUVsCount = selUVs.length();
for( i = 0; i < selUVsCount; i++ )
{
    // Append the current offset in the faceId map to the
    // faceOffset map so we have an index reference into the
    // faceId map for each selected UV. In other words,
    // for each offset value, we have a number of faces equal
    // to (faceOffsetMap[i+1] – faceOffsetMap[i]) that share
    // the UV that that offset value represents.
    //
    selUVFaceOffsetMap.append( offset );
    // Parse the mesh for faces which share the current UV
    //
    for( ; !polyIter.isDone(); polyIter.next() )
    {
        // Only continue if the face is mapped
        //
        if( polyIter.hasUVs() )
        {
            // Now parse the vertices of each face and check for
            // the current UV
            //
            int polyVertCount = polyIter.polygonVertexCount();
            for( j = 0; j < polyVertCount; j++ )
            {
                int UVIndex = 0;
                polyIter.getUVIndex( j, UVIndex );
                // If we find the UV on this face, append the faceId,
                // append the local vertex (relative to the current
                // face) and increment our offset.
                //
                if( UVIndex == selUVs[i] )
                {
                    selUVFaceIdMap.append( polyIter.index() );
                    selUVLocalVertIdMap.append(j);
                    offset++;
                    break;
                }
            }
        }
    }
}
// Finally append the last offset value so we can obtain the
// number of faces that share the last UV in the list.
//
selUVFaceOffsetMap.append( offset );

The face and face-vertex associations are stored using a similar technique used by Maya to store topological data for polygons. This technique is apparent in the code where the list of faces shared by each selected UV is accumulated. Rather than creating a multi dimensional array to store the list of faces shared by each selected UV, store it all in a single dimensional array (a data array). To do this you create another single dimensional array (an index array) to store the index values of the data array where each selected UV begins its list of faces.

For each UV, parse the mesh for any faces sharing that particular UV. This is accomplished by parsing the face-vertices of each face in the mesh, looking at the associated UVId and comparing the UVId with the current UV. Now store the face Id and the local vertex Id (relative to the current face, enumerating from 0 to (faceVertexCount – 1)). Make note of the local vertex Id rather than the global or mesh vertex Id because UVs are assigned on a face-vertex basis. 

// Declare UV count variables so we can keep create and
// keep track of the indices of the new UVs
//
int currentUVCount = meshFn.numUVs( selUVSet );
// For each UV in our list of selected UVs, split the UV.
//
for( i = 0; i < selUVsCount; i++ )
{
    // Get the current faceId map offset
    //
    offset = selUVFaceOffsetMap[i];
    // Get the U and V values of the current UV
    //
    float u;
    float v;
    int UVId = selUVs[i];
    meshFn.getUV( uvId, u, v, &selUVSet );
    // Get the number of faces sharing the current UV
    //
    int faceCount = selUVFaceOffsetMap[i+1]–selUVFaceOffsetMap[i];
    // Arbitrarily choose that the last faceId in the list
    // of faces sharing this UV will keep the original UV
    //
    for( j = 0; j < faceCount – 1; j++ )
    {
        // Create a new UV (setUV dynamically sizes the UV array
        // if the index value passed in exceeds the length of the
        // UV array) with the same 2D coordinates as our UV.
        //
        meshFn.setUV( currentUVCount, u, v, &selUVSet );
        // Get the face and face-vertex info so we can assign
        // our newly created UV to one of the faces in the list
        // of faces sharing this UV
        //
        int localVertId = selUVLocalVertIdMap[offset];
        int faceId = selUVFaceIdMap[offset];
        // Associate the UV with the particular face vertex
        //
        meshFn.assignUV( faceId,
            localVertId,
            currentUVCount,
            &selUVSet );
        // Increment our counters so we can create another new UV
        // at the currentUVCount index. Increment the offset, so we
        // can associate the next new UV with the next face in the
        // the list of faces sharing this UV
        //
        currentUVCount++;
        offset++;
    }
}

There are two primary methods which are called to perform the actual split:

Call the first method, setUV(), to create a new UVId. The method automatically grows the UV array to accommodate the index passed into the method. Thus in the code you can see a variable named currentUVCount which is continuously incremented after each new UV. currentUVCount keeps track of the index that is one element greater than the highest element in the UV array. Incrementing it after each iteration through the loop allows you to create a new UV, one at a time.

Call the second and last method, assignUV(), to associate a given UVId with a face and face-vertex.

Integrating into the Maya architecture

There are many intricacies involving modifying a polygonal mesh, including construction history and tweaks. If the mesh does not have history, you could attempt to unshare the UVs directly on the mesh itself. If the mesh has history, any DG evaluation from a node upstream in the construction history overwrites the mesh on the mesh node and the modifications made directly to the mesh would be lost. Even if that were the case, the existence of tweaks would change the appropriate place to write the modifications on the mesh.

You need to look at the mesh node, analyze its state, and apply your operation accordingly. The MPxCommand class polyModifierCmd (see polyModifierCmd example) was developed with the splitUV command to aid in abstracting the handling of construction history and tweaks. polyModifierCmd is a mid level command class designed for commands which intend to modify a polygonal mesh. It provides an outlet through which a poly command can take its code to modify a mesh directly and seamlessly integrate it into the Maya framework, accounting for both construction history and tweaks.

polyModifierCmd is a good example of using the API and demonstrates how construction history and tweaks work.

polyModifierCmd enhanced splitUV

Before you proceed with this section, read the polyModifierCmd example. This section steps through the implementation of a command based on polyModifierCmd.

There are three main pieces of the polyModifierCmd that must be handled:

splitUV factory

The factory is the lowest level of the splitUVCmd, which performs the operation given a set of inputs. The inputs are an integer array of UV Ids and a reference to the mesh you are about to modify. The rest fits inside the factory. The splitUVFty factory class interface is shown below. 

class splitUVFty : polyModifierFty
{
    public:
        splitUVFty();
        virtual ~splitUVFty();
        void setMesh( MObject mesh );
        void setUVIds( MIntArray uvIds );
        // polyModifierFty inherited methods
        //
        MStatus doIt();
    private:
        // Mesh Node
        //
        MObject fMesh;
        // Selected UVs
        //
        MIntArray fSelUVs;
};

splitUV node

There are two methods of deploying the factory. One is through the splitUV node and the other is directly through the command for certain exception cases where the node is not applicable. The splitUV node is used for cases where you want to build or add to an existing history chain in the DG.

When a DG evaluation is propagated via a dirtied node, the DG evaluates from the top of the history chain where a copy of the original mesh (original referring to the node’s state denoting the start of this history) is located. It then takes a copy of that mesh and passes it in through each node in order, where the mesh is altered through each node evaluation. Once it reaches the final shape, you have a mesh placed onto the shape which holds all the modifications stored in the history chain. The splitUV node needs to take in a mesh input as well as an input of which UVs to modify, and pass that data down to an instance of the factory. The resulting mesh is then passed out through a mesh output attribute. 

class splitUVNode : polyModifierNode
{
    public:
        splitUVNode();
        virtual ~splitUVNode();
        virtual MStatus compute(const MPlug& plug, MDataBlock& data);
        static void* creator();
        static MStatus initialize();
    private:
        // Note: There needs to be an MObject handle for each
        // attribute on the node. These handles are needed for
        // setting and getting values later. The standard inMesh
        // and outMesh attributes are already inherited from
        // polyModifierNode, thus we only need to declare splitUVNode
        // specific attributes
        //
        static MObject uvList;
        // Node type identifier
        //
        static MTypeId id;
        // We instantiate a copy of our splitUV factory on the node
        // for it to perform the splitUV operation
        //
        splitUVFty fSplitUVFactory
};

The standard node interface is in the above class declaration. The only differences to note reside in the private members. From the class hierarchy, splitUVNode inherits an inMesh and outMesh attribute from polyModifierNode. We add yet another attribute to the node, specific to the splitUVNode, which consists of our only other input—the list of UVs to operate on.

Notice that the node class has an instance of a splitUV factory. You create a distinct factory for each node so that the splitUVFty implementation would require no foreknowledge of which node is calling the operation. Continuing with the basic node setup, implement the basic methods in the above interface, creating and associating attributes, assigning a type id, etc.: 

MTypeId splitUVNode::id( 0x34567 );
MStatus splitUVNode::creator()
{
    return new splitUVNode();
}
MStatus splitUVNode::initialize()
{
    MStatus status;
    MFnTypedAttribute attrFn;
    uvList = attrFn.create("inputComponents",
        "ics",
        MFnComponentListData::kComponentList);
    // To be stored during file-save
    attrFn.setStorable(true);
    inMesh = attrFn.create("inMesh",
        "im",
        MFnMeshData::kMesh);
    // To be stored during file-save
    attrFn.setStorable(true);
    // outMesh is read-only because it is an output attribute
    //
    outMesh = attrFn.create("outMesh",
        "om",
        MFnMeshData::kMesh);
    attrFn.setStorable(false);
    attrFn.setWritable(false);
    // Add the attributes we have created for the node
    //
    status = addAttribute( uvList );
    if( !status )
    {
        status.perror("addAttribute");
        return status;
    }
    status = addAttribute( inMesh );
    if( !status )
    {
        status.perror("addAttribute");
        return status;
    }
    status = addAttribute( outMesh );
    if( !status )
    {
        status.perror("addAttribute");
        return status;
    }
    // Set up a dependency between the inputs and the output.
    // This will cause the output to be marked dirty when the
    // input changes. The output will then be recomputed the
    // next time it is requested.
    //
    status = attributeAffects( inMesh, outMesh );
    if( !status )
    {
        status.perror("attributeAffects");
        return status;
    }
    status = attributeAffects( uvList, outMesh );
    if( !status )
    {
        status.perror("attributeAffects");
        return status;
    }
    return MS::kSuccess;
}

Finally, we turn towards the implementation of our compute() method. The compute method is not overly complex. Since we have the factory to perform the operation, all the compute method needs to do is provide the factory with the references to the proper mesh to modify.

Start as all plug-in nodes should and look to handle the ‘state’ attribute, inherited from MPxNode, on the node. The ‘state’ attribute holds a short integer representing how the DG treats the node. In a sense it is an override mechanism to alter how the node is treated during a DG evaluation. With respect to plug-in nodes, the only state of concern is the ‘HasNoEffect’ or ‘PassThrough’ state, where the node is ignored entirely. For the node to behave as though it were transparent, you need to redirect the inMesh to the outMesh without altering the mesh passing through. Otherwise the node behaves normally.

Following the node state check, grab the UVs from the component list and the input mesh, assign the input mesh to the output mesh, and pass in these references to the factory. Assigning the input mesh to the output mesh allows you to operate directly on the output mesh, so that the output mesh will hold the modified mesh. From there, let the factory take care of the rest of the operation. 

MStatus splitUVNode::compute(const MPlug& plug, MDataBlock& data)
{
    MStatus status = MS::kSuccess;
    // Retrieve our state attribute value
    //
    MDataHandle stateData = data.outputValue(state,&status);
    MCheckStatus( status, "ERROR getting state" );
    // Check for the HasNoEffect/PassThrough state
    //
    // (stateData is stored as a short)
    //
    // (0 = Normal)
    // (1 = HasNoEffect/PassThrough)
    // (2 = Blocking)
    // ..
    //
    if( stateData.asShort() == 1 )
    {
        MDataHandle inputData = data.inputValue(inMesh,&status);
        MCheckStatus(status, "ERROR getting inMesh");
        MDataHandle outputData = data.outputValue(outMesh,&status);
        MCheckStatus(status, "ERROR getting outMesh");
        // Simply redirect the inMesh to the outMesh
        //
        outputData.set(inputData.asMesh());
    }
    else
    {
        // Check which output value we have been asked to compute.
        // If the node doesn’t know how to compute it, return
        // MS::kUnknownParameter.
        //
        if( plug == outMesh )
        {
            MDataHandle inputData = data.inputValue( inMesh,
                &status );
            MCheckStatus(status, "ERROR getting inMesh");
            MDataHandle outputData = data.outputValue( outMesh,
                &status );
            MCheckStatus(status, "ERROR getting outMesh");
            // Now, we retrieve the input UV list
            //
            MDataHandle inputUVs = data.inputValue( uvList,
                &status );
            MCheckStatus(status, "ERROR getting uvList");
            // Copy the inMesh to the outMesh so we can operate
            // directly on the outMesh
            //
            outputData.set(inputData.asMesh());
            MObject mesh = outputData.asMesh();
            // Retrieve the UV list from the component list
            //
            // Note, we use a component list to store the components
            // because it is more compact memory wise. (ie.
            // comp[81:85] is smaller than comp[81],...,comp[85])
            //
            MObject compList = inputUVs.data();
            MFnComponentListData compListFn( compList );
            unsigned i;
            int j;
            MIntArray uvIds;
            for( i = 0; i < compListFn.length(); i++ )
            {
                MObject comp = compListFn[i];
                if( comp.apiType() == MFn::kMeshMapComponent )
                {
                    MFnSingleIndexedComponent uvComp(comp);
                    for( j = 0; j < uvComp.elementCount(); j++ )
                    {
                        int uvId = uvComp.element(j);
                        uvIds.append(uvId);
                    }
                }
            }
            // Set the mesh object and uvList on the factory
            //
            fSplitUVFactory.setMesh( mesh );
            fSplitUVFactory.setUVIds( uvIds );
            // Now, call the factory to perform the splitUV
            //
            status = fSplitUVFactory.doIt();
            // Mark the outputMesh as clean
            //
            outputData.setClean();
        }
        else
        {
            status = MS::kUnknownParameter;
        }
    }
    return status;
}

splitUV command

Now that we have a splitUVNode, the last thing left on the list to do is the splitUV command. This is the piece that ties everything together. It is from here that the method for modifying the mesh is chosen (although implicitly through polyModifierCmd). The command manages the operation and is the highest level of interfacing with the user.

As a child class of polyModifierCmd, the splitUVCmd does not have much work to do other than override some specific polyModifierCmd methods and retrieve the input. 

class splitUV : polyModifierCmd
{
    public:
        splitUV();
        virtual ~splitUV();
        static void* creator();
        bool isUndoable();
        // MPxCommand inherited methods
        //
        MStatus doIt( const MArgList& );
        MStatus redoIt();
        MStatus undoIt();
        // polyModifierCmd inherited methods
        //
        MStatus initModifierNode( MObject modifierNode );
        MStatus directModifier( MObject mesh );
    private:
        // Private methods
        //
        bool validateUVs();
        MStatus pruneUVs();
        // Private members
        //

        // Selected UVs
        //
        // We store two copies of the UVs, one that is passed down to
        // the node and another kept locally for the directModifier.
        // Note, the MObject member, fComponentList, is only ever
        // accessed during a single call of a plugin, never between
        // calls where its validity is not guaranteed.
        //
        MObject fComponentList;
        MIntArray fSelUVs;
        // splitUV Factory
        //
        // This factory is for the directModifier to have access to
        // operate directly on the mesh.
        //
        splitUVFty fSplitUVFactory;
};

This looks much like the standard MPxCommand class interface. However there are a few differences due to the polyModifierCmd inheritance as well as some performance enhancing methods. Two methods need to be overridden:

  • initModifierNode()
  • directModifier()

initModifierNode() is the chance for a command to initialize any inputs aside from the inMesh on the modifier node, which in our case is the splitUVNode. This is not restricted to input initialization, but can be catered towards custom node initialization if desired. This method is called before the modifier node is placed in the history chain, if the creation of history is permissible. For example, in our case we’d like to initialize the uvList input on our splitUVNode: 

MStatus splitUV::initModifierNode( MObject modifierNode )
{
    MStatus status;
    // Tell the splitUVNode which UVs to operate on.
    // 
    MFnDependencyNode depNodeFn( modifierNode );
    MObject uvListAttr;
    uvListAttr = depNodeFn.attribute( "inputComponents" );
    // Pass the component list down to the node.
    // To do so, we create/retrieve the current plug
    // from the uvList attribute on the node and simply
    // set the value to our component list.
    //
    MPlug uvListPlug( modifierNode, uvListAttr );
    status = uvListPlug.setValue( fComponentList );
    return status;
}

directModifier() is a method called only in a specific exception case where the mesh node has no history and the preference to record history is turned off. The consequence of this state is that the user does not wish to have any history chain at all. So in effect, the polyModifierCmd is forbidden to use the DG. As a result we modify the mesh directly. The polyModifierCmd description discusses the implications of this state in more detail as well as alternative approaches. However all we need to know is that we need to provide a method to operate on the mesh directly, which if you recall, we completed in the concepts section. It is for this reason that the command also holds an instance of the factory as well as a copy of the UVs to modify in an integer array format (as opposed to a component list for the splitUVNode).

You might wonder why we store two copies of the selected UVs in different formats. The reason for this is that an MObject is never guaranteed to be valid between plug-in calls (including redoIt() calls). Since the directModifier() would be called in a redoIt() case, it would rely on the validity of the MObject component list between calls. As such we’ve stored two copies on the command. Alternatively, one could choose to modify the node so that it receives an integer array as a node input rather than a component list to streamline the operation, however it’s a balancing issue of performance vs. storage.

Using these inputs we have the following simple directModifier() method: 

MStatus splitUV::directModifier( MObject mesh )
{
     MStatus status;
     fSplitUVFactory.setMesh( mesh );
     fSplitUVFactory.setUVIds( fSelUVs );
     // Now, call the factory to perform the splitUV
     //
     status = fSplitUVFactory.doIt();
     return status;
}

Before we look at the performance enhancing methods, let’s take a peek at the MPxCommand inherited methods. These methods will give us a better appreciation of how the performance of the command can be slightly tweaked:

  • doIt()
  • undoIt()
  • redoIt()

The doIt() method is our main method which retrieves the input and caters the rest of the operation to the various parts, overseeing the entire operation. The doIt() method is the method used to initialize the command and perform the operation as the name would suggest. And much to that effect, the splitUV’s doIt() method does exactly that.

We begin by parsing the selection list for any objects where UVs are selected, just the same as we did in our original implementation. Following that we initialize the polyModifierCmd settings, call our performance enhancing methods and issue the doModifyPoly() method, which can be viewed as the polyModifierCmd’s version of doIt(). Additionally we scatter the appropriate error messages in the code to inform the user of improper use of the command. 

MStatus splitUV::doIt( const MArgList& )
{
    MStatus status;
    MSelectionList selList;
    MGlobal::getActiveSelectionList( selList );
    MItSelectionList selListIter( selList );
    selListIter.setFilter( MFn::kMesh );
    // Initialize our component list
    //
    MFnComponentListData compListFn;
    compListFn.create();
    // Parse the selection list
    //
    bool found = false;
    bool foundMultiple = false;
    for( ; !selListIter.isDone(); selListIter.next() )
    {
        MDagPath dagPath;
        MObject component;
        selListIter.getDagPath( dagPath, component );
        if( component.apiType() == MFn::kMeshMapComponent )
        {
            if( !found )
            {
                // Add the components to our component list.
                // ‘component’ holds all selected components
                // on the given object, so only a single call
                // to add is needed.
                //
                compListFn.add( component );
                fComponentList = compListFn.object();
                // Locally store the selected UVIds in the command
                // int array member, fSelUVs
                //
                MFnSingleIndexedComponent compFn( component );
                compFn.getElements( fSelUVs );
                // Ensure that our DAG path is pointing to a
                // shape node. Set the DAG path for polyModifierCmd.
                //
                dagPath.extendToShape();
                setMeshNode( dagPath );
                found = true;
            }
            else
            {
                // Since we are only looking for whether or not there
                // are multiple objects with selected UVs, break out
                // once we have found one other object.
                //
                foundMultiple = true;
                break;
            }
        }
    }
    if( foundMultiple )
    {
        displayWarning( "Only operates on first found mesh" );
    }
    // Set the modifier node type for polyModifierCmd
    //
    setModifierNodeType( splitUVNode::id );
    if( found )
    {
        if( validateUVs() )
        {
            // Now, pass control over to polyModifierCmd
            //
            status = doModifyPoly();
            if( status == MS::kSuccess )
            {
                setResult( "splitUV command succeeded!" );
            }
            else
            {
                setResult( "splitUV command failed!" );
            }
        }
        else
        {
            displayError( "Selected UVs are not splittable" );
            status = MS::kFailure;
        }
    }
    else
    {
        displayError( "Unable to find selected UVs" );
        status = MS::kFailure;
    }
    return status;
}

The undo/redo mechanism is supported by the undoIt() and redoIt() methods inherited from MPxCommand. These methods often use cached data from the first doIt() to execute. This is what splitUV does as well as polyModifierCmd, which supports its own undo/redo in the form of undoModifyPoly() and redoModifyPoly(). Since splitUV relies on polyModifierCmd to perform the operation, the undo/redo redirects the undo/redo to polyModifierCmd. As a result, the splitUV’s undoIt() and redoIt() methods are very straightforward: 

MStatus splitUV::redoIt()
{
    MStatus status;
    status = redoModifyPoly();
    if( status == MS::kSuccess )
    {
        setResult( "splitUV command succeeded!" );
    }
    else
    {
        setResult( "splitUV command failed!" );
    }
    return status;
}
MStatus splitUV::undoIt()
{
    MStatus status;
    status = undoModifyPoly();
    if( status == MS::kSuccess )
    {
        setResult( "splitUV undo succeeded!" );
    }
    else
    {
        setResult( "splitUV undo failed!" );
    }
    return status;
}

The call to validateUVs() in the doIt() method is a performance enhancing method. Though this method is primarily a pre-condition check on the selected UVs, it increases the optimal performance of the command by pruning the selected UV list of UVs that cannot be split. This potentially saves the operation unnecessary loops. However, an extra pass of the mesh is required to check for UVs that cannot be split, but only on the very first call to the command. Any successive redoIt() calls or node evaluations are faster.

To define when a UV is invalid and unable to be split, look at the definition of the operation. splitUV provides each face which shares a particular UV with it’s own unique and unshared UV. Thus a UV can only be split if it is shared by more than one face. Subsequently, the validateUVs() method parses the mesh and retrieves the face sharing information for each UV, marking valid UVs. The valid UV list is sent to the pruneUVs() method which replaces the component list and locally stored integer array of selected UVs. 

bool splitUV::validateUVs()
{
    // Get the mesh that we are operating on
    //
    MDagPath dagPath = getMeshNode();
    MObject mesh = dagPath.node();
    // Get the number of faces sharing each UV
    //
    MFnMesh meshFn( mesh );
    MItMeshPolygon polyIter( mesh );
    MIntArray selUVFaceCountArray;
    int i;
    int j;
    int count = 0;
    selUVsCount = fSelUVs.length();
    for( i = 0; i < selUVsCount; i++ )
    {
        for( ; !polyIter.isDone(); polyIter.next() )
        {
            if( polyIter.hasUVs() )
            {
                int UVIndex = 0;
                polyIter.getUVIndex( j, UVIndex );
                // If we have a matching UVId, then we have a
                // face which shares this UV, so increment the
                // count.
                //
                if( UVIndex == fSelUVs[i] )
                {
                    count++;
                    break;
                }
            }
        }
        selUVFaceCountArray.append( count );
    }
    // Now, check to make sure that at least one UV has more than
    // one face sharing it. So long as we have at least one valid
    // UV, we should proceed with the operation by returning true
    //
    bool isValid = false;
    MIntArray validUVIndices;
    for( i = 0; i < selUVsCount; i++ )
    {
        if( selUVFaceCountArray > 1 )
        {
            isValid = true;
            validUVIndices.append(i);
        }
    }
    if( isValid )
    {
        pruneUVs( validUVIndices );
    }
    return isValid;
}
MStatus splitUV::pruneUVs( MIntArray& validUVIndices )
{
    MStatus status = MS::kSuccess;
    unsigned i;
    MIntArray validUVIds;
    for( i = 0; i < validUVIndices.length(); i++ )
    {
        int uvIndex = validUVIndices[i];
        validUVIds.append( fSelUVs[uvIndex] );
    }
    // Replace our local int array of UVIds
    //
    fSelUVs.clear();
    fSelUVs = validUVIds;
    // Build our list of valid components
    //
    MFnSingleIndexedComponent compFn;
    compFn.create( MFn::kMeshMapComponent );
    compFn.addElements( validUVIds );
    MObject component = compFn.object();
    // Replace the component list
    //
    MFnComponentListData compListFn;
    compListFn.create();
    compListFn.add( component );
    fComponentList = compListFn.object();
    return status;
}

For further details on the implementation of the splitUV command, look at the source code provided in the plug-ins directory of the developer’s kit.

Please send us your comment about this page

Creative Commons License Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Please see the Autodesk Creative Commons FAQ for more information.