On Fri, Jul 4, 2014 at 11:35 PM, Marcus Ottosson <[email protected]> wrote:
> It’s been a while since I dipped my toes in PyMEL and it was early on in > my programming experiences so it’s likely that if I ventured back into it > at this point in time I might end up looking at things very differently, > but I’ll try and summarise why I’m *not* using PyMEL today. > > I was stoked over the prospect of dot-notation access to operations on > nodes in Maya. Having worked only briefly with Python and maya.cmds at > the time and wanting to get deeper into classes and inheritance, PyMEL > seemed the smart way to go in terms of learning about things and I was in > no position to draw any conclusions about whether or not > object-orientedness of maya.cmds was a good thing, so from where I was > standing using PyMEL was a given. > > In regards to performance, I did take notice of the fact that most things > took a while longer than they used to - especially the ~5 second freeze > upon loading pymel itself, something that would pop up whenever I shared > scripts with someone who hadn’t pre-loaded PyMEL or in cases where I used > it on a new workstation (as a freelancer at the time, this was quite > frequent), something I think have been taken care of today although I > haven’t investigated - but I honestly never had any real issues with it and > in general don’t bother much about performance in anything Python anyway > and would turn to other languages for that sort of thing. > In my specific case, I had to worry about performance because it was a user-facing tool that scanned the scene for specific kinds of bad geometry. So it used a lot of loops. At first it was written in python cmds. Then I found PyMEL and tried that, assuming the underlying usage of the API would improve my performance. It actually made it multiple times slower. I ended up writing it in the API directly and got excellent speed improvements. In this tool, we are talking potentially minutes under PyMEL to scan the scene as opposed to under 30 seconds, for heavy of geometry. I had a trivial comparison benchmark that I used in my "Python for Maya Artists Vol 02" training video. Reposted it here: https://gist.github.com/anonymous/4597cf363e37d7c74ed0 I'm sure other types of operations would produce different degrees of performance differences. Some reasonable and some not. As you can see in my example, we aren't seeing 350x or 25x differences. But we are seeing noticeable ones, if someone is waiting for an operation to complete. I would say that it would definitely not be an issue for stuff like you mentioned, where you are loading things or interacting with the scene in ways that don't involve lots of iteration. A single call isn't going to cause any kind of impact. It is when you have to make many many calls to PyMEL and it creates lots of its objects, that it becomes noticeable. > As Justin mentioned and as with any framework, there is the additional > layer of errors you will need to get comfortable with and this was the > killer for me. Again, this might not have been the killer if I gave it a > try today, but at that time I found myself digging into the PyMEL docs > first, the Maya docs next and lastly the Python docs and it seemed like one > too many layers of debugging considering the rather small amount of gain I > got out of using PyMEL in the first place. (The second most motivating > thing, beyond less lines of code, was the feeling of being an early > adopter, something that doesn’t apply today that we’ve gotten some > perspective) > > The reason I never got back into PyMEL was simply due to not having the > need. I think this also resonates with what Justin was saying above about > maya.cmds not being complete, but sufficient. The majority of the code > that I write has little to do with Maya and whenever I need to interface > with it its usually to offload the end-results of some computation having > been performed. As an example, I might run cmds.file() to load a file for > which a path has been computed from a number of factors, each unrelated to > the Maya application itself, such as the currently logged in user, a > project, environment variables or various options from a GUI. Another one > may be to retrieve the node-tree using cmds.ls() and from there perform > any processing in pure Python and PyQt and such. > > I’d say that because the vast majority of my code is spent not interfacing > with Maya, the (potentially) slight productivity increase from using a > framework such as PyMEL isn’t worth the additional learning curve and > debugging effort for me, though I agree with Justin that it is a major > achievement and is without doubt very useful areas other than those I’m > involved in. > > As a side note, I would argue that developing using any of the Python > libraries provided by Maya is to be avoided or delayed as much as possible. > It’s important to keep your code independent and reusable and any > connection to Maya cuts a pretty broad cord. PyMEL is a step away from this > direction as you are encouraged to write more with it but it also > introduces additional objects to pass around your otherwise decoupled code. > > Best, > Marcus > > > > On 4 July 2014 04:51, yury nedelin <[email protected]> wrote: > >> Pymel is object oriented. >> And that's a great python feature that is missing in Maya.cmds . Hamish >> makes a point about performance. It is true its slower then Mel but if you >> really want speed go with api for few times speed is important. Do not >> write a new ik solver with pymel but you probably will not write it in >> .cmds ether. Pymel is here for you to make you get results faster. Not to >> get your results run faster. You choose what you need for the job and use >> what fits best. Pymel is great another tool in the toolbox and it ships >> with Maya so they think its worthy. >> On Jul 3, 2014 7:10 PM, "Jeremy YeoKhoo" <[email protected]> wrote: >> >>> Just remember the post by Hamish MacKenzie. But this was a few years >>> ago. Which put me off pyMel in the first place. >>> >>> MacaroniZoo <http://www.macaronikazoo.com/?p=271> >>> >>> >>> On Friday, 4 July 2014 12:06:52 UTC+10, Jeremy YeoKhoo wrote: >>>> >>>> Hey guys, >>>> >>>> I want to ask your personal opinion of pyMel. After reading the topic >>>> on Monkey Patching the Maya API >>>> <http://christophercrouzet.com/blog/post/2014/06/23/From-Monkey-Patching-the-Maya-Python-API-to-Gorilla-and-Bananas> >>>> by Christopher Crouzet and an earlier discussion regarding this topic in >>>> this forum >>>> <https://groups.google.com/forum/#!topic/python_inside_maya/cLdkFBAgRtI> >>>> , I started thinking back to pyMel and wondered if it might be an >>>> answer, I feel like kicking myself for disregarding PyMel previously. I >>>> have just realised how pythonic and how pyMel holds more of a object >>>> oriented paradigm as opposed to MEL and maya.cmds (even described by >>>> Autodesk >>>> <http://download.autodesk.com/us/maya/2011help/PyMel/why_pymel.html>) >>>> >>>> So I have a few queries, Pymel is now being shipped with Maya, but not >>>> supported by Autodesk which my have production implications. >>>> >>>> What do you guys think of Pymel? >>>> >>>> -Jeremy >>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/451a3ffd-28b5-4bea-abd9-a555d8863aec%40googlegroups.com >>> <https://groups.google.com/d/msgid/python_inside_maya/451a3ffd-28b5-4bea-abd9-a555d8863aec%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CACqGScjNR8g_uvM0fEn%3D-aNgmJkvQ94RRgA8n8DXRqjidJHDFA%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CACqGScjNR8g_uvM0fEn%3D-aNgmJkvQ94RRgA8n8DXRqjidJHDFA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *Marcus Ottosson* > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA%3Dpx3rL0q%2BqDtNaeUjRdWMC1PncHMS33%2B69r40bDfY-g%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA%3Dpx3rL0q%2BqDtNaeUjRdWMC1PncHMS33%2B69r40bDfY-g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1hQukM01ocXzDuJXPv6dxL61edq_Zcoh3mUMQs5DCXwQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
