A Few Fundamental MEL Commands Everyone Should Know

Here are a couple of useful MEL commands/operators that you'll end up using in a lot of the stuff you write.

continue ;
Skips one iteration of a loop.

break ;
Stops the loop and continues script where the loop ends.

Warning("You messed up, but it isn't too bad so I'll keep going.") ;
Warnings alert the user that something is awry, but it's not a deal breaker.

Error("You messed up bad, I need to quit now.") ;
The error command will stop a script in it's tracks, ending everything.

return ;
Ends a procedure/function/method, but not the entire script. Continues on where the procedure ends. Can also be used to return a value (return $myString).

CGSutra has a great article going into more depth on these and a lot more of the fundamental MEL concepts. Check it out here.

Understanding Recursion

Always remember...

"In order to understand recursion, you must first understand recursion."

:-)

Repost: Some lesser-known truths about programming

I saw this on Reddit this morning and thought some of you may like to read it. Find the link to the full article on http://dotmac.rationalmind.net below.

My experience as a programmer has taught me a few things about writing software. Here are some things that people might find surprising about writing code:

A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960′s have consistently shown this. A bad programmer is not just unproductive – he will not only not get any work done, but create a lot of work and headaches for others to fix.

Read the full article here: http://dotmac.rationalmind.net/2010/08/some-lesser-known-truths-about-programming/

Using White Space To Your Advantage

A really helpful hint when scripting is to know how to leverage white-space in your code. What this means is that certain languages will allow a lot of flexibility in the way your code is laid out that can make it much easier to read and edit. Take this example:

string $fileArray[] = {"C:/_Maya/temp/file_0001.ma","C:/_Maya/temp/file_0002.ma","C:/_Maya/temp/file_0003.ma","C:/_Maya/temp/file_0004.ma","C:/_Maya/temp/file_0005.ma","C:/_Maya/temp/file_0006.ma","C:/_Maya/temp/file_0007.ma","C:/_Maya/temp/file_0008.ma","C:/_Maya/temp/file_0009.ma","C:/_Maya/temp/file_0010.ma","C:/_Maya/temp/file_0011.ma","C:/_Maya/temp/file_0012.ma","C:/_Maya/temp/file_0013.ma","C:/_Maya/temp/file_0014.ma","C:/_Maya/temp/file_0015.ma","C:/_Maya/temp/file_0016.ma","C:/_Maya/temp/file_0017.ma","C:/_Maya/temp/file_0018.ma","C:/_Maya/temp/file_0019.ma","C:/_Maya/temp/file_0020.ma"} ;

The code above shows a string array containing twenty Maya Ascii files. It's straight forward, but a little difficult to read due to it all being condensed. If you need to make edits to one of the file names or add some into the list somewhere specific it can be a bit annoying finding the right spot. Let's use white space to help us with this.

string $fileArray[] = {
 "C:/_Maya/temp/file_0001.ma",
 "C:/_Maya/temp/file_0002.ma",
 "C:/_Maya/temp/file_0003.ma",
 "C:/_Maya/temp/file_0004.ma",
 "C:/_Maya/temp/file_0005.ma",
 "C:/_Maya/temp/file_0006.ma",
 "C:/_Maya/temp/file_0007.ma",
 "C:/_Maya/temp/file_0008.ma",
 "C:/_Maya/temp/file_0009.ma",
 "C:/_Maya/temp/file_0010.ma",
 "C:/_Maya/temp/file_0011.ma",
 "C:/_Maya/temp/file_0012.ma",
 "C:/_Maya/temp/file_0013.ma",
 "C:/_Maya/temp/file_0014.ma",
 "C:/_Maya/temp/file_0015.ma",
 "C:/_Maya/temp/file_0016.ma",
 "C:/_Maya/temp/file_0017.ma",
 "C:/_Maya/temp/file_0018.ma",
 "C:/_Maya/temp/file_0019.ma",
 "C:/_Maya/temp/file_0020.ma"
} ;

Cool huh? MEL and most languages will allow you to do this and many other things with white space in your code to really space it out evenly and neatly so it's easy for you and anyone else interacting with your scripts to use and read. Practice ways of using this trick to make your code more awesome!

Maya Scripting: "Should I Learn MEL Or Python?"

The question I get asked most often by people just getting into scripting in Maya is, "Should I learn MEL first or go right to Python?". It's a legitimate question and at this stage in the lives of both languages, it has merit. The reality is you need to learn both...but which one first? And why learn MEL when Python is there? Maya's embedded language has been around for ages and is notoriously weak and difficult to use in certain areas. As Python slithers it's way deeper and deeper into our pipelines, many believe MEL will be phased out completely in coming years. Seeings how it will inevitably become more and more prevalent in 3D applications and is not Maya-specific, isn't it only logical to not bother with Maya's aging language and go right to Python? All signs seem to point that way, but I don't agree with this philosophy and I'll explain why.

Python and Mel - Both Badass, (though one is insane)

My answer is almost always the same when people ask me this question: First, learn enough MEL for it to be useful and help you work, then start to learn Python along side it.

If you are new to programming and scripting, you are unlikely to learn enough Python quickly enough for it to be of any use to you. Python is definitely more powerful, gives you more control, and is really more fun to use in the end...BUT...it's more difficult. There are more rules, more things involved with getting it working properly and generally just more things you need to know in order to use and learn it. You'll need to learn the basics of installing libraries, having paths set up correctly, using environment variables, linking modules, and all sorts of steps just to get it doing what you want. Of course you can just go in there and start giving it Maya commands, but at that point you're not taking advantage of it's abilities and may as well use MEL. That brings me to my point.

With MEL, you can start doing things almost instantly even with little to no knowledge of how it works. Compared to some languages it's relatively easy to pick up and get going with and it exists in Maya already with great documentation. To get started, you can watch your Script Editor to see what certain commands are doing and how they work. Run a tool or do something in Maya and watch what kind of code it spits out in the Script Editor. Copy and paste that code and start changing things around to make your own little scripts and buttons. Learning the basics of variables, functions and syntax are all easy using the tutorials in the Maya documentation. All in all, within a couple of hours you can be writing small snippets of code that will actually be speeding up your work-flow. It's not to say you can't do the same with Python if you're a fast learner, but generally speaking you'll be up and running with MEL a lot quicker.

Once you're cruising with MEL and you're putting it good use...that is when I'd recommend diving into some Python and beginning to learn how it works. At the end of the day you can (and will) use both in various situations, but I'd never suggest to anyone to NOT learn how to script in MEL. Whether it be needing to clean up a co-workers code, make changes to a script, write a Maya GUI, or write a script in an older version of Maya that doesn't have Python...there are plenty of reasons you should not skip MEL.

All that being said, PyMEL combines the best of both and is my drug of choice at the moment. Learn them all so that you can make your own call on what's best. :)

To Script, or Not To Script

It seems to happen all of the time. One of those situations arise where you have a task to accomplish that you know will be simple as pie to script. There's a big smile on your face as you finish writing it, nod approvingly at it's beauty and let it run it's course. Relaxing back into your seat, you bask in the glory of having once again thwarted destinies vain attempts to make you work.

But, this was one of those not-so-rare occasions where the task at hand would have taken you only a few minutes longer, or in some cases less time to accomplish than writing the code to make it work. You were torn for a moment, "Should I just do it? I'll never have to do this ever again and scripting it will take just as long as doing it manually". To script, or not to script?

If you're reading this blog, you're most likely in the demographic that would answer that question easily. Script it! Even though this is a specific case and the actual code will most likely never get used again verbatim, you still gain a lot from scripting tasks like this. Here is why:

Within every task given us is a problem to solve. Some are easier than others, some are difficult, and some may not seem like problems at all. The fact is though that as simple or as direct as a task may seem there is always some level of problem solving involved with it and as it is with any other skill, practice and repetition always make you better. If you approach every task like a challenge and use it to level up in some way, it makes even the simplest script worth writing!

What can you do to make a simple, easy-to-write script more challenging? Some ideas:

• Write it in another language or application
  
• Use commands or functions you've never used before
• Make it more robust, so that is becomes useful in other situations
• Write it in as few lines of code as possible (don't count comments or white space lines)

All of these things will definitely make you better and are usually fun. As long as your skills are improving, you're getting more benefit from scripting a simple one-off task then if you were to just do it manually. Your gaining skills, experience, challenging yourself, and inevitably getting better so that you'll be more apt to tackle a difficult assignment when it comes knocking.

In our line of work, the ones who stop learning are the ones that are left behind. Always seek out new ways to improve your skill-set and keep getting better!

Lightbot 2.0 - Free Flash Game Teaches Programming Logic

I stumbled upon this great little gem on Reddit the other day: it's a free flash game that teaches you how to solve puzzles using programming style logic. You use functions, recursion and other programming tools and tricks to control a little man trying to solve his way through puzzles. It's brilliantly designed and has already helped me get a colleague of mine starting to think like a scripter.


"Light-bot is back, more puzzling than ever! Use programmer-style logic to tell the bot how to light up all the blue tiles! Functions, conditionals, recursion, expert levels- many different features for new and old players."

It's called Lightbot 2.0 and can be found here: http://www.kongregate.com/games/Coolio_Niato/lighbot-2-0

Confirmations And You

I got into an interesting debate with a colleague last year about the use of confirmations in tool writing. He was passionately of the mind that the user should be solely responsible for clicking a button, and if they didn't mean to click it then they should face the consequences. Now, most people will agree that there are few tools in our pipelines that will cause issues if a button is pressed when the user isn't ready, it's usually no big deal. There are some though. One example would be sending a shot to be rendered.

Let's look at an example where the user has a button on a shelf that will send their currently open scene to be rendered, on the farm or elsewhere. As soon as he or she clicks the "Render" button, the shot is saved, archived, render is set up, and it's sent to the farm to be magiked into a video. If the shot is ready to be rendered then this is certainly a great solution. One simple click and they're off to play golf. However, what if it's going on the dark side of an 18 hour shift and the shelf buttons have become blurry enough that the user clicks the button by mistake? Let's look at why this is an annoyance in production.

First off, there is now an asset being created that is of no real use. The user will to spend time alerting the powers that be that they need not use this asset for anything and it should be deleted when it's finished being comped. Next, the powers that be must track down this asset and delete it so it doesn't get confused with a proper deliverable of any sort. On top of all this, the process of rendering and comping this shot will inevitably take up resources that would be better served doing anything but an irrelevant task. In the big picture it's not a huge problem by anyone's standards, but it could have all been avoided by requiring one extra click.

I won't argue that there is a time and place for a confirmation box, but when the potential for screwing up is wasting people's time and resources then I think it's right to use one. A tired animator or rigger can save themselves and others time and money by being given a chance to say "No!".

Today I was coding something and a similar situation occured where I was making a decision to include a confirmation or not. This is how I was reminded of the passionate fellow who argued never to use them. I laughed for a minute, then added my confirm dialog, with gusto.

Thoughts? To confirm, or not to confirm?

MEL Scripting Tutorial: Using The Tokenize Command

This MEL scripting tutorial will give you an in-depth look into how to use the tokenize command. Tokenize is used for taking a string and breaking it up into a number of parts so they may be used on their own. It's one of the most commonly used commands in the language and a strong knowledge of how to use it will help anyone write better procedures. This tutorial assumes a basic knowledge of running a MEL script in Maya.

Skill Level: Beginner

The tokenize MEL command is incredibly useful and very easy to use. You'll find once you know how it works and what it does, you'll end up using it in almost every script you write in one way or another. What tokenize does is essentially break a string up into different parts based on a splitter character, and return them into an empty string array. Why would you need to break up a string into different parts? There are many reasons you may need to do this. An example being let's say you're string is an Object.Attr and you need to parse out just the attribute, or perhaps just the object. You can use tokenize to split them up into their own strings. Maybe you have a path to a file and you want to tokenize it by slashes. Or, you have a comma-separated line of text and you want to split each field into an array. There are countless ways to use it and I think you'll find once you know how to use it, you'll use it constantly. Let's look at some examples:

"myObject.translateX" would tokenize into "myObject" and "translateX". Here's how we would do that:

// Here is our string, in the variable $myString
string $myString = "myObject.translateX" ;

// First we create an empty string array, to play our "parts" in.
string $buffer[] ;

// Now we'll tokenize our string and put the tokens into $buffer
tokenize $myString "." $buffer ;

// Notice the arguments:  string, splitter, array.

// Now if we print out $buffer we'll get:
print $buffer ;
// Result:
// myObject
// translateX

Note: Because we used the "." as the splitter, it is now gone from any return strings.

Besides just splitting a string up into different parts, tokenize will also return the number of parts your string was split up into. This can be useful for many reasons as well. Let's say you have a string that looks like this: "myObject,myAttribute,myValue,myMultiplier,myComment". This could be a comma-separated text file you're reading from, or data from a database table. So now for whatever reason let's say we want to know how many comma-separated fields are in this line of text. We can use tokenize for that as well.

// This is the original string
string $myLine = "myObject,myAttribute,myValue,myMultiplier,myComment" ;

// Tokenize it, but save the return of tokenize into an INT variable
string $buffer[] ;
int $numTokens = `tokenize $myLine "," $buffer` ;

print $numTokens ;
// Result: 5

print $buffer ;
// Result:
// myObject
// myAttribute
// myValue
// myMultiplier
// myComment

Now we have both our tokens saved into $buffer and the number of tokens saved into $numTokens. Now that you've got your 5 fields into your $buffer array, you can now define them properly.

// Define Vars
string $object = $buffer[0] ;
string $attribute = $buffer[1] ;
string $value = $buffer[2] ;
string $multiplier = $buffer[3] ;
string $comment = $buffer[4] ;

Note: Remember MEL arrays are "zero-based" so the first index of $buffer is going to be zero.

You may notice that I've defined $value and $multiplier as strings in the above example. Since they are coming from a comma-separated string and then tokenized into a string array they are technically strings. However, since they are most likely floats I can define them as such when I take them out of $buffer. You will get a Warning in Maya when you do this, but it won't stop your script. Same example but with redefined vars below:

// Define Vars, But Assign To Float
string $object = $buffer[0] ;
string $attribute = $buffer[1] ;
float $value = $buffer[2] ;
float $multiplier = $buffer[3] ;
string $comment = $buffer[4] ;

Now we've got five values that we took from our comma-separated text line, all in their own variables with no commas. Very useful! Now, what if we need to save this data out again? How do you form a line again with all these variables? The practical way would be to do this:

// Redefine CSV String
string $myNewLine = ($object+","+$attribute+","+$value+","+$multiplier+","+$comment) ;

This will put all your variables into a new, single string variable. But, if you've done this sort of thing you may have noticed that this will produce an error in MEL, because we're attempting to concatenate two different types of variables a string. In MEL, we can't combine floats and strings together into a string. (Thank you Python!) So, the alternative is to just use our original string array from your tokenize, along with the MEL command: stringArrayToString.

// Redefine CSV String
string $newLine = stringArrayToString($buffer, ",") ;

That will reassemble our string array into a single line again, and use the comma as the splitter. You can use anything you want as a splitter as long as it's a valid character.

Play around with tokenize a bit and see what you can come up with. It's one of the MEL commands I use the most and getting comfortable with how it works and how to use it will improve your scripting a lot!

Looking for more tutorials? Check out Script Swell's Technical Artist Tutorials page.

Python: Learn Python via Google

Google has put up a free video collection of Python classes. Another great resource on the web for learning how to code in the coolest language ever. :)

