questions about pymel
106 views
Skip to first unread message
daganael
Dec 11, 2009, 11:47:49 AM12/11/09
to python_inside_maya
Hi,
First, sorry for those who may have read this allready somwhere else,
as we posted in several places.
So, we are a rigging team, here at Mac Guff Ligne, and we are moving
forward to add Pyhton to our rigging toolSet (finaly!).
Even if we are beginner in Python, we understand the benefits of it
(its object oriented nature, the vast amount of available libraries,
large community, etc...), and we know that the standard implementation
of it in maya should/could have been much more deep and powerful, as
Pymel seems to prove.
We read a lot about it everywhere, and it seems that pymel is a very
powerful example of what the implementation could have been, both on
object and api sides.
We are truly enthousiasts about using pymel but our R&D department is
almost against the use of pymel.
Their arguments are:
- Probable issues and the support it might need.
- As this projet doesn't belong to Autodesk si it may stop at any
time.
- Major changes in pymel future versions may occur and obsolete large
portions of our code
- As it's another layer of code, it brings its own bugs.
- OpenSource
Our arguments are (based on various readings over the net):
- The ObjectOriented implementation rocks.
- Smaller and clearer code, thus faster development.
- Smarter Api integration.
- OpenSource (^^)
So at last, we decide to turn to the community in order to gather the
maximum pros and cons.
We'll be glad to hear from everyone (Pymel developpers opinion, of
course, is a must), for any advice, known issues, problem with support/
continuity, knowledge and experience you have and of course everything
you can think about it!
Thank's for the time you may spend to reply.
- MglRigTeam -
First, sorry for those who may have read this allready somwhere else,
as we posted in several places.
So, we are a rigging team, here at Mac Guff Ligne, and we are moving
forward to add Pyhton to our rigging toolSet (finaly!).
Even if we are beginner in Python, we understand the benefits of it
(its object oriented nature, the vast amount of available libraries,
large community, etc...), and we know that the standard implementation
of it in maya should/could have been much more deep and powerful, as
Pymel seems to prove.
We read a lot about it everywhere, and it seems that pymel is a very
powerful example of what the implementation could have been, both on
object and api sides.
We are truly enthousiasts about using pymel but our R&D department is
almost against the use of pymel.
Their arguments are:
- Probable issues and the support it might need.
- As this projet doesn't belong to Autodesk si it may stop at any
time.
- Major changes in pymel future versions may occur and obsolete large
portions of our code
- As it's another layer of code, it brings its own bugs.
- OpenSource
Our arguments are (based on various readings over the net):
- The ObjectOriented implementation rocks.
- Smaller and clearer code, thus faster development.
- Smarter Api integration.
- OpenSource (^^)
So at last, we decide to turn to the community in order to gather the
maximum pros and cons.
We'll be glad to hear from everyone (Pymel developpers opinion, of
course, is a must), for any advice, known issues, problem with support/
continuity, knowledge and experience you have and of course everything
you can think about it!
Thank's for the time you may spend to reply.
- MglRigTeam -
JP
Dec 11, 2009, 12:56:22 PM12/11/09
to python_inside_maya
Howdy,
I've been getting familiar with PyMel over the past few months, and
have found it a treat to work with.
As far as support - I suppose you can't give your R&D team the comfort
that a full-fledged support contract might provide, but I can say from
(recent) personal experience that Chad from Luma is awesome about
answering questions on the CGTalk forums and at this group. In fact,
I just posted a problem I was having a couple days ago and within a
day or so Chad looked at my code and helped me diagnose the problem.
Also, lets say you start writing tools for Maya 09 with the current
PyMel version (0.9.2). If there's something that you discover in this
release that doesn't work properly, you can always code around with
with good ol' maya.cmds. After writing your tools, you don't *need*
to upgrade if new PyMel versions are released until some new feature
in Maya 2011 or whatever forces an upgrade. And at the point where
the studio upgrades Maya, I would assume there would be some extensive
testing before rolling it out anyways. I would also assume an upgrade
wouldn't take place in the middle of a fast-paced production, so
hopefully you'll have time to solve any issues that may arise.
From a cost/benefit standpoint I think that PyMel is a big winner -
because it costs nothing! I've been able to develop probably 30%
faster using PyMel than without it.
Now I have to qualify my comments by saying that I'm currently a
student at Gnomon, so I haven't coded in production :) That being
said, I did work as a IT/systems auditor for PricewaterhouseCoopers
before jumping into CG, so I have some understanding of the risk
analysis that you're going through.
Anyways, hope this is some help, or at least gives you something to
think about. Good luck!
-JP
I've been getting familiar with PyMel over the past few months, and
have found it a treat to work with.
As far as support - I suppose you can't give your R&D team the comfort
that a full-fledged support contract might provide, but I can say from
(recent) personal experience that Chad from Luma is awesome about
answering questions on the CGTalk forums and at this group. In fact,
I just posted a problem I was having a couple days ago and within a
day or so Chad looked at my code and helped me diagnose the problem.
Also, lets say you start writing tools for Maya 09 with the current
PyMel version (0.9.2). If there's something that you discover in this
release that doesn't work properly, you can always code around with
with good ol' maya.cmds. After writing your tools, you don't *need*
to upgrade if new PyMel versions are released until some new feature
in Maya 2011 or whatever forces an upgrade. And at the point where
the studio upgrades Maya, I would assume there would be some extensive
testing before rolling it out anyways. I would also assume an upgrade
wouldn't take place in the middle of a fast-paced production, so
hopefully you'll have time to solve any issues that may arise.
From a cost/benefit standpoint I think that PyMel is a big winner -
because it costs nothing! I've been able to develop probably 30%
faster using PyMel than without it.
Now I have to qualify my comments by saying that I'm currently a
student at Gnomon, so I haven't coded in production :) That being
said, I did work as a IT/systems auditor for PricewaterhouseCoopers
before jumping into CG, so I have some understanding of the risk
analysis that you're going through.
Anyways, hope this is some help, or at least gives you something to
think about. Good luck!
-JP
Paul Molodowitch
Dec 11, 2009, 1:24:32 PM12/11/09
to python_in...@googlegroups.com
Ok, well, first of all, let me say I'm a contributor to the pymel project, so I'm hardly an unbiased opinion. =P
However, here's my take:
First of all, as far as having issues... well, I could go on about how hard we've worked to try and eliminate bugs (we currently have ~ 1450 unit tests, I believe)... and mention that it's been used successfully in major studios... but any software has bugs. However, I would argue that, despite the lack of official support, it's actually easier to fix / find a workaround for a pymel bug than it is for a "normal" autodesk one.
First of all, there's the fact that it's OpenSource - all your normal debugging options are open to you, and if you find the root source of the problem, you can fix it yourself. With a regular maya command, it's generally a black box... and even if you know the exact conditions that cause the problem, can reproduce it reliably, and submit a ticket to autodesk... well (assuming the ticket gets noticed and given a high-enough priority to get fixed), simply due to the nature of Maya's corporate release schedule, you'll likely have to wait a while before you see the fix incorporated into Maya. Due to the fact that we're open source, you can access any pymel fixes as soon as we make them.
Secondly, consider that while, yes, pymel will inevitably have bugs in it's own code, it ALSO fixes/hides a number of bugs in maya's own code. Plus, it allows you to avoid, ah, 'confusing' elements of maya's python implementation which, while not technically bugs in and of themselves, are likely to introduce bugs of their own. (*cough* MScriptUtil *cough*). Then there's the simple fact that it can drastically reduce the number of lines of code it takes to write a program... and more lines of code mean a higher the probability of a bug.
Remember, too, that pymel is NOT an either-or question. It's another tool in your toolset. If you are having problems with pymel (or suspect you are), you can quite easily fall back on the standard maya.cmds, or mix those in with pymel commands.
As a final note on the whole 'support' question, while we may not be an 'official' support mechanism, Chad and I try to be as helpful as we can... as do a large number of other folks on this list.
As far as pymel going 'poof'... well, of course, nothing is ever guaranteed. But the chances of pymel dying at anytime in the near future are, ah... slim, to say the least. It's very tightly integrated into our pipeline here at Luma, so even if nobody else were using it, we would keep on developing it. And Autodesk is very aware of pymel's existence, and it's user base. We have a fairly good relationship with Autodesk, and they know that doing something which would break pymel is not in their best interest.
Anyway, that's my take... I'm sure others have different views. =)
- Paul
However, here's my take:
First of all, as far as having issues... well, I could go on about how hard we've worked to try and eliminate bugs (we currently have ~ 1450 unit tests, I believe)... and mention that it's been used successfully in major studios... but any software has bugs. However, I would argue that, despite the lack of official support, it's actually easier to fix / find a workaround for a pymel bug than it is for a "normal" autodesk one.
First of all, there's the fact that it's OpenSource - all your normal debugging options are open to you, and if you find the root source of the problem, you can fix it yourself. With a regular maya command, it's generally a black box... and even if you know the exact conditions that cause the problem, can reproduce it reliably, and submit a ticket to autodesk... well (assuming the ticket gets noticed and given a high-enough priority to get fixed), simply due to the nature of Maya's corporate release schedule, you'll likely have to wait a while before you see the fix incorporated into Maya. Due to the fact that we're open source, you can access any pymel fixes as soon as we make them.
Secondly, consider that while, yes, pymel will inevitably have bugs in it's own code, it ALSO fixes/hides a number of bugs in maya's own code. Plus, it allows you to avoid, ah, 'confusing' elements of maya's python implementation which, while not technically bugs in and of themselves, are likely to introduce bugs of their own. (*cough* MScriptUtil *cough*). Then there's the simple fact that it can drastically reduce the number of lines of code it takes to write a program... and more lines of code mean a higher the probability of a bug.
Remember, too, that pymel is NOT an either-or question. It's another tool in your toolset. If you are having problems with pymel (or suspect you are), you can quite easily fall back on the standard maya.cmds, or mix those in with pymel commands.
As a final note on the whole 'support' question, while we may not be an 'official' support mechanism, Chad and I try to be as helpful as we can... as do a large number of other folks on this list.
As far as pymel going 'poof'... well, of course, nothing is ever guaranteed. But the chances of pymel dying at anytime in the near future are, ah... slim, to say the least. It's very tightly integrated into our pipeline here at Luma, so even if nobody else were using it, we would keep on developing it. And Autodesk is very aware of pymel's existence, and it's user base. We have a fairly good relationship with Autodesk, and they know that doing something which would break pymel is not in their best interest.
- Paul
David Moulder
Dec 11, 2009, 1:51:54 PM12/11/09
to python_in...@googlegroups.com
Hi daganael,
Eurocom went through a similar debate when we started to move from mel to python. At the time we were just learning OOP with python. We struggled to write Python in a OO way because of the cmds wrapping. We also had problems mixing our python code with our extensive mel code base. pymel.melGlobals[] and pymel.mel.myMelScript() realy went a long way to bridging the gap for us. Since we started to play and investigate Python it was a NATURAL progression/realisation that we could be doing things much more intutetively. So 6 months of writing code with python the pymel argument/discussion we were having internally faded. Lets just say the pro's out weighed the con's.
My 2 pennies,
-Dave
Eurocom went through a similar debate when we started to move from mel to python. At the time we were just learning OOP with python. We struggled to write Python in a OO way because of the cmds wrapping. We also had problems mixing our python code with our extensive mel code base. pymel.melGlobals[] and pymel.mel.myMelScript() realy went a long way to bridging the gap for us. Since we started to play and investigate Python it was a NATURAL progression/realisation that we could be doing things much more intutetively. So 6 months of writing code with python the pymel argument/discussion we were having internally faded. Lets just say the pro's out weighed the con's.
My 2 pennies,
-Dave
Ofer Koren
Dec 11, 2009, 11:24:07 PM12/11/09
to python_in...@googlegroups.com
I keep arguing that in the absence of pymel we'd just end up writing our own private maya.cmds wrappers/util-libraries/helper-modules/bug-fixer-modules sooner or later (that's Chadrik's story pretty much).
But then you don't have the benefits of a collaborative project, the expertise of solid python architects that design and abstract the library to fit all uses, and the much larger user community to test and debug it.
pymel is also useful as an abstraction layer between the pipeline tools and the underlying maya implementation, which actually allows a studio for much greater flexibility when it comes to upgrading maya versions. By having tools go through the pymel layer one is able to change some default behaviors based on the pipeline needs in a centralized manner.
Reply all
Reply to author
Forward
0 new messages