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

MEL Script: Print Toolbox

One of the best things about scripting is that it gives you the ability to design your own tools that compliment and speed up your workflow. When I'm using Maya I am in constant need of information from my scene. Whether I'm debugging a broken file, preparing scenes for delivery to a client, or setting up a rig, I always need little morsels of data from the scene to do this. To help me with this I wrote this simple little toolbox that let's me get a lot of the data in just a click.

It's a small floating gui with a half-dozen buttons that let you print out some very useful information.

Features:

• Print Transform Values: Prints out basic transform values in the script editor for everything selected in an easy to read format.
• Print SDK Count: Prints the number of set driven keys in your scene.
• Print Joint Count: Prints the number of joints in your scene.
• Print Selection Count: Tells you how many objects are selected.
• Print All Nodes Count: Gives you the total number of nodes in your scene.
• Print Selected To Array: This will print out your selected objects into an array that you can copy from the script editor.

There are of course an enormous number of random things that you may want to print out at any given time but these are the ones that I need to use on a day to day basis. Perhaps in an updated version I'll add the ability to customize which buttons appear and allow you to print out a load of other things. For now, enjoy!

Get the Print Toolbox here: jgPrintToolbox.mel

As always feedback and comments are welcome. If you're just getting into MEL scripting take a look at the script itself to see how it's working.

Shout Out: Animators Resource

Animators Resource is a blog dedicated to all things animation. It features links to helpful sites, videos, behind-the-scenes info on upcoming animated films, links to useful animation tools and a lot more awesome content. It's updated regularly by a group of dedicated animators and is a great resource for both the student and the professional.

http://animatorsresource.blogspot.com/

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 Script: Makes A Quick Set Driven Key

This is a tool I use from time to time that enables me to quickly bridge a set driven key between two objects/attributes that I can then edit. It's much faster for me to grab a node and edit a curve into the values I want than it is to use Maya's default Set Driven Key creation GUI or even the default MEL commands. This lets me quickly create an SDK and edit without all the fuss. It's not something I'd use when creating Set Driven Keys on a massive scale, like in the case of an entire rig...but instead for when I just need a couple of them here and there.

The 'GET' button will grab the selected attribute from the channel box, or you can type in your 'object.attribute' manually. Hit the 'Make SDK' button to create. Sourcing the script will launch the GUI.

Get it for free here: jgMakeSimpleSDK.mel