Back to when I had to work on Maya 2010 and that PyMEL wasn't shipped with it, I banned the idea to deal with the Python command layer (the port of MEL to Python) and decided to work exclusively with the Maya Python API. It's been a painful experience and—as probably everyone using it—I ended up writing a lot of routines to fill-in the gaps.
I did this using a well-known technique called monkey patching. It can be quite hackish, dangerous and even evil depending on how it's being used but I've intensively made use of it in a few productions and it's been quite helpful for me. It should be seen as a last resort kind of thing though, if no better alternatives are available. I've started to write an article some times ago that mainly focuses on a convenient way to implement the monkey patching technique for the Maya Python API. If you guys are interested, I'll share the link over here when it'll be online. On 6 May 2014 19:42, Raffaele Fragapane <[email protected]> wrote: > Your beloved Softimage scripting experience won't be coming back. It's not > all downsides, but Maya just works very differently. In some cases it's > superior, in some cases it's even more pleasant to deal with (Qt), and in > some others it's so dreadful you'll just be better off using the C++ API > even if performance wasn't a concern. > > In Soft, for better or for worse, the entire API was passing COM objects > around towards the scripting side of things. On Top of that, the general > layout of the application, the scene, and the various accessors lent itself > very well to Pythonic styles. > > In Maya you do have several options. > You can import mel commands, which is largely a legacy thing but some > times still needed, which was the first implementation offered back then. > It's OK if you miss something somewhere (there are some dark corners of > Maya where only MEL can go still, places where innocence dies) and have to > absolutely get there, or have to quickly convert some MEL script to Python > with little time to do it. > > You have pymel, which was originally a private initiative by some VFX > shops (tempted to say Luma started it originally), which is a wrap that's > intended to "feel" pythonic in how it divides and offers modules, and does > a decent enough job of it, this was later bought and offered by Autodesk. > It's not bad for pipeline-y scripts actually, but performance can swing a > lot. > > And lastly you have OpenMaya, which I think gets referred to as the Python > API these days, which is now up to v2. > OpenMaya is a 1:1 binding of the C++ API, which IMO is by far the > strongest and better engineered of various things in Maya. The good news is > that that makes it relatively fast and gives it access to a considerable > extent of Maya's guts. The bad news is that the wrapper being a largely > automated job derived from headers it has limitations and requires you > constantly deal with very, very type specific methods and constructors, > which usually leads to Python code that vastly surpasses the line count of > the same in C++, not to mention is simply not meant to be written or read > like that. > In some cases it gets to the point where I don't even bother doing proto > work in Python, and just straight away pick up a template and start writing > a step further than that in C++, because it's just too damn noodly to have > any of the benefits of doing a sketch. > > Lastly, you have pyQt (or pySide, the distinction as a user is almost > academic), which is the framework a great deal of Maya's UI work and a > handful of other things, and that works quite well at several different > levels of depth. On that I agree with Luc-Eric. > I also agree with Luc-Eric on the availability of more and better > examples, especially in the advanced topics, but there's also a lot more > crud to sift through. All in all though it's rare I can't find at all what > I need if I look for it hard enough. > > Hopefully that clears it up in terms of what the options are. > As for what your scripting experience will be, you have to bear in mind > Maya and XSI do things very, very differently. > I have a deep dislike for the mantra "all software are the same it's just > a matter of finding what the button is named". It's total and utter > bullshit if you do anything more than pushing buttons :p > > Some things are better in one app, some in the other, but in general be > ready to write A LOT more code when it comes to Maya. It has a very... > "diverse" approach to many things, often scattered and specialized in > inscrutable ways. Some things that are trivialities or have obvious > feedback when operated in XSI will have crawling over walls and spewing > like the child from the Exorcist movie. > There are good days when I don't have to roam in the dark areas, and > writing/porting some nodes is an enjoyable experience. Other days I have to > call IT for a new monitor. > > > > > On Wed, May 7, 2014 at 12:35 AM, Leendert A. Hartog <[email protected]>wrote: > >> See what you did there? You confused me needlessly. ;) >> >From all of this I gather there is an original Python implementation, >> PyMEL and Maya Python 2.0. >> And some comments seem to imply none of them are any good... >> So where to actually start, if this is more of less true? >> What comes closest to our "beloved" Softimage Python scripting experience? >> >> >> Greetz >> Leendert >> >> -- >> >> Leendert A. Hartog AKA Hirazi Blue >> Administrator NOT the owner of si-community.com >> >> > > > -- > Our users will know fear and cower before our software! Ship it! Ship it > and let them flee like the dogs they are! > -- Christopher Crouzet *http://christophercrouzet.com* <http://christophercrouzet.com>
