PyMel: ParentConstraint

[Subbu]

Hi,

When am trying in Python, Its working as below:
import maya.cmds as cmds
pCon =cmds.parentConstraint('pCube1', 'pCube2', mo=1, w=1)


but in PyMel, Both the following are not working

import pymel.core.nodetypes as nt
pCon =nt.ParentConstraint('pCube1', 'pCube2', mo=1, w=1)
or
pCon =nt.ParentConstraint( PyNode('pCube1'), PyNode('pCube2'), mo=1,
w=1)

"Error: Unable to determine pymel type for 'pCube1' " is coming


In single line it is not possible in PyMel, But its working in 3 lines
like this:
import pymel.core.nodetypes as nt
select ('pCube1', r=1)
select ('pCube2', add=1)
pCon =nt.ParentConstraint(mo=1, w=1)

Any one has any idea, so that I can save 2 lines code in this case,
Constraints are repetitive in my code

Thanks in advance.

Subbu

[Paul Molodowitch]

Hi Subbu -

Unfortunately, the PyNode classes (such as pm.nt.ParentConstraint) do not contain all of the functionality of the corresponding commands (ie, pm.parentConstraint or cmds.parentConstraint).  In particular, the initial creation of the underlying MAYA node must often be done with the command form.  In fact, the only way it is currently possible to trigger the creation of the underlying maya node AND the pynode with the pynode constructor is when the PyNode constructor is fed no non-keyword args  (such as when you do nt.ParentConstraint(mo=1, w=1) ).  If you need to create the underlying node in manner in which you feed in other node args, you'll have to fall back on the command:

import pymel.core as pm

cube1 = pm.polyCube()[0]

cube2 = pm.polyCube()[0]

pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1)

In general, my habit is often to use the commands to create, and the PyNode class constructors to create PyNodes for already-existing maya nodes.  I agree, though, that it would be nice to expand support for node creation in 

- Paul

PS - Did you know it's also possible to do the selection of multiple objects in a single step? ie,

select ('pCube1', 'pCube2')

--
http://groups.google.com/group/python_inside_maya

[John Patrick]

Personally, I feel like I wouldn't be served well by having the PyNode class constructor handle node creation.  After all, it's the command's job to create the node and hook it into the DG.  I think, if anything, there maybe could be a class method that does a createNode() and returns a PyNode instance of that node...but even then, it's pretty easy to do pm.PyNode(pm.createNode('transform'))

That being said, maybe there's a situation where using the PyNode constructor like a command would be convenient, I just haven't run into one :) 

-JP

On Wed, Apr 20, 2011 at 7:33 AM, Paul Molodowitch <elro...@gmail.com> wrote:

Oops... correction below:

On Wed, Apr 20, 2011 at 7:28 AM, Paul Molodowitch <elro...@gmail.com> wrote:

Hi Subbu -

Unfortunately, the PyNode classes (such as pm.nt.ParentConstraint) do not contain all of the functionality of the corresponding commands (ie, pm.parentConstraint or cmds.parentConstraint).  In particular, the initial creation of the underlying MAYA node must often be done with the command form.  In fact, the only way it is currently possible to trigger the creation of the underlying maya node AND the pynode with the pynode constructor is when the PyNode constructor is fed no non-keyword args  (such as when you do nt.ParentConstraint(mo=1, w=1) ).  If you need to create the underlying node in manner in which you feed in other node args, you'll have to fall back on the command:

import pymel.core as pm

cube1 = pm.polyCube()[0]

cube2 = pm.polyCube()[0]

pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1)

In general, my habit is often to use the commands to create, and the PyNode class constructors to create PyNodes for already-existing maya nodes.  I agree, though, that it would be nice to expand support for node creation in 

PyNode class constructors to be able to handle these situations as well.

--
http://groups.google.com/group/python_inside_maya

--
John Patrick
404-242-2675
jspa...@gmail.com
http://www.canyourigit.com

[Judah Baron]

Not directly related to this thread, but it is related to parentConstraints....

Has anyone noticed that parentConstraint offset rotations are not calculated correctly for nodes with parents that have negative scale? When the same thing is attempted, but using an orient constraint instead, the correct offset values are generated.

On Wed, Apr 20, 2011 at 7:33 AM, Paul Molodowitch <elro...@gmail.com> wrote:

Oops... correction below:

On Wed, Apr 20, 2011 at 7:28 AM, Paul Molodowitch <elro...@gmail.com> wrote:

Hi Subbu -

Unfortunately, the PyNode classes (such as pm.nt.ParentConstraint) do not contain all of the functionality of the corresponding commands (ie, pm.parentConstraint or cmds.parentConstraint).  In particular, the initial creation of the underlying MAYA node must often be done with the command form.  In fact, the only way it is currently possible to trigger the creation of the underlying maya node AND the pynode with the pynode constructor is when the PyNode constructor is fed no non-keyword args  (such as when you do nt.ParentConstraint(mo=1, w=1) ).  If you need to create the underlying node in manner in which you feed in other node args, you'll have to fall back on the command:

import pymel.core as pm

cube1 = pm.polyCube()[0]

cube2 = pm.polyCube()[0]

pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1)

In general, my habit is often to use the commands to create, and the PyNode class constructors to create PyNodes for already-existing maya nodes.  I agree, though, that it would be nice to expand support for node creation in 

PyNode class constructors to be able to handle these situations as well.

 

- Paul

--
http://groups.google.com/group/python_inside_maya

[Paul Molodowitch]