From Google Code:

"Welcome to Google's Python Class -- this is a free class for people with a little bit of programming experience who want to learn Python. The class includes written materials, lecture videos, and lots of code exercises to practice Python coding. These materials are used within Google to introduce Python to people who have just a little programming experience. The first exercises work on basic Python concepts like strings and lists, building up to the later exercises which are full programs dealing with text files, processes, and http connections. The class is geared for people who have a little bit of programming experience in some language, enough to know what a "variable" or "if statement" is. Beyond that, you do not need to be an expert programmer to use this material."

Very cool if you're looking to learn some Python and have been waiting for an opportunity.

http://code.google.com/edu/languages/google-python-class/

Efficient Scripting In MEL - Part II

TL;DR - Make your own MEL procedures that are better versions of existing commands if it will speed up your workflow. Some of the default MEL commands are lacking.

This next article is a bit more about scripting and programming in general and less about MEL specifically. It's about using procedures to take care of basic functions in order to speed up tasks you perform regularly in your scripts.

Let say for example you want to print out some data. In MEL and most languages I've programmed with, when you print or echo something it will not create a new line the next time you print. So if you print the phrase "Hello World" twice in a row, it will look like this: "HelloWorldHelloWorld".

So, a quick and easy way to do this is to add a newline. To do this in MEL, you use the characters "\n". So your print statement looks like this:

print "Hello World\n" ;
print "Hello World\n" ;
// Result:
// Hello World
// Hello World
//
// Without \n you'll get:
// Result: HelloWorldHelloWorld

When you need to add a newline character onto every single thing you print it can get time-consuming. Especially when you need to concatenate it with a variable which in turn you then need to add parenthesis around your entire statement, it's very annoying. We know every millisecond counts right? So let's save ourselves some time and build a custom print statement.

// **********************************************************
// Faster way to print
global proc jgPrint (string $print) {
print ($print+"\n") ;
}

// Now I can simply call:
jgPrint "Hello World!" ;

// And it adds the newline for me.

Slightly unrelated, but another benefit to this method is that you can print a concatenated int or float with a string argument using this method which you can't with a normal print statement.

So there we've created a small procedure that will save us lots of time down the road. Essentially we're creating tools to help perform tasks faster than we could without them, and filling in gaps with tools that the default language doesn't provide or where the default commands are lacking in one way or another.

