Still Here….

Heya.

First, a couple quotes from work:

“There are no small parts, just small animators.”

“Well, that’s what you get for putting rigging on your reel.”
An animator told me this after he discovered that I was rigging now.

Next, a little MEL, if you don’t mind.
A friend of mine sent me a mel script a week or so ago to get some feedback. I wrote some suggestions, and figured I might as well share them here. (hope you don’t mind)

Avoid selecting things within the script. I think it can probably slow things down in larger scripts, adds extra lines of code, and it can be hard to keep track of what’s selected. Certain procedures end up selecting what they create, so you can never be sure that your selection will survive all the commands in your script.
For example, instead of :

select $newLctr $lctrDup ;
parent ;

you can just do this:

parent $newLctr $lctrDup ;

Only one line, and you don’t change your selection. Most people will tell you that’s the way to go.
If you avoid selection, then that means you also need to avoid pickwalking and those kind of navigation tools. Instead of:

select $lctrDup ;
pickWalk -direction down ;
delete ;

Just in general this is bad because you’re almost doing it blind. If you had anything else in your selection, you would end up deleting that also, or if the chidren weren’t organized properly, you might end up deleting the wrong thing. Instead, this seems a little more complicated, but it’s much better:

string $shapes[] = `listRelatives -c -s $lctrDup`;
delete $shapes;

the first line will list all the shapes of $lctrDup. listRelatives that are (-c) children and (-s) shapes of $lctrDup. Then delete them. This ensures that if there’s another transform below this node, it won’t get deleted by accident (because it’s not a shape) and that if the object has multiple shapes that they all get deleted.

My other suggestion makes life a little more difficult as well, but it will make for a more solid script. For your UI elements, rather than hardcoding names, use variables for them as well. The reason for this, is that UI objects are like any other object in maya. They exist in a heirarchy, and they’re not allowed to have duplicate names. So if you create a checkbox called cb1, but there’s already a cb1, then you’re checkbox might be renamed cb2. Then when you go to query it, you’ll actually be querying this other checkbox created by whoever.
but if you do
string $cb1 = `checkbox`;
then you know the variable $cb1 is exactly what you need.
Where this gets confusing and difficult, is that you have to pass these variable around to the different procedures that handle your UI.

For example, if you’ve got a proc that clears fields, called by a button, then you need to get the textScrollList names out of the UI and into the proc, because the names are arbitrary now.
for example:

//you’ve got these lists
textScrollList tsl1;
textScrollList tsl2;
//and this button
button -c “clearFields”;

//this is the proc it calls:
global proc clearFields (){
textScrollList -e -ra tsl1;
textScrollList -e -ra tsl2;
}

Instead, you want to do this:

//you’ve got these lists, put them in variables
string $tsl1 = `textScrollList`;
string $tsl2 = `textScrollList`;
//this button will call the procedure and pass the variables
button -c (“clearFields “+$tsl1+” “+$tsl2);

//call this proc and pass the scrollList names as arguments.
global proc rwlOCClearFields (string $tsl1, string $tsl2){
textScrollList -e -ra $tsl1;
textScrollList -e -ra $tsl2;
}

Does that make sense? It’s a little confusing, and actually this last part is something I just started doing since I was scolded by the guys at work. Chances are you’re not going to get into much trouble by hardcoding names, but this is just safer and cleaner.

Share Button
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *