Posts Tagged ‘ Maya

Mel command argument passing in Python

From over on my mel wiki

Python has some shortcuts you can implement when passing arguments to mel commands (or other Python functions).
Take for example a sphere (named pSphere1) that you want to scale. Here is the basic mel to do so:

float $scaleVals[] = {1.0, 2.0, .5};
// optionA:
setAttr pSphere1.scale -type double3 $scaleVals[0] $scaleVals[1] $scaleVals[2];
// optionB also works:
setAttr pSphere1.scale $scaleVals[0] $scaleVals[1] $scaleVals[2];

Likewise in Python, you can do something very similar:

import maya.cmds as mc

scaleVals = [1, 2, .5]
# optionA:
mc.setAttr("pSphere1.scale", scaleVals[0], scaleVals[1], scaleVals[2], type="double3")
# optionB also works:
mc.setAttr("pSphere1.scale", scaleVals[0], scaleVals[1], scaleVals[2])

However, in Python you can pass all the args in as a list\tuple variable by prefixing the variable name with an asterisk ‘*’. The function (mel command) will unpack the variable as individual positional arguments. It’s important that the variable have the same number of items as the command expects argument values, or a Python RuntimeError exception will be raised:

# option C, much cleaner!:
mc.setAttr("pSphere1.scale", *scaleVals)

You can see more about how this argument system works over on my Python Wiki.

How does Maya populate its maya.cmds package?

From over on my Mel Wiki:

When using Python in Maya, to access the bulk of the mel commands via Python, you import the mel.cmds package, usually into a namespace, like so:

import maya.cmds as mc
print mc.ls()

But if you browse to that package on disk, you’ll find it empty, only containing an __init__.py file (required for package creation):

C:\Program Files\Autodesk\Maya<VERSION>\Python\Lib\site-packages\maya\cmds

So how are all the ‘mel commands’ added to that package for execution in Python?

There is a Maya startup Python module living here, that works the magic of populating that package:

C:\Program Files\Autodesk\Maya<VERSION>\Python\Lib\site-packages\maya\app\commands.py

It inspects a file called commandList (no extension, but it’s text) living here:

C:\Program Files\Autodesk\Maya<VERSION>\bin\commandList

You can open that file in a text editor, and what you’ll find are two columns: One with a ‘mel’ command name, and one with a .dll where that command ‘lives’. Those .dll’s live in the same dir as the commandList file. Here’s a sample:

TanimLayer AnimSlice.dll
about Shared.dll
addAttr Shared.dll
addDynamic DynSlice.dll
addPP DynSlice.dll
affectedNet Shared.dll
affects Shared.dll
agFormatIn Translators.dll
agFormatOut Translators.dll
aimConstraint AnimSlice.dll
air DynSlice.dll
aliasAttr Shared.dll
align Shared.dll

What commands.py does is parse the commandList file and append each command (via a Python command wrapper function) to maya.cmd‘s ‘__dict__‘ attribute (maya.cmds.__dict__), which is the lookup table users access when calling their favorite mel command via Python (like maya.cmds.ls())  It also passes the name of the .dll to the command wrapper function, so when the user executes the given command, it first loads the parental .dll.

Crack open commands.py for the nitty-gritty details.

If you want to see the end result of all this hard work, you can run this code in Maya. But it prints a *lot* of stuff:

import maya.cmds as mc

for k in sorted(mc.__dict__.keys()):
    print k, mc.__dict__[k]

R2D2 Maya Viewcube

Based on this post that I read a while back, I decided to ‘modify’ my Maya viewcube.  Runners up were Mario, Spongebob, and the Death Star.

r2d2_viewcubeHere’s the .png, for your own usage:

VCfacemap

I got the R2D2 pattern off this papercraft site.

Open Source Sony?

Saw that Sony just opened up some of their software to the world, darn fine of them to do:

http://opensource.imageworks.com/

Includes:

  • OSL: Open Source Shading Language
  • Scala Migrations: Database Library Management
  • Field3D: Voxel Data Storage Library
  • PyString: Python string handling in C++
  • Maya Reticle: Flexible camera guilds for Maya

What to make a game in, part 2

After some serious thinking (based on my previous post), I’ve decided to go with PyGame as my initial platform for making a game.  As much as I like Processing for making ‘interactive visuals’, the more I learn Python, the more I like it (as in, the language itself… Python has no great graphics abilities on its own).  The syntax is just so much cleaner than Java (Processing).  I also looked closely at XNA, but approaching C# doesn’t give me any great joy, based on its structural similarities to Java.  There is a huge XNA community, and I’ll probably come back to at during some point.  I also took a serious look at Blender, and its game creation system.  But since I’m so used to Maya as my DCC tool, switching to Blender was really hard.   You can’t change the hotkeys!  It’s just too much for me :)  Maybe when version 2.5 comes out…   So for now,  PyGame FTW!

I have picked up some books on the subjects to supliment the vast quantity of tutorials on the web:

PyGame:

XNA:

And while I was at it, got one on the Arduino, since you never know when that will come in handy 😉

I’ve already got a simple 2-‘player’ game up and running where you can drive two ‘tanks’ around the screen.  A pleasing start.

On a side note, my Xbox 360 got the RROD last night.  Sigh…