There are an infinite number of ways you can use these. I'm not going to provide all the code for you since it's a good learning experience to write these on your own...but here are a couple examples of some procs I use on a daily basis.

• Append A Single String Argument To A String Array
• Read A Text File And Return It As A String Array
• Create A Set Driven Key
• Make An Attribute On An Object
• Edit An Attribute's Values
• Pass An Array Into A String Argument
  

These are all things that already have built-in Maya commands but are either unintuitive to use or are just plain annoying and slow. There are no rules that say you need to do it the "right" way or the way Maya wants you to. If you can get the job done faster by making your own commands or procedures than go for it!

Efficient Scripting In MEL - Part I

TL;DR - The less lines in your code the better, and use argument passing tricks whenever possible. Keep it clean!

After talking to a coworker today about how it'd be cool to try and rewrite a script he made in only ten lines of code...I thought it'd be good to to write a short post about how to increase efficiency in your MEL scripting. By efficiency, I mean saving yourself time both in the creation and the editing of your code by condensing your scripts into shorter blocks and not using more lines than you need to. I've found that it helps me a lot in the long term when my scripts are much shorter and easier to edit. On top of that, it's just way more awesome to write a script in ten lines that does the exact same thing as one that does it in fifty.

We'll start with some simple examples:

Let's start with a FOR Loop. Normally you'd setup a FOR loop like this:

for($i = 0; $i < 10; $i++) {
   print $i ;
}

Or like this..

for($item in $myArray){
 print $item ;
}

But why not condense it? Let's put that three lines of code into one.

for($item in $myArray) print $item

It doesn't seem like much of a gain, but in actuality you've cut the size by 66%.

Now let's add an IF statement to this line..

for($item in $myArray) if($item == "myItem") print $item

Still one line of code but you've got another check in there.

Another example, check if an object exists, error out if not.

int $exists = `objExists $myObject` ;
if(!$exists) {
 error "Object doesn't exist." ;
}

// Four lines?  Bleh.  Let's bring it down a few..

if(!`objExists $myObject`) error "Object doesn't exist." ;

Some more error check examples:

if(!`filetest -f $pathToFile`) error "File does not exist." ;
//
if(!`endsWith $mayaFile ".mb"` && !`endsWith $mayaFile ".ma"`)  error "File is not a Maya file." ;
//

This helps a lot when you've got a procedure that has a lot of error checking. Don't allow your checks to steal all of your screen real estate. Condense them into one line and celebrate your awesomeness with a frosty pint.

What about when you need to get some data from a textField or any other control? Assuming it returns a string, and not a string array. You condense the following:

string $myText = `textField -query -text myTextField` ;
print $myText ;

// Pffffff.

print `textField -query -text myTextField` ;

// Much better!

So this is a short, basic look into how to do this sort of stuff. I find that although making your code cleaner and nicer is probably in the top ten nerdiest things possible, you'll appreciate it someday when you look step back and look at your script and actually smile at how cool it looks. It is after all an art form. :)

MEL: Run A Command Line Program Through Maya

Ever needed to run an executable/command line app from Maya? You can use the "system" command to do this.

system("echo \"Hello World!\"") ;
// Result: "Hello World!"

So, if you need to use your maya data to run through an executable for any reason, you can use the system command the same as you would with any Maya procedure.

Random Example:

string $numVerts = "2023" ; // Number of vertices on a mesh
string $mesh = "myMesh" ; // Mesh Name
system("C:/myAppDirectory/mySpecialVertApp "+$numVerts+" "+$mesh) ;

This allows you to gather data in a Maya scene and send it directly to your executable without needing to save it out first. It's a bit slower than running it normally, but barely noticeable.

MEL: Source A Script With A Variable

Maya's MEL script command "source" will not let you source a path through a variable. Example, the following will NOT work.

string $myScriptPath = "C:/myScript.mel" ;
source $myScriptPath ;

It will produce a syntax error. So, how do we do it then? One method is by using the "eval" command and putting the source command into the string itself and slashing out the quotes.

string $command = "source \"C:/script.mel\" ;" ;
eval $command ;

"eval" will run the string as a command, thus sourcing it and your script/variable.

Another option here is to create your own proc, let's call it betterSource() ;

global proc betterSource (string $script) {

     string $command = "source \""+$script+"\"";
     eval $command ;

}

// Now you can run:

string $path = "C:/script.mel" ;
betterSource $path ;

Either way works and one is not necessarily better than the other.