I’ve been using PyMel a lot recently and have become a huge fan - my code is much more concise and I love being able to treat my nodes as objects. But right now I’m iterating our character pipeline for the next project, and can’t decide if building it on PyMel is a good idea. Particularly because it still feels like magic voodoo to me.
Does anyone have any warnings or blessings for me? In particular, i’d love to hear about any cases where PyMel caused errors that were difficult to track down, or where it gave you enough rope to hang yourself. But i’m kind of crossing my fingers you guys will be all: “OMG it just made my life better and i never looked back!”
I’m going to have to go with “OMG it just made my life better and i never looked back!”
The only real caveat i can think of is that if you’re going to really make use of all of PyMel’s facilities, realize that it’s a fundamental break from maya.cmds (ie, strings vs PyNodes, that sort of thing). So if you’re really going to make use of PyMel, it’s sort of a go all in proposition. Also if you want to distribute your tools externally you’d obviously run into some issue, but for inhouse development, i say bite the bullet and make the jump. When i was at Bungie, the concern expressed was that it’s not officially Autodesk supported hence our not using it there, but my response to that is that it’s an open source project, learn the codebase and support it yourself if that’s really that huge of a concern.
For Sure: “OMG it just made my life better and i never looked back!”
Come on man, read the posts everywhere. Everybody loves it. Your only dilemma is the standard Open Source politics, you get through that like Seth says, and there’s no going back.
Object Oriented python objects for your maya nodes. This means real Python, not MEL syntax Python. Maya’s built-in Python looks (and acts) exactly like MEL. Pymel works like the rest of Python. You’ll notice this if you do any other Python coding outside of Maya.
Okay… looks great and sounds great… and solves one of two problems.
Pymel makes Maya’s python integration more pythonic. One problem. Mel\Melthon documentation sucks donkey balls. Now I have a pythonic wrapper around an API whose documentation sucks donkey balls.
That’s one extra layer of abstraction on top ‘sucks donkey balls’. Is there some documentation on it that does not assume that you already know Mel like the back of your hand?
This recently got me while playing around with PyMel. The PyMel documentation seems to have added extra things to Melthon that isn’t there at all. Not sure how many of these exists in PyMel but the one that tripped me up is art3dPaintCtx.afterStrokeCommand/beforeStrokeCommand which doesn’t appear in Melthon.
[QUOTE=ZeroByte;4842]This recently got me while playing around with PyMel. The PyMel documentation seems to have added extra things to Melthon that isn’t there at all. Not sure how many of these exists in PyMel but the one that tripped me up is art3dPaintCtx.afterStrokeCommand/beforeStrokeCommand which doesn’t appear in Melthon.[/QUOTE]
You’ll see alot of that, there are lot of Pymel specific classes that include their own methods not found in maya.cmds. FormLayout and optionVar are two other good examples.
Just as a follow up to this thread, we have some custom locators (defined via a compiled plugin) that don’t play with pymel nicely. This is a relatively complex node that our tools team put together, and since I’ve done very little C++ plugin dev i’m pretty clueless about what kind of request to make of the tools dept. Right now only the tech art team is using pymel, and while the tools dept isn’t actively supporting it i’m sure they’d help me out if I can be specific about what I need.
So the problem occurs if I do any pymel operations on the node. Even simply selecting it:
x = selected()[0]
Gives me:
# Error: 'MObjectHandle'
# Traceback (most recent call last):
# File "<maya console>", line 1, in <module>
# File "c:\dfp-stack\Common/code/Tools/Maya/Python\pymel\core
odetypes.py", line 2724, in __str__
# return "%s" % self.name()
# File "c:\dfp-stack\Common/code/Tools/Maya/Python\pymel\core
odetypes.py", line 2667, in name
# return self._updateName()
# File "c:\dfp-stack\Common/code/Tools/Maya/Python\pymel\core
odetypes.py", line 2656, in _updateName
# self.__apimobject__()
# File "c:\dfp-stack\Common/code/Tools/Maya/Python\pymel\core
odetypes.py", line 2714, in __apimobject__
# handle = self.__apihandle__()
# File "c:\dfp-stack\Common/code/Tools/Maya/Python\pymel\core
odetypes.py", line 2720, in __apihandle__
# return self.__apiobjects__['MObjectHandle']
# KeyError: 'MObjectHandle' #
Does anyone have advice I can share with our tools dept. that might help our node play nice? Thanks!
Stab in the dark, because it’s been a few days with no response for you:
What does maya.cmds.ls(sl=1) return in this same case?
Is this an MPxLocator, MPxSurfaceShape, or MPxNode?
If you use the Maya Python API to get to the MObject manually using an MSelectionList then pull the dependency node from that, then take that object ( should be of type maya.OpenMaya.MObject ) and wrap that in a pyNode, and see if basic operations like changing to position using that pyNode work correctly. If that succeeds, than pyMEL is just not parsing your names correctly. If that fails, then perhaps pyMEL does not properly handle the particular type of MPxNode you’re using.
It looks like you’re seeing a pyNode that has failed to completely initialize, and it is unclear to me exactly why that would occur. It looks like pyMEL tries to decide what type a string is and tries to delegate that to the proper location fairly quickly, perhaps something about your custom node is making it guess incorrectly.
I’m not intimately familiar with pyMEL, this was all gleaned from a cursory glance at nodetypes.py so take this with a grain of salt about the size of the Utah. Hopefully someone with a stronger knowledge of pyMEL will be able to help you. Also, I doubt that whatever the case, complete library authors like the guys behind pyMEL like their code randomly stack-tracing in the middle of it. They would most likely like to guard against this and report to the user a logical error message, so even if this is caused by a bug in your toolchain, it might be worth tossing out the bug to the pyMEL guys and see what happens there.
The PyMel documentation seems to have added extra things to Melthon that isn’t there at all. Not sure how many of these exists in PyMel but the one that tripped me up is art3dPaintCtx.afterStrokeCommand/beforeStrokeCommand which doesn’t appear in Melthon.
zeroByte, as djTom pointed out, pymel adds a number of new commands, but that is not what is going on in this case. pymel requires a lot of data about commands and their flags in order to perform its wraps. it gathers this data by combining info parsed from the docs with info from the MEL help command. during this process pymel may discover undocumented flags and commands. that’s what you are seeing here.
we have some custom locators (defined via a compiled plugin) that don’t play with pymel nicely. This is a relatively complex node that our tools team put together
drew, for some reason, the usual method of getting low-level api objects for your custom node is failing. it’s important that we get this problem fixed.
the first thing you should do is try out the beta of 1.0 (posted in the other thread on this site). if you’re still seeing the problem with 1.0, then it would be great if you can work with your dev team to create the simplest custom node that recreates the problem. then post and issue here http://code.google.com/p/pymel/issues/list along with the code and we’ll sort it out.
Thanks for the help Lithium and Chad! I just grabbed 1.0 and I’ll let you guys know if it fixes it. If not I’ll be sure to get the issue posted on the project site.
Resolution per our lead tools programmer: PyMel doesn’t support custom transforms, only custom shape nodes. He modified the pymel code to remap our custom transform type to the normal transform type, and that seems to make everything better (for my needs at least).
Even though you’ve figured out a solution, I’d like to note that custom transforms defined in python plugins work fine. In earlier versions (0.7) there were some issues where pymel would default the node to a DependNode so I would have to cast it to a transform to use transform commands, i.e:
but at some point that got fixed. For all the random data storage I’ve needed, python plugins have been awesome. No compiling and quick updating = good times. The only draw back is when I did the first one the API is weird and debugging it was tricky but it’s been smooth sailing ever since.
I’m afraid creating a custom transform that exhibits the problem would be a bit more difficult for me as I’ve done zero plugin work (neither in C++ or python). Sorry I can’t be more helpful there.