Interesting... and here I was, about to announce that I'd expanded support for maya node construction in PyNode class constructors.  You would be able to pass in a special 'createArgs' kwarg that would be passed to the underlying command in create mode.  Ie:

pCon = pm.nt.ParentConstraint(createArgs=(cube1, cube2), mo=1, w=1)

would now be equivalent to:

pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1)

I can see the argument of keeping a clear separation between PyNode construction and maya node construction, as it helps make clear the conceptual difference between the two.  On the other hand, PyNode constructors already support maya node construction when there are no keyword args, and have for a while, so removing support for it is pretty much not possible, as it would break too much existing code.  So my feeling is, if we're going to support it, may as well support it all the way.  Plus, I guess it just feels more like I'm doing real object oriented coding when I'm invoking class constructors. =P Just my two cents though...

Anybody else with an opinion? Should probably get Chad to weigh in on this, too...

- Paul

--

http://groups.google.com/group/python_inside_maya

[Subbu Addanki]

Hi All,

Thanks a lot for replies. You saved my time so much for typing.

pCon = PyNode(parentConstraint(cube1, cube2, cube3, mo=1, w=1))
w1 =pCon.getWeightAliasList()[0]

As shown above, and as said by John Patrick, above command is done in one line and it serves my purpose.
Now I can get drop down menu for '.getWeightAliasList' in ecplise editor for Maya.

::==)) Subbu

--

http://groups.google.com/group/python_inside_maya

--
Regards,
Subbu Addanki
http://subbuadd.blogspot.com/
http://www.vimeo.com/17439975

[Subbu Addanki]

Thanks Mr. Paul for the analysis and solutions on this topic  ::==))

[Paul Molodowitch]

Oops... correction below:

On Wed, Apr 20, 2011 at 7:28 AM, Paul Molodowitch <elro...@gmail.com> wrote:

Hi Subbu -

Unfortunately, the PyNode classes (such as pm.nt.ParentConstraint) do not contain all of the functionality of the corresponding commands (ie, pm.parentConstraint or cmds.parentConstraint).  In particular, the initial creation of the underlying MAYA node must often be done with the command form.  In fact, the only way it is currently possible to trigger the creation of the underlying maya node AND the pynode with the pynode constructor is when the PyNode constructor is fed no non-keyword args  (such as when you do nt.ParentConstraint(mo=1, w=1) ).  If you need to create the underlying node in manner in which you feed in other node args, you'll have to fall back on the command:

import pymel.core as pm

cube1 = pm.polyCube()[0]

cube2 = pm.polyCube()[0]

pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1)

In general, my habit is often to use the commands to create, and the PyNode class constructors to create PyNodes for already-existing maya nodes.  I agree, though, that it would be nice to expand support for node creation in 

PyNode class constructors to be able to handle these situations as well.

 

- Paul

[John Patrick]

Hey, don't let me rain on your parade!!  It sounds like you have a valid point, given how the constructors are set up currently.  And I'll agree, it does feel a little more satisfying to instantiate the classes directly :P

I think the main downside is that it may be confusing for those new to PyMEL, since it's a little redundant...but that may not be enough reason not to support it.

-JP

[David Moulder]

I suppose you could have a .createCmd() classmethod instead of the kw args and leave the current constructor as it is?

I saw this on a PyCon video the other day.  It's widely accepted that you should create multiple constructor methods rather then 1 complicated method and where possible stick to already used conventions in the python standard library as a naming convention. 

Also, in the exmaple above I'd expect the result of the cmd to return a PyNode?

pCon = parentConstraint(cube1, cube2, cube3, mo=1, w=1)

instead of

pCon = PyNode(parentConstraint(cube1, cube2, cube3, mo=1, w=1))

but saying that I have done the later in some instances.

-Dave

--
http://groups.google.com/group/python_inside_maya

--
David Moulder
http://www.google.com/profiles/squish3d

[Count Zer0]

> That being said, maybe there's a situation where using the PyNode
> constructor like a command would be convenient, I just haven't run into one
> :)

Nah man,

You definitely want to create all objects with PyMEL classes, that way
you get an instance object and method completion in your Script Editor
or IDE.

No need to worry about importing in Maya2011/2012. This works straight
up:

cube1 = polyCube()[0]
cube2 = polyCube()[0]
pCon = parentConstraint(cube1, cube2, mo=1, w=1)

Then type 'pCon.' in your Editor/IDE and watch the code-completion
save your day. Even if you're using older Maya you can go ahead and
import with asterisk and not have to worry about namespaces, like
this:

from pymel.core import *

If you are not embracing PyMEL at this point, you are falling way
behind the curve. Those who are, are racing ahead writing tons of
readable, powerful OOP maya code, super-duper fast. Just sayin.

[John Patrick]

We're not talking about using pymel or not - when I say command, I mean a pymel command (which returns a PyNode instance) vs. maya node creation via direct instantiation of a pymel class.  You're using the command in your example, for instance :)

As an aside, I still don't like to import everything from pymel into the root namespace.  It's too easy for me to accidentally overwrite things (even though it's perfectly safe if you're more careful).

--

http://groups.google.com/group/python_inside_maya

[Count Zer0]

You're right. I just copied the example above.

Not much of a difference using command or class for instanciation:

from pymel.core.nodetypes import PolyCube
cube1 = PolyCube()

both return PyNodes.

And importing into root namespace is very much a preference thing. I
know everybody imports differently. I oscillate between lazy importing
into root namespace and importing in just the modules/commands I need.
Just glad to see another PyMEL user, JP.

> jspatr...@gmail.comhttp://www.canyourigit.com