MEL For Maya

MEL For Maya

MEL For Maya

After the unexpected popularity of my Python For Maya programming course, I had a lot of requests to do a course for MEL.

So here it is, FREE for anyone to access. There’s over an hour of content that goes over the basics of everything you need to know in MEL. It’s not as in depth as the 8 hour Python course, but it should get you up and running with MEL pretty quickly.

Introduction To MEL

In this first video, we are introduced to MEL and compare it Maya’s other programming languages. We also learn how to use the script editor and write our very first, simple script.


Learn Python

If you're interested in learning more about Python, why not sign up for my course here?

This course takes you from learning the fundamentals of Python, to creating tools with advanced user interfaces, all while creating projects you can use immediately.
It will teach you many of the skills necessary to create tools like the ones in this article.

With over 700 students in its' first week, including artists from major studios, it is sure to provide valuable knowledge to everyone.

Python For Maya: Artist Friendly Programming - $70 $90

If you sign up from this link, it will save you $20 off the retail price using the coupon code: DGOVILCOM

Learning By Doing

Maya uses MEL for pretty much everything we interact with. It also tells us every MEL command it runs.

We can use that to learn how to script by using Maya like we normally would, and in this video I teach you to take those commands, how to understand them and finally how to modify them to do what you want.


In this video we learn about using variables. Variables allow us to give names to our data to refer to it easily. In this video we learn about the different types of variables in Maya and how we can use them.


Comments are really useful while coding, because they let us leave notes to ourselves for the future. That way if we come back to code tomorrow, or in a few weeks or even many years, it’s easy to pickup where we left of.

If Statements

In this video, we’ll be going over how to make our code smarter by being able to deal with different situations. I’ll be going over the If/Else statement, the ternary operator and switch cases.


In this video we’ll learn how to use Loops in MEL to iterate over ranges of values or arrays. I’ll be going over the For loop, For Each, While and Do While loops.

Putting It All Together

Now that we’ve learned a lot of the basic skills we need to write a MEL script, let’s put everything we’ve learned together to make a script. Our script will rig any selected objects as a prop for animation.


Probably the biggest tentpole of programming, functions let us group our code together into reusable chunks.

Saving Scripts and Scopes

Now that we’ve written some code that we want to reuse, we’ll probably want to save it for use later. In this video we’ll go over how to save your scripts and then how to source them.

This naturally brings us to another issue called scopes and we’ll go over the access scopes of functions and variables, and how to best use the global keyword.

User Interfaces

Making command line scripts is one thing, but everyone loves to use pretty interfaces! In this video, I’ll be going over how to make a simple window with a few buttons.

External Editors

We’ll quickly be outgrowing the Maya script editor. It’s limited and if Maya crashes, we lose all our work. Instead lets go over how to setup an external code editor that will make for a much nicer coding experience.

Visual Studio Code is a free, multi-platform editor from Microsoft and we’ll learn how to set it up to edit MEL.

Mixing Python and MEL

Sometimes you need to mix languages, because what you’re trying to do is either easier in the other language, or just straight up not possible in your current language. I’ll be going over how to run Python code from MEL, and how to execute MEL code from within Python.


If you’ve made it this far, I’d like to thank you for watching! Even if you just watched one video, thank you for giving it the time.

If you feel like you want to learn more about programming, check out my Python for Maya course. I have thousands of students in the first two months of it being up, with artists from major film and games studios enrolled as well.

Chasing Efficiency In Programming

Chasing Efficiency In Programming

There’s something I’ve been trying to achieve this year. Really, it’s something we all try and achieve, but it’s something I’ve been giving more thought to lately. Efficiency.

That’s dumb though, who tries to not be efficient? Why would you act against your own interests of time? Well, the answer I find is, a lot of us are less efficient than we can be. Specifically today I would talk as a software developer and efficiency in programming.

So let’s set up a scenario. We’ve just hired two new developers who are completely equal in skill. Let’s call them Linda and Tina. We give them similar tasks. Linda gets her task done in a single day, whereas Tina takes two days to finish her task. Who was more efficient? It’s not such a simple answer.

In the pursuit of speed, Linda may have inadvertently been the less efficient of the two. Let’s go over why.

“There Was No Time For Clean Code”

This is an obvious one. Just because you’re faster doesn’t mean you write clean code.

Often a lot of the code reviews I give at work end up being caused by the developer trying to get the task done as quickly as possible. Sometimes this is valid, sometimes you do really need to just get it out as soon as possible, but at what cost?

Common issues are blocks of code that have been copied all over the place, or hard-coding values in place when it’s better to have done it programmatically. Sometimes it’s just variable names that make no sense or dumping your code inside existing code without stopping to do minor refactors.

Again, this can be valid sometimes. Sometimes you do not have the time to write good code, but instead ship whatever is working. It does make a lot of people happy too even if there aren’t strict deadlines. You have happy managers for meeting targets ahead of schedule and it makes the developer look good.

That is, till it comes time to make changes later on. An edge case has come up, that could have been caught if your code wasn’t using hardcoded values everywhere. You go into your old code and you can’t understand what your variables mean. You change one block of code and forget you have to change it in 5 other places that you copied it around to.

This is where I think code review really helps.

It forces the developer to slow down to be vetted and to have their code on display, and it forces them to reason about their design choices. This means they’re more likely to keep their code tidy for fear of being called out for it and having to explain it. It means they get an outsiders perspective on their design, and it forces them to take a step back and see the forest for the trees. All too often we get lost in the code itself and forget how it all relates together.

This is not to say that you should leave your developers in fear of code reviews, but it’s indeed a scary process for new developers (and some veteran devs). It’s putting your hard work on display and asking to be torn apart.

I think a successful code review process can be constructive, critical, and more importantly teach  the developers to be better. It changes from dreading the process to looking forward to it because you take pride in your work, and want it to be as good as possible.

It also is the place I see my favorite excuse…

“It’s Just Throw Away Code”

This is my pet peeve. Seriously. Don’t put code into production and then claim it was throwaway code when I ask you about it.
This is something people who want to be fast always hide behind. “I’ll just change it later when I get time”

Firstly, You won’t get time. Write it well the first time or we’ll be paying the price later on.

Secondly, why would you double your own work? Why would you write code that you now have to maintain if you’re just going to rewrite it again. You should never be aiming to rewrite your code while you’re writing it to begin with. That’s just daft.

Yes, you should have reasonable layers of abstraction so that you can rewrite it if you need to, but that’s different. That’s good API design, whereas hiding behind ‘throwaway code’ is just being lazy.

Speaking of API design, it is something that I think more developers should be taught because I often hear this…

Sometimes it’s good to just take a step back from the code and look at it in context.

“This Will Only Be Used By My GUI (or my library)”

A lot of the code review comments I give on user interfaces is that they need to decouple their logic from their interface. The most common response is that it won’t ever be used outside their user interface.

The problem is, if someone finds your tool or application useful, they will want to leverage it and often that means your pretty interface won’t be part of it. So now you have to spend all this time refactoring your code to decouple it from the user interface.

Properly decoupling a GUI and the underlying logic does require some time and thought to do cleanly. It’s not as trivial as it sounds and it requires the developer to put on their software architect hat and architect their design rather than focus on pushing out a feature.

Again though, this is something that a little extra time before hand could have saved you in the long run. Making sure your code can be used without any interface, or indeed, making sure your code can be called as a library for other projects is the hallmark of efficient development.

The alternative is making a new library or re-implementing your logic for every project. At the very least it requires at least one rewrite of something you could have done from the get go.

Designing your code like an API isn’t easy though and you really do have to think about other people. It requires a lot of care and it goes hand in hand with my next point…

“I Don’t Have Time To Write Documentation”

This is a huge fallacy. You always have time to write documentation, but I think it comes down to people thinking of documentation as needing to be this giant, in depth bible of the code. Of course, the more in depth you can go the better, but all you really need at a minimum is to add a docstring to your functions and write a ReadMe.

How does this make you efficient though? Well the amount of time you have to spend explaining your code to people and helping them with issues, could easily be spent writing documentation instead.

Seriously, if all you did was write a README.MD file with some usage examples, you would be miles ahead of so many repos online. That’s enough for a lot of libraries to be picked up by people and used. They can figure out quite a bit from just a few example snippets and it cuts down on how many questions you get asked.

Don’t stop there though. Document your functions. Add docstrings, explain your parameters and put comments in your code. That will dramatically cut the amount of time you have to spend explaining your code to someone else.

More importantly it will cut the time you need to spend re-familiarizing yourself with your own code when you eventually need to get back into it. All that time spent going, “I wonder how this worked…”, could be cut completely because you read your thought process from when you wrote it.

It doesn’t even take that much effort. IDE’s like PyCharm will quickly fill out your docstrings for you. Plus you get advantages like basically having a lot of your documentation done by just doing that. Tools like Sphinx can simply extract your docstrings and make documentation out of it.

Time spent now is lots of time saved later. Not just for you, but everyone using your code. Those people may even be inclined to help you maintain your code, but I often see this one..


Documentation doesn’t need to be a massive bible. It can be as simple as a Readme, docstrings and comments.

“Writing Tests is Hard”

Well you know what is hard too? Having your code do the wrong thing in production, wasting lots of man hours and having to answer to your manager how this happened. Write Tests.

Ideally you’d have as much coverage as possible in your tests, but even a few tests can dramatically cut the error rate of new commits to your code. This in turn can make it easier for people to contribute to your code because you’re not spending as much time vetting their code, and they’re not as afraid of breaking something important.

Lastly though…

“It’s Critical and Needs To Be Done Now”

This is completely valid. Sometimes you don’t have time to be meticulous. Sometimes you just need to get it now and have a task list piling up that needs to be addressed right away. That’s the reality of the world of a developer and sometimes you can’t escape it.

I definitely am not writing perfectly clean code that can be reused. I too often forget to document my code and I’ve only recently started embracing tests in my code. That said, I think it’s important to try and aim to be efficient, because that task list that’s piling up will only keep piling up otherwise. If 10 minutes spent here can save me 30 minutes tomorrow, then that’s definitely worth being a little slower. If a whole day can save me a week of time over the course of a year, that’s time well spent.

So write cleaner code, write documentation, write tests and make everyone’s lives easier. If you’re a manager, encourage your developers to spend time to do it right and give them that liberty.

Always try and be as efficient as you can be, even if that means you’re not the fastest. You’ll be the turtle in this race and come out ahead.

As always, here’s a relevant XKCD (

Pin It on Pinterest