On Apr 17, 4:27 pm, Jawabiscuit <[email protected]> wrote:
> This is interesting stuff!  Anyone have modules besides pickle they
> want to share about?

Well, I would also recommend taking a look at a very Maya specific
module called MRV. It is an extraordinary piece of work, that seems to
have been almost entirely done by one guy, who deserves some
recognition IMHO. It focuses on the API side of things, where Pymel is
a bit more focused on the MEL side of things. The two are
complementary in many ways, but they are also a bit incompatible which
is something that you have to bear in mind if you decide to use MRV.

MRV is actually pretty amazing. Dunno if you have written many API
tools/contexts for Maya, but one thing that is pretty annoying about
that is that it is very hard to get undo to work properly within a
Maya context. Hard enough that basically everyone who uses Maya knows
that you just can't reliably undo while using a tool. MRV has a whole
module/plugin that pretty much fixes this. I showed this to some co-
workers at our studio and they were amazed that I had undo working in
a context without doing _anything_ other than importing a Python
module and making a couple of calls. I'm working on a commercial plug-
in, and that would be a real selling-point for us, but...

The downside of MRV is that it patches a lot of stuff in Python for
Maya. Almost all of the patches are very reasonable. For instance,
once you have imported MRV MVectors and MPoints have a reasonable
print representation. Which is great. But I can't ship a commercial
plug-in that changes even the print behavior of those classes, because
you know that somewhere out there there is someone with a pipeline
that relies on how Python for Maya prints those classes.

MRV makes more important changes as well. In order to allow Pythonic
iteration MRV adds a __len__ method to a number of API classes,
including MPlug. This works OK with Python for Maya, but is
incompatible with PyMel, since PyMel checks the truth value of MPlugs
when printing Attributes, and throws an exception if they evaluate to
False. Since non-array MPlugs have length zero they evaluate as False.
I've patched this by adding a __nonzero__ method to MPlug, in our
software, but we clearly can't ship software that relies on things
like this, so we're going to have to take MRV out before we ship, and
re-implement the bits we use in a way that doesn't require modifying
classes at run-time.

None of the above should be taken as a criticism of Pymel or MRV. Both
are really solid pieces of work. We wanted to move fast at the
beginning of development, and MRV helped us do that (and Pymel is
really helping us now.) I knew, almost from the beginning, that we
would have to eventually remove the MRV dependency, so we limited our
use of it- we will have to give up the nice undo, but we can replace
everything else we used in a day or two of work. What we used really
sped us up, at a time when we needed it. Some of the above _could_ be
taken as a criticism of Autodesk's integration of Python into Maya.
Seems very slapdash to me, but I guess we all know that, and if that
weren't the case there would be no Pymel.

I had to say all that before strongly recommending MRV because it's
important to understand how it interacts with the standard Maya
environment before using it. There are a lot of cases where you you
just can't use it because it might step on other things. But there are
also a lot of cases where you can use it, particularly for in-house
tools run from the command-line. MRV is so useful in cases like that
that it would be folly to ignore its existence, IMHO. Sebastian Thiel
should be commended for building, almost single-handedly, such a great
library. Check it out.

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

Reply via email to