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()
                  
    • 
                  
  • 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 comments about this page