I’ve recently returned back to Maya after 7 years in a 3DS Max based studio.
I’m planning out a pipeline for a commercials department and was wondering on everyone’s thoughts about PyMel. I’ve had a little play with python for Maya and have found it baffling in the way it interacts with Maya itself … however experimenting with PyMel I’ve found to be a much more complete programming language.
Although it does seem a million times better than the default implementation, I worry that PyMel might be a bit of a dead end or a novelty that would cause our pipeline development to hit a wall after a certain point.
Does anyone have any thoughts on PyMel vs Python in Maya as a language to create pipeline tools and scripts ?
PyMel is actively developed, blessed by Autodesk, and very quickly becoming an industry favorite (from what I can tell). What sort of walls would you expect to hit?
More a case of not wanting to back the wrong horse. Having a studio depend on countless tools written in a language that feels just a little peripheral worries me a touch. I guess I’m looking for reassurance from people that they’re using it and it’s not going to go away soon.
The fact that it’s been rolled into Maya probaby is a good sign.
Here at Lionhead we switched to Maya about a year ago and decided to use PyMel exclusively ( mainly because we’re so used working in an OOP language ).
So far we have hit very few issues, and those that we did hit have been extremely minor and lets face it, when that happens its not the end of the world to import maya.cmds to get around something. Though i think thats only happened in a couple of places throughout our pipeline code base.
As Tyler mentioned, it is actively developed and plenty of people use it. There are some performance considerations to make, as iterating through large amounts of pymel objects can be slow(er), but for us at least the amount of times we have to switch to cmds for that is minute compared the rest of our code.
I don’t think there is any worry that PyMel is going away anytime soon.
I also wouldn’t go as far as to say it is an industry standard either.
At the end of the day it’s about what your team is comfortable with. Also evaluate the scope of the pipeline and the perceived benefits of using PyMel over the native Maya command implementation.
It’s probably fine. Ive never used pymel, but it’s worth noting that you’re still using the python language when you’re using pymel. And I don’t think that’s going any time soon.
I think PyMel is great, I only use mayapy for plug-ins and when PyMel becomes to slow inside of Maya. It’s not hard to convert PyMel code to mayapy and vice versa if needed either.
We use 95% PyMel, 5% maya.cmds when iteration is an issue (lots of vertex walking).
Even use it for a few custom node plugin-ins.
I am a lazy programmer and rather see my design in action quickly first, pymel offers a fair amount of wrapping to accomplish that over straight cmds or MEL.
One suggestion I’ll make is to ignore the PyMEL docs when they suggest to import the entire namespace: “from pymel.core import *”.
It may be safe, but if you find you do have any compatibility issues or want to mix in some maya.cmds or if for some reason you find you have to abandon PyMEL, having a distinct namespace such as “pm” will be useful for quickly searching for instances of PyMEL commands. Just a thought.
I like PyMel too, but have been moving away from it recently due to a few reasons. I know performance comparisons between mayapy and pymel are made on a daily basis and some don’t mind, some don’t notice and I guess ultimately its all down to whatever flots your boat but I’ve found that the extra time I spend coding in regular mayapy is largely outweighed by the extra time I spend interpreting the slightly more layered errors I get from PyMel.
It has a way of telling you what is wrong in the original PyMel source, rather than your own code, having you chase your tail just a bit more than when you get errors directly related to your code or your submodules, like in mayapy.
I do however use it all the time for smaller pieces of code, or when I’m being pushed to deliver right this instant.
The only thing to remember is, NEVER EVER mix PyMEL and maya.cmds in your class interfaces. IE, a module should ONLY use PyMEL for any of its external classes and functions, or ONLY use maya.cmds (internal implementations can be mixed, just document it). I’ve seen modules do this and it causes no end to grief.
[QUOTE=Rob Galanakis;15800]The only thing to remember is, NEVER EVER mix PyMEL and maya.cmds in your class interfaces.[/QUOTE]
I have seen this statement plenty of times, but never any just cause to back it up.
You can’t pass a PyNode to regular maya.cmds. PyMel deals with python objects and maya.cmds deals with strings. I find that as long as you keep this in mind, you can mix and match however you please.
And, whenever you need to go from one implementation to the other, you can simply cast it:
I understand that you may want to view pymel and mayacmds as a grey area, but not mixing them is sort of fundamental to API and module design. In fact Python 3 was largely developed to solve exactly this problem of objects that look alike, are designed and treated alike, are convertible back and forth, but ultimately must be treated very differently- unicode and ascii strings! If you want to understand the “just cause to back it up”, I’d suggest reading about the basis for Python 3, since the problems are pretty much exactly the same.