Pymel vs MayaPy

I’m kinda interested who is completely submerged into Pymel now as a standard part of their pipeline, or who has shunned it or avoided it.

I guess I’m also interested in its future as it doesn’t seem to be met with any kind of release schedule and obviously as its a third party wrapper its not supported by Autodesk despite its inclusion as a distributable.

What are the chances that Autodesk would move to be more pymel’ish or pythonic over the current mel in a blanket that is implemented?

Stayed away from Pymel myself. It was also not being used in the last 3 studios (1 game, 2 film) I worked at.

Although, right now I’m running my own OOP wrapper API around Maya, it is also being used on a couple of shows here at DD although not too widely just yet.

[QUOTE=rhexter;9580]I’m kinda interested who is completely submerged into Pymel now as a standard part of their pipeline, or who has shunned it or avoided it.
[/QUOTE]
Our pipeline is built on it and we actually make fixes and add features.

[QUOTE=rhexter;9580]
its not supported by Autodesk despite its inclusion as a distributable.
[/QUOTE]
Not supported officially but Autodesk does have their own branch, they’re not just pulling from main and shipping it when Maya goes out, and i believe Dean Edmonds does make fixes to the Autodesk branch. I know Chad Dombrova posts here occasionally, he could probably illuminate better/further.

And yay! Potential for another maya.cmds vs pymel thread! Because there aren’t enough of those in every other forum that has a maya scripting section!

Let me say this up front - pymel is an impressive project. The scope of the work is huge, and Chad executed it really well. His releases are solid, having all the unit tests and whatnot is a huge amount of work. I’ve learnt alot from reading his code.

Having said that…

I came to pymel late in the game. I had heard of it, but initially didn’t see the point of it. After all, I was super familiar with mel, and while syntactically different, maya’s python bindings were basically just the same api as mel. At least at first glance.

I wrote my initial thoughts down after using pymel for about a month in this post: http://www.macaronikazoo.com/?p=224

Anyway after using it for a few months I eventually moved away from it completely. I wrote up my thoughts on why it didn’t work for me here:
http://www.macaronikazoo.com/?p=271

But basically for me it comes down to two things - its really inconvenient to use in just part of your code base, so using it is an all or nothing affair*.

And secondly its really slow.

These two reasons mean that using it creates sub-optimal code.

*to go into more detail - instances of the PyNode class cannot be passed to maya.cmds functions - they need to be cast as a string first. So if you have a function/class based on pymel that calls into one that isn’t, one of them needs to handle this conversion. Now if the caller does the conversion then when the callee gets re-written in pymel there is no clear way to fix up this dependency.

Similarly if the callee does the conversion, then you end up having to edit all the leaf code you touch just to convert a script to use pymel. Both of these options are just horrible in my opinion. The last option I guess is to re-write your entire codebase to work with pymel - but then you’ll almost certainly bump into the performance problem.

Anyway. Thats my take on pymel. :slight_smile:

And yay! Potential for another maya.cmds vs pymel thread! Because there aren’t enough of those in every other forum that has a maya scripting section!

Yeah sorry, its a while onwards and theres little movement in some of the older threads.
I am legitimately wondering how embedded its become for most, if at all.
This really should have been a poll I guess.

Not really looking at a flame war or which is technically better than the other, just how entrenched it is becoming within the sample of industry that lurk here ;).

I do find it slow to work with, because ‘my’ memory is not good ;), I’m entrenched in legacy mel (still), but I do love the OOP side of it and when i get going, it pythonically flows much better, I try and use it when i can its more comfortable when diving in and out of native python which seems to happen a lot.
But and its a big but i’m not a power user and I’m not writing my own fixes.
Plus I seem to grind to a halt at Ui related stuff for some reason.

I would certainly be interested in knowing how big the user base is…

[QUOTE=rhexter;9585]Yeah sorry, its a while onwards and theres little movement in some of the older threads.[/QUOTE]

Probably because everything that’s going to be said about that whole issue has been said in those threads. Some people like it, some people think it’s slow, altho i can’t remember the last time i heard an artist complain that our pymel tools are slow oh because it’s never happened. I doubt the user base is that big, i’ve only worked at one studio that used it, but i will be building my future pipelines against it.

We use it extensively, in fact most of our recent pipeline is based on it to the point that we’ve patched into some of the Pymel node types and extended them, makes programming far more simple. For example pm for us now returns our own eTransform, eFile, eCGFX nodes etc… which in turn have extended calls on them to add functionality for our pipeline. Keeps things very tidy.

Now as has been said, if you’re itterating over large numbers of Maya nodes, it’s slow, and as long as you bear that in mind and drop to cmds when you need to, Pymel is a godsend.

[QUOTE=rhexter;9580]What are the chances that Autodesk would move to be more pymel’ish or pythonic over the current mel in a blanket that is implemented?[/QUOTE]

Not sure if anyone else was at the “Oh My… Maya is QT!” talk by Autodesk at GDC, but during the Q&A there was a question about what is new in Maya 2012… and here it this: From what I understand they have started to change their own python command implementation to be more pythonic in nature. Apparently the implementation is about 50% done in Maya 2012 and they hope it will be 100% done for Maya 2013.

Of course the follow up question was if they saw this new implementation as a competitor to PyMEL. And the answer was of course no, and that PyMEL and Mayas Python Script would still exist side by side.

