after using it on a fairly surface level for about a few weeks its pretty obvious that I should be using pymel.  its not easy to describe why, but I’ll take a shot.  the main reason is kinda “fluffy”, but basically it lowers mental friction when you need to interact with maya via script.  and lowering mental friction means you just get more done.

mel (and thus default maya python) is pretty straight forward – in theory.  but in practice there are all these stupid little gotchas, and most of those gotchas made their way across to the python binding of maya’s scripting interface.  awesome things like “hey I want to add an attribute.  do I use the dt or at flag?”.  or other little things like “hey I want to set a string attribute to something – don’t forget to use the -type string flag for whatever reason”, or “hey I want to query something about an attribute, which command do I use?”, or “hey, are these two objects equal?  you’ll need 10 lines of code to be sure!”.

also mel has no data structures that make sense for a 3d app.  hello?  its a 3d app, how about vector, matrix, euler and quaternion data types?  its weird that they never added these – oh and don’t tell me about the “vector” data type in mel.  its essentially useless, and seems largely unsupported.  sure the python bindings allow you to roll your own data types, but you still need to cast return values from mel commands to their appropriate type.

there are a lot of weird commands in mel, and there is a lot of mental friction involved in trying to think whether querying data about a reference is done with the file command, or the referenceQuery command.

why does pymel help?  well, in some ways it just changes the problem, but in many ways alot of things are simplified.  there is generally less typing – which again goes to the lower friction point above.  commands that return vector data actually return vector data – which means you can add and subtract them, ask for their magnitudes etc…  there are nice methods for things like querying hierarchy.  someNode.getParent() or someNode.getChildren( type=’joint’ ) for example.

of course, if you’ve already got a heap of python scripts written you may find it annoying to integrate pymel into your code.  pymel fixes a bunch of issues, and many of those fixes mean small changes which mean you can’t just drop in pymel.  and because pymel data types aren’t strings you can’t pass a PyNode to a non pymel command.  so there are a bunch of issues doing anything but a wholesale integration of pymel, and if you have a lot of code already, a wholesale integration can mean a huge amount of work.

I’ve gone the path of a partial integration.  It was originally kinda painful, but I think I’ve found most of the parts of the tangled web that is our code base that pass data across boundaries, and its working really well.  but it was initially a pain in the ass – so be warned.  I believe this problem may get worse going forward I’m not sure.

anyway, thats my experience thus far.  if you’re doing reasonably isolated tool work you should definitely be using pymel.  if you’re doing work on more integrated code then its probably not worth doing until you have a better handle on where the problems will occur.  I stupidly decided to use it on some new rigging tools which has been kinda painful tracking down all the points of failure.  and while painful so far its been worth it.

oh and I’m using 0.9.2 – the pymel guys are already way ahead with their alpha 1.0 release.

This entry was posted on Tuesday, January 19th, 2010 at 21:45 and is filed under main. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.