Developer Resources > API Guide > Polygon API > 
splitUVCmd example
 
 
 

(Source code is located in the devkit 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() 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:
            

            
            
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