Another thing that came up in the Q&A was that the Maya Python API is finally done in Maya 2012, as it apparently hasn’t been fully implemented with everything from the C++ API until now. Apparently it was mainly on the GUI side that it was a bit unstable until now.

Some unexpected info to come out of that talk early on Wednesday morning.

[QUOTE=Mark-J;9592]Now as has been said, if you’re itterating over large numbers of Maya nodes, it’s slow, and as long as you bear that in mind and drop to cmds when you need to, Pymel is a godsend.[/QUOTE]

I wouldn’t say Maya nodes as much as mesh components. I do a lot of iterating over vertex and face list as I only deal with the art pipeline and not animation, and going into components I always have to go back to cmds as it can save up to several minutes in execution time.

But it’s as you said, just keep it in mind and go back to cmds where it is needed and PyMEL works fine.

[QUOTE=macaronikazoo;9584]
But basically for me it comes down to two things - its really inconvenient to use in just part of your code base, so using it is an all or nothing affair*.
And secondly its really slow.
[/QUOTE]
These were my observations back when we first tried to roll out pymel a couple of years ago.
I ended up addressing both of these by allowing almost any oop object to be passed into a maya command directly. Thus if you want to use it in just a specific area it’s a seamless integration.
The performance is improved by making it a pull based system, as much as possible, where objects get instanced only as you need them.

Glad I missed this thread for a couple of days. Thanks Seth (and others) for taking up the initial charge.

In one long-sentenced-nutshell . . .

PyMEL’s super-power is that every Maya node becomes a class which means that everything you’d want to do to any node becomes a method attached to every instance of these classes which is then auto-completed in a powerful IDE like Eclipse.

If this doesn’t make sense or doesn’t seem worth the “hassle”, then keep at it until it does, 'cause one day you’ll see that this is a powerful way to code Maya.

Explained in full Thursday morning at GDC: http://bit.ly/e5f43R

I’d still like to run a poll to see how embeded pymel is to demonstrate to Autodesk that they should drop their own ‘suggested implementation of pymel’ and actively support pymel maybe even pay dues to someone thats made such a big impact on the industry, personally I think thats fair and something a community could potentially do, no?

Otherwise they are going to put effort into something that is pointless as we’ll all be based on what we have now and reliant on the Open source updates, that appear to be being fixed in house, but are those fixes rolling back to the community within revisions??

In my mind the fact that its adopted at a core level within Sony, Microsoft and other well known and respected production houses should say something that Autodesk should be recognizing. But not to say oh we’ll write our own version.

Thanks for the links they are great guys, btw!

Well while pymel has been adopted very widely it’s far from being accepted as the universal standard for programming in Maya. There are many big studios that do not use it for various reasons so if Autodesk does actually ask that question they will hear a lot of “no thanks”!

[QUOTE=rhexter;9787]But not to say oh we’ll write our own version.[/QUOTE]

Did you miss this part? They are kind of already doing this, about 50% done in Maya 2012 apparently.

We use it extensively in our pipeline.

And it would behoove any potential candidates for our upcoming job offers, for more pipeline TD/TAs (shortly coming), to know it as well =)

Yes, the marshaling from string to node sucks.

Yes the new 2012 stuff is super neat, but way incomplete. That is the trend over at AD, first round pass = half §arsed

but whateva…

We are talking mostly end users being artists.

When you have tools that ultimately shave off hours of time, a few seconds of waiting is not killing anything critical.

And if it is, you are using the wrong tool to get the job done.

Jumping forward now to the Maya 2013 cycle timeframe, I’m curious if anyone has more information on that Autodesk-internal effort to produce a more “pythonic” Maya wrapper library they started in 2012?

I don’t see any reference to their completing or making progress on it in the “What’s New” information…

The Python API 2.0 (maya.api.OpenMaya) are just upgraded wrappers around the C++ OpenMaya API
http://docs.autodesk.com/MAYAUL/2013/ENU/Maya-API-Documentation/index.html?url=files/GUID-EC669155-DD0C-4072-A0DC-D24C7FB2AB2D.htm,topicNumber=d30e17833
It has a very different command structure than maya.cmds.

PyMEL is the best of both. It wraps maya.cmds in an OOP way so it behaves similar to OpenMaya but not in the crappy C++ kind of way. :x:

This is a decent high-level explanation of these wrappers: Why PyMEL? — PyMEL 1.0.4 documentation

PyMEL won’t make sense until you start to use it. Then it will start to make a whole lot of sense. I recommend trying it on some select projects and giving it a little time. You’ll never go back! :D:

(Unless you’re a genius like Hamish et.al. and can write your own) :p:

I hope it’s OK for me to bump a several year old thread rather than making my own and referencing back to it, but this is the better result I found when searching on google.

How has the information presented here changed? Primarily studios using it over Python. A couple of the reasons to veer away stated is the inferior speed vs. maya.cmds and Autodesk’s incomplete pymel, I assume these will have both changed?

I’ve always ignored PyMEL but was considering it now and not finding solid up to date information.

Thanks

I think it’s like @Macaronikazoo had it: it’s great project, especially if you’re not a hardcore pythonista, but it’s got speed and ‘weight’ issues. None of that has really changed in recent years. And integrating it with other code requires some thought.

You can do OO-style coding without it if you are a 70th perceentile pythoneer or up – but if you’re not it, it’s a good start. For a smallish team or a junior/intermediate coder I’d say it’ s a good platform because it helps you think in less imperative terms; eventually you outgrow it. It’s really excellent training wheels.