I’ve done a very slight amount of scripting with MEL. I’ve started down the path of learning Python because of its all around usefulness but it looks like the python I was vaguely familiar with (import maya.cmds) was replaced with PyMel (which is more pythonic instead of simply wrapping mel commands)…simple…until I read about something called OpenMaya…which is also python based. Does this now replace PyMel? I can’t find a straight answer on what it is other than it uses python and is faster than PyMel.
Its not quite as simple as one thing replacing another. Probably better to say they are 3 different things. In my own over simplification I’d say maya.cmds was an attempt by tthe maya devs to convert every mel command to a python equivalent. PyMel (written at LumaPictures ? ) did this too, and in addition provided an object oriented way of using those commands. OpenMaya is giving you access to the maya C++ api through a python wrapper, and for many operations this has an obvious speed advantage.
Which one(s) you end up using is going to depend very much on your scripting skills and you scripting needs. My preference was for the objected oriented PyMel approach enhanced with a small amount of OpenMaya. But you should probably not judge from other peoples experience. Try each of them yourself and see what works best for you.
for just general scripting if your takeing a object oriented approach pymel is by dar the best.
OpenMaya is a wrapper around the C++ api it defiently requires a lot more boilerplate code to accomplish the same things you can do with pymel or cmds, but performs very well for things with lots of iterations.
openmaya is what you will need to use if you want to create a plugin that implements something like a new file translator, or a manipulator.
I use pymel for almost everything and only openmaya for the very odd thing.
For the most part, it is all about trade-offs: functionality, flexibility, execution speed, development time and ease of use.
Everything (with a few non-public exceptions) that you can do in standard Maya Python and PyMEL, you can do using the OpenMaya modules. This is not true in reverse. There are lots of things that you cannot do in Maya Python/PyMEL and require OpenMaya.
Using OpenMaya provides you with the most functionality, flexibility, control, and (generally) the fastest execution speed. But, and this is a big but… it is not very easy to use. There are usually many more lines of code required to accomplish a task using OpenMaya. There are also many more things that you break when using OpenMaya. You are responsible for a great deal more error checking. This increase in code complexity leads to longer development times and more challenging code maintenance.
Maya Python/PyMEL make the more common operations much easier to work with and decrease the potential for errors. For the most part, the commands just work. This is great for decreasing development time and errors. Again though, it is a trade off. Generally, execution is slower and you may not have all of the desired flexibility.
In most cases, the sacrifice in execution speed is worth it (often it is negligible). And, Maya Python is comprehensive enough that you can accomplish most things without ever touching OpenMaya. Assuming you are new to Python and Maya scripting, I would recommend avoiding OpenMaya until you are comfortable with the basics.
Personally (and this is just a different perspective), I avoid PyMEL whenever possible (and it is almost always possible). I don’t find the trade-offs worth it. Keep in mind, PyMEL isn’t a replacement for regular Maya Python, it’s just an add-on/alternative.
First there is the overhead. PyMEL does a lot of extra stuff under the hood, both one off when you first import the module and extra stuff to make it object oriented. Usually, there is little gained by doing this, just wasted cycles.
The bigger problem is that when working on a larger code base, not just one-off scripts, when PyMEL is mixed with regular Maya Python the potential for errors/bugs increases dramatically. Code reuse and maintenance becomes a nightmare. For example, some methods may return a list of node names (strings) while others return a list of PyMEL objects. Six months down the road, even if there is only one TD/developer, people forget which is which.
In a team environment, or when integrating 3rd party tools, this becomes even more of a problem. One person uses PyMEL, one doesn’t. Or, someone adding to an existing module decides to use their method instead of conforming to the existing standard of the code.
Consistency is obviously most important, and because of that, in the last two studios I’ve worked at, PyMEL was, for the most part, blacklisted from the pipeline (exceptions for certain types of tools where applicable).
Well, on the other side pymel makes code better readable and maintaining is easier. We use it since is was boundled with maya, even a bit longer in quite heavy productions and even if it may sometimes take a bit longer, it is a really efficient tool.
Of couse I agree, it has some drawbacks. But you can combine it quite nicely with OpenMaya because from any pymel node you can get its MObject, MDagPath or other api types on the fly.
I disagree. Both of these are highly subjective statements and are a matter of personal opinion.
However, I agree completely with you on PyMEL’s integration with OpenMaya. It is a definite advantage. That being said it is rarely used an becomes unnecessary overhead.
Really I find the oop syntax you can use in pymel is much more readable. But as far as maintaining things I find there is no difference. Good encapsulation and other patterns to make code easier to maintain is all on the writer.
I just weigh the pros and cons of eeverything when I choose what to do. tend to use pymel when performance is not a concern since I like the features it offers over maya.cmds
If performance matters I will start in openmaya for python and if I need more speed I will prototype in python with openmaya than move it to c++ api.
This. For the original poster (rochre26), despite all our side discussion, find what works for you and use it (especially when you are learning). Try them all. If/when you end up at a studio with a fixed set of programming rules, you may have to change things up but it probably isn’t something worth worrying about now.
Thank you all for the thorough explanations. I was concerned about wasting time on something that was about to be deprecated that doesn’t seem like the case.
Would it be fair to say that maya.cmds would be for procedural programming and PyMel would be for an OOP approach? My understanding of OOP being that if you know where you’re heading and have time to plan it can lead to a more effiecient design but that this isn’t always an available luxury. I’m sure this is somewhat inaccurate.
maya.cmds is a wrapper for MEL. Ultimately, you are just making function calls. PyMEL leverages object-oriented design and builds on the maya.cmds module.
OOP vs procedural is a debate that has been raging for many years now. There are arguments for both sides. Learn both, use what feels more appropriate for the current situation.
Keep in mind, you don’t need to use PyMEL to write object-oriented code and using PyMEL doesn’t make your code object-oriented.
Also, don’t get hung up on overused buzzwords like “pythonic”. It tends to get thrown around with reckless abandon and has lost most of its meaning.
Despite my obvious lack of enthusiasm for PyMEL, I write almost all of my code in an object oriented manner. Everything is a class (for both Python and C++). I find the benefits far outweigh the longer development time. This is especially true when working with a larger code base.
OOP usually takes longer (in the beginning). Design is generally more complex and you can end up writing (significantly) more code. That being said, code maintenance and extending existing code is where OOP shines.
In a production environment, where everything needed to be done yesterday, it can often be difficult to allocate the time for good object oriented design. Over time though, it can really pay off.
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.