Topics by tag:
Recently published articles by Dave G:
Just got my invite to the Mac Mari beta and excited to be running this app – on even my 17” MacBook Pro:
Can’t wait to get it running on new Mac Pro.
I just spent the last half hour trying to find a conflict with V-Ray Tuner and someone else’s MEL script for Maya. As soon as I opened theirs, it reminded me of the main thing you should do when learning to script: avoid common words for global variables. If you open open script that relies on $text as a global variable and open another that uses the same global variable, they are both going to break. This script I looked at was peppered with global variables with cosmically stupid names like $text, $parent, $node and $p. I’m embarrassed to say that I had $obj as a global variable in V-Ray Tuner, so I’ll need to change that since it’s a common one.
If you’re on OS X or Linux and want to see all your global variables in a script file, this command will show you them:
cat /path/to/MELfile.mel | grep global | grep -o -i '\$[A-Z]*' | sort | uniq
That will spit out something like this:
I’m increasingly trying to get into the habit of appending some two-character nonsense onto the end of dumbly-named global variables so, instead of $node, it’s $nodeYo, which is much less likely to exist elsewhere because no one else codes in Jive talk.
Can you dig it, home?
2 notes | Permalink
I am just moving my work to a new Lacie 2big Thunderbolt enclosure and wanted to save myself annoying task of migrating all my existing work to link to the new disk in place of my old one. There are nice utilities like FileTextureManager for Maya and Nuke has a find/replace that do this on a per-scene basis but this seemed slow since I would be doing the exact same replacement for all future files.
So I made an Automator workflow that reads plain text files and substitutes my “dullard/WORK_mbp” path in the file with “lackey/WORK” and then creates a new file next to the old one so nothing is clobbered. Since Maya ASCII and Nuke files are plain text, the script can use the Unix utils awk and sed as if it were just working on a big (and quite boring) essay.
See it in action:
Grab the Automator workflow here. Obviously, you’ll need to edit the workflow in Automator to substitute your paths instead of mine:
The text between the % are the find and replace terms. The script doesn’t overwrite any files but just for the sake of legalese, it comes with no guarantees.
So, I have this shell script “hammeroutimages” that sends an image to Nuke for batch processing with all my .cube LUTs for a quick image treatment gallery and I have been wanting to make it an Automator action. But then I thought “I have all these one-off shell things that I do on files—why not just make the command itself a variable with input?” So I found out how to do that with a combination of existing Automator know-how with this handy tip, which shows how to pass multiple variables to an Automator workflow for use in a shell script. And I made this bad boy:
What does it do? Anything you throw at it, actually:
If you want an explanation of how it works, read the linked post above. Basically, it takes your text input and assigns it to variable $1 (this is the command) and variable $2 is your file so it sends those to echo and makes a shell script that the Terminal then opens it in Terminal.app. I could have it do it sans file but I like to see the output for some commands in a window.
Open the Automator file and change the default command to something you do often and you’ll also probably want to change the script file path to something other than your desktop.
You could probably edit the Automator workflow to use selected text as an input so that you could use something like awk in your text or HTML editor. That might get a little hairy with encapsulation of stuff though, so I’m not positive how well it would work for deep text scripting. Anyway, I hope you get some use out of it.
Just a note that yesterday I penned a piece for Ars Technica looking at the contentious new Mac Pro design:
I’ll be writing a full review when the machine ships, which should be around September/October.
3 notes | Permalink
Apple makes nice hardware and some people are tempted to run Mac machines in Windows via Boot Camp as their main workstation, thinking they are getting the familiarity of Windows with the Apple hardware. Apple’s Boot Camp drivers support the GPU, motherboard chipset, audio, etc. in your machine but there is one crucial difference that I just discovered while writing an article on ExFAT for Ars Technica: Boot Camped Windows runs your disks in IDE mode for installation compatibility reasons and there is no way to run the faster AHCI mode without doing something dodgy like using a custom bootloader like grub. That means that your SSD that will perform amazingly in OS X will be running at just over half the speed in Windows. CPU and GPU functions will be fine but this will definitely affect the overall performance of Windows in your Boot Camped Mac. Applications will launch slower, file saves will take longer and your virtual memory writes will take a serious performance hit. So there you have it - if you buy a Mac, it’s best to use it as a Mac. And that might not be such a bad thing when you compare rendering performance between OS X and Windows (not to mention multitasking abilities while doing those renders).
2 notes | Permalink
I use Python 3.3 for my multithreaded Automator actions in OS X but I just realized that this prevents Houdini from installing properly if you’ve overwritten /usr/bin/python with anything other than Python 2.7. If you have a custom Python version installed, just copy the 2.7 binary back over /usr/bin/python, and then Houdini will install correctly.
I do a lot of composites of similar images or render passes, so I like to have the document name as the layer name so it’s clear which document was used for the layer. I don’t know much about scripting Photoshop but I managed to piece together a very basic AppleScript to do exactly that, so grab it here if you want to:
The original AppleScript is here: Rename Front Doc with Document Name AppleScript.
Here it is in action:
I use this script so often that I ended up putting the script into an iKey hotkey so I don’t need to the AppleScript Editor to run it manually. I highly recommend iKey if you want a keyboard automation app for OS X. I also used it to map command-shift-z to command-y for Nuke’s redo function and it does a bunch of other auto-typing stuff for me.
1 note | Permalink
I just got word of this tip that lets you alter the way that windows float in Maya for OS X. By default, floating palettes sit on top of the main window in Maya and this can be either helpful or annoying, depending on your preference. Luckily, you can change this behaviour to let the main window cover palettes by adding this line to your Maya.env file (~/Library/Preferences/Autodesk/maya/2013-x64/Maya.env on my machine):
Restart Maya and you’re set. The command-` still cycles through windows, so you’re not going to lose any windows:
Update: Just thought I’d mention that, in OS X, you can click and manipulate (move, close, minimize) background windows by holding down the command key modifier when clicking. So you could have MAYA_SET_PARENT_HINT=0 on and still manipulate another window without bringing it forward:
It’s a good one to know. OS X has a lot of these little hidden command key and modifier features.
1 note | Permalink
In an older post and in my 101 Autodesk Maya Tips, I talked about how you can send UNIX standard output to Maya via its commandPort and I just made a tool that batch generates previews for files using an open session of Maya. I made something similar in the past but it was slow because it launched a new session of Maya for each file via command line rendering. This is very quick because it just tells an already-open app to make a new scene, import the file, kick out an antialiased viewport 2 render to JPEG, wash, rinse and repeat.
Here is the Automator workflow file to install. Don’t rename it because it contains a shell script (stmaya) that bounces commands to Maya. You need to enable commandPort on port 2222 before Maya will accept input from the action. Do it with this command (I put this line in userSetup.mel so it is executed on Maya’s launch):
commandPort -n ":2222";
The only thing to keep in mind is that the script sets the imported file folder to your working project directory, so just remember to change it to your desired project after you’re done batching or you’ll be rendering into the last-previewed /tmp folder. Also, save your existing open work before you start doing these because it uses the “file -f -new” command meaning it won’t prompt you to save if you have an open doc with unsaved changes.
If you’re on Linux, you can do a similar thing with the two shell scripts that the Automator action uses. This is the script that operates on your input 3D file and this is the stmaya script that passes standard output to Maya. It’s a bit of a hairy combo that would be much nicer as one Python script but I am just updating existing bash scripts.
Sorry, Windows users – there’s no way to pipe standard output to Maya from the command prompt in Windows, so this can’t be adapted for non-UNIX OSes.