Results 1 to 5 of 5

Thread: Integrating PyMel

  1. #1
    Technical Artist
    Join Date
    Jan 2012
    Location
    London
    Posts
    16

    Default Integrating PyMel



    We're planning to integrate PyMel, hurray!

    I was wondering; who's actually using PyMel into their pipeline?

    How do you deal with it?
    - Integrating it into the current pipeline (We have our custom node system similar as PyMel's.)
    - Adding functionality (monky patching?)
    - Transferring between versions. (We will move to Maya 2015 in a couple of months)

    As autodesk just ships PyMel with Maya, I assume https://github.com/LumaPictures/pymel is the official repository?
    The latest version over there fixes the wrapping for our custom nodes..

    Any advice?
    Thanks!

  2. #2
    string
    Join Date
    Jan 2011
    Location
    Guildford
    Posts
    101

    Default

    At both Lionhead and Improbable we use PyMel heavily. Infact it makes up the majority of our pipeline code. Having an object based wrapper to interface with Maya/Nodes makes coding far easier than dealing with names and strings all the while.

    Typically we use it 'out-the-box' predominantly and just keep an eye on fixes that are of interest that we cherry pick ( though we honestly didnt have to do that much at all ). If you choose to get a later release or deploy your own custom version its just a case of ensuring your version comes before the default maya one in the sys.path list.

    At Lionhead we switched from 2012/2013/2014 with barely any alterations to our actual pymel code (i cant actually recall any).

    We tend to fallback to compiled c++ plugins for anything that requires a node that will be used within a rig just to ensure framerates will be as high as possible, and there is the occasional splash of cmds in places ( again usually where you need to iterate through masses of verts etc ).

    We're just building a fresh pipeline at Improbable, and I dont hesitate to use PyMel heavily within the Maya codebase. IMO its a python integration done right.

  3. #3
    program Theodox's Avatar
    Join Date
    Mar 2012
    Location
    Seattle
    Posts
    1,107

    Default

    Pymel is pretty much standard equipment; it's quite well done (although I'm sure everybody has their quibbles in matters of detail) and can definitely help you write more concise, readable code. Plus the vector and matrix types that come with it are very handy and save a ton of roll-your-own work.

    The main drawbacks are the long startup time (universally reviled) and the tight under the hood integration of the Maya API - while using the APIs great for common maya problems (like renaming a bunch of objects without doing lots of fancy footwork to hang on to them as their names changes) it does mean you can also completely crash maya with a typo, which is much harder to do with vanilla cmds.

    FWIW if you just want to write pCube1.tx = (1,1,1) you can do that without pymel by using a descriptor that wraps the a native maya command. Here's an example for working with transforms, it'd be fairly simple to do the same thing for other properties http://techartsurvival.blogspot.com/...roperties.html

  4. #4
    struct
    Join Date
    Mar 2011
    Location
    San Francisco
    Posts
    348

    Default

    We use PyMel pretty much exclusively. The one area that I will avoid it (or just use the python API) is when processing large numbers of components. There can be a large overhead when pymel casts thousands of components to individual API types.

    There are some annoyances and gotchas when using PyMel that you'll discover as you work with it (if you haven't already). Some methods don't return PyNodes (like filterExpand), and you'll come across some calls that just plain break (like calling duplicate on a namespaced object when an object with the same short name (non-namespaced) exists, or using slices on a getAttr call for a multiAttr)

    EDIT:
    Oh and the pymel.util.path module shipped with 2014 breaks on isdir calls (python2.7 changed the isdir implementation, and stopped playing nice with the version of the path module that ships with pymel in 2014). Since then they've updated the path module in their repo, but just be aware of that if you're using 2014 and the path module.
    Last edited by capper; 04-03-2014 at 12:55 AM.

  5. #5
    Technical Artist
    Join Date
    Jan 2012
    Location
    London
    Posts
    16

    Default

    Sounds all good. Looks like no studios try to avoid it.
    It will take a while to transfer from our custom node system to PyMel's, but I believe it will be worth it.
    As for deploying a custom version we'll avoid it as much as possible. Think we'll have all functionality from the standard out-of-the-box PyMel version. So far no complains..
    I like PyMel alot more then maya.cmds. So I'm looking forward to switch :)

    Thanks for the heads up!

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •