PDA

View Full Version : examples of pymel in 2012 for a beginner?

 LML06-17-2012, 10:32 PMhi all, I've done some hunting around and am having trouble finding some good, basic examples of beginner pymel tasks (I'm using maya 2012--and I'm coming at it from an artists perspective, not as a budding TD). I've seen the "getting started" documentation, and a few other things here and there, but haven't found enough to get that critical understanding to start doing it on my own. would be great just to see some things like: create an object access some random verts move those verts around (maybe along a normal) set some keyframes for an animation or create a curve manipulate the cv's sweep something set some keyframes stuff like that--maybe these aren't the best examples :) , but if you've run across some good basic stuff like this somewhere online or elsewhere, would love to hear it cheers LML
zoharl
06-19-2012, 12:28 AM
http://autodesk.com/us/maya/2011help/PyMel/tutorial.html

For example:

import pymel.core as mc
# Create a plane
objs = mc.polyPlane()

# Get shape
plane = objs[0]
shape = plane.getShape()

# Show info about the vertex class
`shape.vtx[0]` # or repr(shape.vtx[0])
# Result: MeshVertex(u'pPlaneShape1.vtx[0]')
# Print help on the class
help(mc.MeshVertex)

# Let's try some methods from the help
shape.vtx[0].getPosition()
# Result: [-0.5, -1.11022302463e-16, 0.5] #
shape.vtx[0].setPosition([1,1,1])

# Standard mel functions are still available:
mc.setKeyframe(shape.vtx[0], breakdown=0, t=1)
shape.vtx[0].translateBy([1,1,1])
mc.setKeyframe(shape.vtx[0], breakdown=0, t=2)

Exercise: Do the same thing for a curve.

LML
06-19-2012, 12:51 AM
will try it out
thanks a lot
LML

LML
06-19-2012, 01:08 AM

how important is importing with a namespace, i.e. "pm" or "mc"?

does this in anyway effect the object oriented nature of python?

how would you go about "stringing together" a few of these commands with dot syntax, or is that even applicable here?

zoharl
06-19-2012, 02:05 AM
In the link above you have a red warning which explains the pitfalls of working without a namespace (which of course you can import in any name as you like), I prefer to work with, and I can't see how it would affect the OOP nature.

Even without pymel, expression nesting ('stringing') in python is inherent (unlike mel). This expression:

shape.vtx[0].getPosition()

actually is nested. First vtx() is called (as an array operator), then the getPosition() is called for the returned object (okay, not the perfect example, but you get the idea...).

djx
06-19-2012, 10:31 AM
zoharl has demonstrated that you can import anything into any namespace, but his example could be confusing for a beginner. I have never seen anyone import pymel.core as mc before.

It is almost convention to import pymel.core as pm and maya.cmds as either cmds or mc. The majority of examples you will read elsewhere will be using these quasi conventions.

Its totally up to you though.

David

zoharl
06-19-2012, 12:16 PM
About the convention: The pymel doc (the link above) actually imports pymel into the root namespace. I couldn't find many pymel examples, and LML can attest to that. So I'm not sure about the convention.

I use mc for both, since pymel actually replaces the maya.cmds. Thus it easier this way to convert my scripts to use/not use (due to some bugs in pymel) pymel.

And yes, the namespace can be anything.

djx
06-19-2012, 12:46 PM
Of the pymel examples I have seen (agreed, there are not that many around, but still) most (if not all) import pymel as pm. And most of the maya.cmds examples import as cmds (as in the docs) or mc (less frequent). I'm sure (from my experience teaching others) that a python beginner, who is still trying to understand the difference between maya.cmds and pymel, would find the use of the mc namespace for pymel to be unnecessarily confusing and counter-intuitive.

Lets be honest, pymel does not replace maya.cmds. Both have their place. Some like one more than the other. I am not an expert but I read and write a fair amount of python on a daily basis and it would really bug me if one of my co-workers started using the mc namespace for pymel.

David

zoharl
06-19-2012, 01:04 PM
David, since I'm the newbie here, I'll differ to your opinion, but still I would like you to elaborate on your reasoning. From what I understand pymel fully replaces cmds, and you shouldn't (for me it's never) mix between the two, i.e. import and use both name spaces in the same script. The reason for this is that it's confusing (especially for a beginner) because of the redundancy - you are aware that pymel imports the cmds almost fully?

djx
06-19-2012, 02:23 PM
I actually think you probably have a more in-depth coding knowledge than I do.

I wont attempt to argue either side of the pymel vs. maya.cmds argument. I have read solid arguments for both. It is worth remembering in these discussions that even though pymel is shipped with maya, it is not developed (or supported ? ) by autodesk. Personally I like writing pymel because of its object-oriented nature, and the way functions return objects instead of strings. But, I have found some cases where maya.cmds work and pymel does not (for example, using viewport2 with the modelEditor and modelPanel commands seems to be more reliable with cmds).

Using namespaces like pm and cmds allows you to mix both without conflict. I would not recommend doing this as a rule, but sensible and consistent choices of a namespace names always makes your code easier to read by other people. Using mc as a namespace for pymel in an example for a beginner, is a bad choice in my opinion.

David

NaughtyNathan
06-19-2012, 03:37 PM
pyMel has been specifically designed to be imported into the root namespace:
from pymel.core import *so if you do do:
import pymel.core as pm # or as anything elseyou are basically spitting on Chad and all of his hard work. :) ;)

(and anyone who does "import pymel.core as mc" is a deranged screwball!)

DagMX
06-19-2012, 04:26 PM
pyMel has been specifically designed to be imported into the root namespace:
from pymel.core import *so if you do do:
import pymel.core as pm # or as anything elseyou are basically spitting on Chad and all of his hard work. :) ;)

(and anyone who does "import pymel.core as mc" is a deranged screwball!)

Haha, but there is something to be said for organizing things into namespaces.

@djx
There are a very few instances I've run into where pymel has errors, fatal crashes or is just slow, and for those I'll go back to maya.cmds and mix it in.

By the way, does pyMel inherit new additions to cmds?
ie if I create a new API plugin that add a 'foo' cmd
can I do pm.foo() to call it or do I have to do cmds.foo() ?

zoharl
06-19-2012, 04:47 PM
Nathan, I'm happy to hear that you finally started playing with pymel. But I didn't get the joke/reason about importing pymel to the root namespace, especially considering the red warning in my link above.

Beginners, I suggest that you take David advice on this. A convention by definition is a convention, and usually doesn't have reasoning. David is more immersed in the industry than me (I am more of a freestyler), and if he feels that there's such a convention, then it should be followed.

Nevertheless I'll try to explain my intuition here. I see pymel as a small (but nice and important) extension to python, and actually all the big deal here (not to underestimate the work that has been done here in any way, but to encourage people to use it) is the addition of methods to objects (or more exactly declaring objects for the nodes). It can be mixed freely with the standard cmds, and it's just a matter of taste to use pointPosition(p) or p.getPosition(). Most people would find the later more intuitive and easier, and in general I think it's easier to go to the class help and find its relevant method, than to guess the mel command that should be relevant to the node and accomplish what you want (e.g. xform() - how the hell should a beginner find this function.).
Personally I mix both of them in a script, and thus I don't see pymel as a different package or language, like other people might classify. To our convenience pymel imports almost all the cmds, so it seems like just a matter of replacing the current package (cmds) with a new package (pymel), and continue programming as usual, with the new added object methods. And yes, as David noted (and I referred previously as pymel bugs), pymel doesn't always keep pace with cmds, and rarely I also import cmds specifically for this occasion. In case that I didn't use pymel in the script, it actually just a matter of importing cmds into mc instead of pymel (but again, apparently it's against the convention, so try to avoid it).

EDIT: extension to python of course

djx
06-20-2012, 01:07 AM
(Exterior Dagobah, jungle, swamp, and mist.) (http://python.net/%7Egoodger/projects/pycon/2007/idiomatic/handout.html)

LUKE: Is from module import * better than explicit imports?
YODA: No, not better. Quicker, easier, more seductive.
LUKE: But how will I know why explicit imports are better than the wild-card form?
YODA: Know you will when your code you try to read six months from now.

The python getting started says:
PyMEL is designed to be safe to import into the root namespace so that scripts can be written much more concisely. However, if you are a python novice, you might want to keep pymel in its own namespace, because, unlike in MEL, in python you can “overwrite” functions if you are not careful

David

gtbull80
06-20-2012, 03:31 AM
Check me out: