Open Discussion of Pymel by a Pymel noob

[Jeremy YeoKhoo]

Hey guys,

I want to ask your personal opinion of pyMel. After reading the topic on Monkey Patching the Maya API by Christopher Crouzet and an earlier discussion regarding this topic in this forum, I started thinking back to pyMel and wondered if it might be an answer, I feel like kicking myself for disregarding PyMel previously. I have just realised how pythonic and how pyMel holds more of a object oriented paradigm as opposed to MEL and maya.cmds (even described by Autodesk)  

So I have a few queries, Pymel is now being shipped with Maya, but not supported by Autodesk which my have production implications. 

What do you guys think of Pymel?

-Jeremy

[Jeremy YeoKhoo]

Just remember the post by Hamish MacKenzie. But this was a few years ago. Which put me off pyMel in the first place.

MacaroniZoo

[Justin Israel]

Hey Jeremy,

I tend to agree with that older post, from experience. When I had first come across PyMel, I was excited to see a more "pythonic" api than the native MEL/python commands. But then ended up seeing similar issues to what were raised in that post. Let me say up front that I mean no slight to the developers of PyMel that are obviously working hard to solve a problem, and making and supporting a solution available to everyone. So it is without question an achievement. But overall my impression has been that you have to willingly trade off performance for a more consolidated and object-oriented interface. I am sure in certain workflows it suits people perfectly. It depends on what kind of problem you are solving with the code.

To be more specific in my experience, I had applied a PyMel solution to some code that was written in Python Commands, to try and reduce and simplify the code and more easily access the API aspects, but found a dramatic performance difference. As per the comments in that blog post, while at the time the author did see a 350x difference, even with Chad's updated comment, the performance difference was noted to be 25x. That is still pretty significant. 

Secondly, I had a situation where I ran into a bug (not abnormal for any piece of software by any means), which ended up being in the PyMel layer, and after searching for a resolution I found that the suggestion was not to use the shipped version of PyMel (which contained the bug), but rather to use the more updated version directly from source. I believe this is one reason that Autodesk ships but does not support it. If you decide to add PyMel to your stack, then you are accepting that you are adding one extra layer of indirection and that bugs can either be present in the Maya Commands/API, or your own code, or within the PyMel layer. For that similar reason, I believe, it is actually a policy at my studio that ATDs/TDs not use PyMel in their tools to ensure an extra level of complexity is not added to the debugging process.

Personally, in the tools I have had to write in the past, it has proven sufficient for me to work with the Python Commands module, and then drop into the API when needed. That is my own preference obviously. There is no right or wrong answer here. Obviously I would love if the Maya API were natively and 100% more pythonic, but it doesn't bother me all too much. 

Again I would like to reiterate that I think PyMel is a great achievement to provide an alternative API that suits certain workflows and needs. But it is worth knowing the pros and cons when choosing your tools to make sure it won't have any negative impact down the line. It could quite easily have zero negative impacts on your specific usage. 

-- justin

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/451a3ffd-28b5-4bea-abd9-a555d8863aec%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[yury nedelin]

Pymel is object oriented.
And that's a great python feature that is missing in Maya.cmds . Hamish makes a point about performance. It is true its slower then Mel but if you really want speed go with api for few times speed is important. Do not write a new ik solver with pymel but you probably will not write it in .cmds ether. Pymel is here for you to make you get results faster. Not to get your results run faster. You choose what you need for the job and use what fits best. Pymel is great another tool in the toolbox and it ships with Maya so they think its worthy.

[Marcus Ottosson]

It’s been a while since I dipped my toes in PyMEL and it was early on in my programming experiences so it’s likely that if I ventured back into it at this point in time I might end up looking at things very differently, but I’ll try and summarise why I’m not using PyMEL today.

I was stoked over the prospect of dot-notation access to operations on nodes in Maya. Having worked only briefly with Python and maya.cmds at the time and wanting to get deeper into classes and inheritance, PyMEL seemed the smart way to go in terms of learning about things and I was in no position to draw any conclusions about whether or not object-orientedness of maya.cmds was a good thing, so from where I was standing using PyMEL was a given.

In regards to performance, I did take notice of the fact that most things took a while longer than they used to - especially the ~5 second freeze upon loading pymel itself, something that would pop up whenever I shared scripts with someone who hadn’t pre-loaded PyMEL or in cases where I used it on a new workstation (as a freelancer at the time, this was quite frequent), something I think have been taken care of today although I haven’t investigated - but I honestly never had any real issues with it and in general don’t bother much about performance in anything Python anyway and would turn to other languages for that sort of thing.

As Justin mentioned and as with any framework, there is the additional layer of errors you will need to get comfortable with and this was the killer for me. Again, this might not have been the killer if I gave it a try today, but at that time I found myself digging into the PyMEL docs first, the Maya docs next and lastly the Python docs and it seemed like one too many layers of debugging considering the rather small amount of gain I got out of using PyMEL in the first place. (The second most motivating thing, beyond less lines of code, was the feeling of being an early adopter, something that doesn’t apply today that we’ve gotten some perspective)

The reason I never got back into PyMEL was simply due to not having the need. I think this also resonates with what Justin was saying above about maya.cmds not being complete, but sufficient. The majority of the code that I write has little to do with Maya and whenever I need to interface with it its usually to offload the end-results of some computation having been performed. As an example, I might run cmds.file() to load a file for which a path has been computed from a number of factors, each unrelated to the Maya application itself, such as the currently logged in user, a project, environment variables or various options from a GUI. Another one may be to retrieve the node-tree using cmds.ls() and from there perform any processing in pure Python and PyQt and such.

I’d say that because the vast majority of my code is spent not interfacing with Maya, the (potentially) slight productivity increase from using a framework such as PyMEL isn’t worth the additional learning curve and debugging effort for me, though I agree with Justin that it is a major achievement and is without doubt very useful areas other than those I’m involved in.

As a side note, I would argue that developing using any of the Python libraries provided by Maya is to be avoided or delayed as much as possible. It’s important to keep your code independent and reusable and any connection to Maya cuts a pretty broad cord. PyMEL is a step away from this direction as you are encouraged to write more with it but it also introduces additional objects to pass around your otherwise decoupled code.

Best,
Marcus

​

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CACqGScjNR8g_uvM0fEn%3D-aNgmJkvQ94RRgA8n8DXRqjidJHDFA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Justin Israel]

On Fri, Jul 4, 2014 at 11:35 PM, Marcus Ottosson <konstr...@gmail.com> wrote:

It’s been a while since I dipped my toes in PyMEL and it was early on in my programming experiences so it’s likely that if I ventured back into it at this point in time I might end up looking at things very differently, but I’ll try and summarise why I’m not using PyMEL today.

I was stoked over the prospect of dot-notation access to operations on nodes in Maya. Having worked only briefly with Python and maya.cmds at the time and wanting to get deeper into classes and inheritance, PyMEL seemed the smart way to go in terms of learning about things and I was in no position to draw any conclusions about whether or not object-orientedness of maya.cmds was a good thing, so from where I was standing using PyMEL was a given.

In regards to performance, I did take notice of the fact that most things took a while longer than they used to - especially the ~5 second freeze upon loading pymel itself, something that would pop up whenever I shared scripts with someone who hadn’t pre-loaded PyMEL or in cases where I used it on a new workstation (as a freelancer at the time, this was quite frequent), something I think have been taken care of today although I haven’t investigated - but I honestly never had any real issues with it and in general don’t bother much about performance in anything Python anyway and would turn to other languages for that sort of thing.

In my specific case, I had to worry about performance because it was a user-facing tool that scanned the scene for specific kinds of bad geometry. So it used a lot of loops. At first it was written in python cmds. Then I found PyMEL and tried that, assuming the underlying usage of the API would improve my performance. It actually made it multiple times slower. I ended up writing it in the API directly and got excellent speed improvements. In this tool, we are talking potentially minutes under PyMEL to scan the scene as opposed to under 30 seconds, for heavy of geometry. 

I had a trivial comparison benchmark that I used in my "Python for Maya Artists Vol 02" training video. Reposted it here:

https://gist.github.com/anonymous/4597cf363e37d7c74ed0

I'm sure other types of operations would produce different degrees of performance differences. Some reasonable and some not. As you can see in my example, we aren't seeing 350x or 25x differences. But we are seeing noticeable ones, if someone is waiting for an operation to complete. 

I would say that it would definitely not be an issue for stuff like you mentioned, where you are loading things or interacting with the scene in ways that don't involve lots of iteration. A single call isn't going to cause any kind of impact. It is when you have to make many many calls to PyMEL and it creates lots of its objects, that it becomes noticeable. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA%3Dpx3rL0q%2BqDtNaeUjRdWMC1PncHMS33%2B69r40bDfY-g%40mail.gmail.com.

[Jeremy YeoKhoo]

At the moment, I am trying to build a rigging tool, I am trying to write my code more or less independant from Maya's short coming (with maybe ambitiously trying to extend that tool to other software like Houdini)  pyMel looked like it could provide that flexibility. I was actually hoping that pyMel, since now it is being shipped by Maya, the performance of it would now be a bit quicker. But from my research it looks like pyMel is still independent of Maya and could pose annoying problems with varying versions of Maya (since I freelance and different studios use different versions of Maya and etc...) 

It is good to know that you guys gave me that input before I developed more of my code too far down that path. Bit of a shame really in regards to PyMel. Now I am wondering more about Fabric Engine, I might look into that further, maybe that should be a topic for a later date.

-Jeremy

On Friday, 4 July 2014 12:06:52 UTC+10, Jeremy YeoKhoo wrote:

[Justin Israel]

If you do anything with Fabric Engine,  maybe you could write up some info on the experience. Never used it but was interested. It's commercial though,  right?
I sat in a demo once where they were trying to pitch a sale of an aspect of the framework. Looked interesting.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/51d18c7a-0653-4ace-9bf1-2cdc6eb7560a%40googlegroups.com.

[Christopher Crouzet]

It's commercial but their licensing scheme permit anyone to try it out easily: http://fabricengine.com/get-fabric/

I've been following the project for a while and for the first time here's a team of devs that I believe in. As I said in another blog post (sorry for the plug, trying to genuinely share a point of view), I even see this as being the future: http://christophercrouzet.com/blog/post/2014/03/07/Softimage-Has-Been-Killed%2C-the-Future-of-CG-Softwares-Is-Now-in-TD-s-Hands

In your case, if I wanted to build a portable rig or deformers with GPGPU performances in bonus, I'd go with Fabric. It might get more involved though as I'm not sure what tools are at disposition for rigging so far but it sounds like they've just implemented a paint weight tool that you can now use in Maya to replace the default crappy one, so it shouldn't be too bad.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2tqcmHNBNUz%2BvLWrW9YBcy_%3DGtTVvGRoEcQxrydVUaBQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Christopher Crouzet
http://christophercrouzet.com

[Marcus Ottosson]

Fabric Engine falls under the early adopter hype with me and as such I really like it, but can't say much about it's prospects. My main concerns being that it is commercial as opposed to open source, and that it relies on an isolated, custom language as opposed to using an existing, already established one. Hard to say whether there ever was an option, but it is how it is. I would expect an open alternative to be in the works, that potentially uses a more established processing language, like julia.

I echo Justin on interest in seeing what you can come up with Jeremy and'd be happy to see a post of that sorts here!

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CANuKW52c26YwiS_hu-UvmWW-HrmnU-fjtO36b7%3DAz6mOCFkryA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Christopher Crouzet]

I've initially also had my concerns about writing code in a new
language but then the devs have been reassuring. The choice for the
language allows you to write user-friendly code while having some
modern programming optimizations being run out of the box without you
having to code any differently most of the time. With 1.12 you can
even run a single piece of code either on CPU or GPU.

Disclaimer: I'm currently not using Fabric as I've got other
priorities but it's on my medium-term todo list. I'd rather wait for
the planned 2.0 overhaul anyways. But as many—like Andrea
Interguglielmi who came up with Coral—, I've been wishing for a such
framework for some times. What they came up with so far is beyond
anything one could have come up with. But that make sense—they've got
the engineers behind ICE from Softimage, they've got ideas, they want
to change things, and they're a talented bunch.

On 06/07/2014, Marcus Ottosson <konstr...@gmail.com> wrote:
> Fabric Engine falls under the early adopter hype with me and as such I
> really like it, but can't say much about it's prospects. My main concerns
> being that it is commercial as opposed to open source, and that it relies
> on an isolated, custom language as opposed to using an existing, already
> established one. Hard to say whether there ever was an option, but it is
> how it is. I would expect an open alternative to be in the works, that
> potentially uses a more established processing language, like julia

> <http://julialang.org/>.

>>>>> <http://christophercrouzet.com/blog/post/2014/06/23/From-Monkey-Patching-the-Maya-Python-API-to-Gorilla-and-Bananas>

>>>>> by Christopher Crouzet and an earlier discussion regarding this topic
>>>>> in
>>>>> this forum

>>>>> <https://groups.google.com/forum/#!topic/python_inside_maya/cLdkFBAgRtI>
>>>>> , I started thinking back to pyMel and wondered if it might be an

>>>>> answer, I feel like kicking myself for disregarding PyMel previously.
>>>>> I
>>>>> have just realised how pythonic and how pyMel holds more of a object
>>>>> oriented paradigm as opposed to MEL and maya.cmds (even described by
>>>>> Autodesk

>>>>> <http://download.autodesk.com/us/maya/2011help/PyMel/why_pymel.html>)

>>>>>
>>>>> So I have a few queries, Pymel is now being shipped with Maya, but not
>>>>> supported by Autodesk which my have production implications.
>>>>>
>>>>> What do you guys think of Pymel?
>>>>>
>>>>> -Jeremy
>>>>>
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Python Programming for Autodesk Maya" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to python_inside_m...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/python_inside_maya/51d18c7a-0653-4ace-9bf1-2cdc6eb7560a%40googlegroups.com

>>>> <https://groups.google.com/d/msgid/python_inside_maya/51d18c7a-0653-4ace-9bf1-2cdc6eb7560a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .

>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Python Programming for Autodesk Maya" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> email to python_inside_m...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2tqcmHNBNUz%2BvLWrW9YBcy_%3DGtTVvGRoEcQxrydVUaBQ%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2tqcmHNBNUz%2BvLWrW9YBcy_%3DGtTVvGRoEcQxrydVUaBQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Christopher Crouzet

>> *http://christophercrouzet.com* <http://christophercrouzet.com>

>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to python_inside_m...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CANuKW52c26YwiS_hu-UvmWW-HrmnU-fjtO36b7%3DAz6mOCFkryA%40mail.gmail.com

>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW52c26YwiS_hu-UvmWW-HrmnU-fjtO36b7%3DAz6mOCFkryA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --

> *Marcus Ottosson*
> konstr...@gmail.com

>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to python_inside_m...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBieVuqy0AoHm%3Dt1mksrgTxC99Jzw-hpkwTMbnoKOsaJg%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.
>


--
Christopher Crouzet

*http://christophercrouzet.com* <http://christophercrouzet.com>

[Marcus Ottosson]

Yeah, I couldn't have hoped for a better suited team or more exciting goals than that of Fabric, it has all the potential in the world.

Ps. Isn't Andrea with Fabric too? My impression was that he gave up on Coral shortly after having been recruited by those guys. I think he's essentially continuing his vision over there now.

[Christopher Crouzet]

Glad to see that we finally agree on something ;)

As for Andrea, not anymore. After Coral he went to DreamWorks, then indeed worked for Fabric, but he's now happily making beautiful vintage surfboards: http://www.settembresurf.com/

One genius of a kind.

On 6 July 2014 11:28, Marcus Ottosson <konstr...@gmail.com> wrote:

Yeah, I couldn't have hoped for a better suited team or more exciting goals than that of Fabric, it has all the potential in the world.

Ps. Isn't Andrea with Fabric too? My impression was that he gave up on Coral shortly after having been recruited by those guys. I think he's essentially continuing his vision over there now.

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODHS8g-nOp_ibRWctO7p6vQQuXmfbbO3oyQM0COFAp3oQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Christopher Crouzet
http://christophercrouzet.com

[Marcus Ottosson]

Haha, yes, it’s about time. :)

As for Andrea, not anymore. After Coral he went to DreamWorks, then indeed worked for Fabric, but he’s now happily making beautiful vintage surfboards.

Oh really! Didn’t know that, do you know why? Seems like quite a shift.

​

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CANuKW52v9dqmt42f%2B%3DWYCe%2Bt%2BDdy%3Dvim0Wditvsn-5ymWhVHSg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Christopher Crouzet]

Well, he's got his reasons that I won't share for him. Plus, that's a thread about PyMEL (and kinda Fabric), not about Andrea's personal life :)

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODTPkMsT3HWVr9Oqezr608ODgpr0JoZZT%2B3cReVJ8_vzg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Mark Jackson]

Have to say I echo the comments from Marcus. I used to use Pymel all the time back at Eurocom and yes, the way it deals with Maya as proper object oriented setup is very nice and gives you very fast access for prototyping systems. But for most of the things we were doing that cleanliness of code came as a cost. Not just in terms of speed, which lets face it, for a rigging systems isn't that important, if it takes 2secs or 10secs to build a rig in code, who really cares. But the issue of speed meant that we were often doing the grunt work, finding nodes and searching systems in cmds, then passing those to pymel for the meat of the function, and for me, that was hard work. I think what Pymel has done is fabulous, the guys are rocket scientists, but they're still fighting Maya under the hood.

Out of interest have you guys taken a look at the Red9 Meta that I've been doing, it's a really light wrapper that gives you all the dot complete and Maya node handling but is way, way lighter. I'm doing a talk at Develop on it next week and there's a ton of Vimeo demos, be interested to get some feedback from you guys.

http://www.developconference.com/page.cfm/Action=Visitor/VisitorID=339

It's used, or rather it is the backbone of, all the pipelines at Crytek now, everything is wired together and accessed via Red9_Meta.

http://red9-consultancy.blogspot.co.uk/

https://vimeo.com/user9491246   (search for the 4 meta data videos)

cheers

Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CANuKW51iibQvWJVEjzF%2BdGCxHGa0uGe_0PQZqRquK1aV-AW4rQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
-------------------------------------
Mark Jackson
Technical Animation Director
http://markj3d.blogspot.com/

[Eduardo Grana]

Hello Mark,

The red9 stuff looks very interesting, I'll try it as soon as possible..

Is this the latest version?
http://www.creativecrash.com/maya/script/red9-studio-pack

I'm currently at the other side of the world, and I'm wondering if the talk will be
available online later.

Cheers!

Eduardo

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGQH2FEiV1v36SDy%2BiNMJR9vx9P3H0173aTGw4TUBYhOLymBFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Eduardo Graña
www.eduardograna.com.ar

[David Martinez]

Hello Eduardo,

You should be able to grab the latest version from GitHub: https://github.com/markj3d/Red9_StudioPack

I personally love the tools from Red9. As Mark said, check out the metadata videos to get an idea.

As for the conference, I don't think it will be available online but Mark should be able to verify that.

--
David Martinez - Technical Animator

 

Email: david.mar...@gmail.com

Website: http://www.elusiveideas.com

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CACt6Grke4OUA6z41teNNNaaG2bQJRaow9mNJn67xExRMzB-mnA%40mail.gmail.com.

[Jeremy YeoKhoo]

Ill try my best to look into FabricEngine, and get back to this Forum! Like Christopher, I am currently inundated with work, and Fabric is on my lower priority list. Also thanks for the info regarding Julia. 

From my current knowledge of FabricEngine and Maya, current version of Maya have a few internal issues with the API that is causing a few bugs to prop up. Additionally I wouldnt be surprised that Autodesk, Foundry, SideFX and etc are probably against the idea of a middleware platform. So I might just wait a bit.

On Friday, 4 July 2014 12:06:52 UTC+10, Jeremy YeoKhoo wrote:

[Christopher Crouzet]

SideFX came up with Houdini Engine which is a similar idea but not as complete I guess? Just throwing a prejudice here, not sure what I'm talking about.

Anyways, I disagree when you say those companies would be against it. Fabric can act like a glue between them all, potentially bringing more customers to some of them, and definitely bringing more power to them all with the crazy optimizations Fabric comes with.

OT: not sure where you got that I'm inundated with work, I've ben travelling for over 1 year :D

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/9de94ba1-2607-46d5-82ee-4bcad3fd6067%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[techn...@gmail.com]

Hi guys - Paul here, I'm one of the founders of Fabric (previously at Softimage and Autodesk). Someone pinged me a link to this conversation and asked if I could contribute. I hope I'm not intruding.

Happy to answer any questions you have. There are a few points worth making:

1) we use our own language because there's nothing out there that offers what we need - the dynamic, rapid prototyping of Python with the performance capability of well-written, multi-threaded C++ (or CUDA). Trust me when I say we didn't want to do it but saw no other option given our goals. However, it really is paying off - a TD can now write Fabric tools that run on the CPU or GPU without any changes.

2) Fabric is not middleware. It's a standalone framework that can also be run inside of other applications (Maya, Softimage, Arnold, Nuke currently - Max, Houdini and more to come). Most importantly, it's open - the only black box is the core execution engine, everything else is there to be changed/extended/replaced as required. 'Middleware' tends to suggest black boxes and opacity, which we set out from day one to avoid.

3) Fabric is really just a commercial version of what many studios have been building for themselves for many years. We've got the benefit of not being pulled in a particular direction by any one production, which means the platform stays more generally useful. We offer source code access as part of site licensing, which addresses many of the concerns that studios have had.

4) Fabric is completely portable - you can move the tools/assets/data between 'Spliced' applications and into the standalone framework. The fact is that pipelines are heterogeneous so we do our best to play nice with everyone. In some cases there's value in building a standalone version of a tool, and Fabric offers that.

5) I can't speak for what other vendors think of Fabric, but we have good relationships with all of them. We're not building a complete DCC and have no plans to do so - we're just another piece of the pipeline. There's an argument that we break 'lock-in' to a particular DCC, but that's something that studios want and vendors have to respond to - initiatives like Alembic have proven that to be the case.

6) we've been in operation for 4 years now, so the technology is maturing well and having customers like MPC really help when it comes to hardening our technology for production. It's still early days but we've been out of beta for a long time now and are about to move to FE2.0.

I hoped this helped - feel free to ping me directly if you prefer to talk offline.

Thanks,

Paul

[Geordie Martinez]

Getting back to Pymel. I love it. OOP is the way to go. the only way to go.

I just hate that it has "mel" in the name.

if and when there is ever a concerted effort by Autodesk to truly OOP their Maya python API I will adopt it.

but in the meantime. Objects with methods makes more sense than flinging strings everywhere.

2 cents.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CANuKW52_ij1KZ50ztmpazooR_9hJV34sphsAGSd9hULUNfa%3DWg%40mail.gmail.com.

[Marcus Ottosson]

I'm certainly not one to argue the merits of object-oriented programming. But OOP is only one of many programming paradigms and is as much of a silver-bullet as any other. If you're suggesting it fits and problem I'd have to disagree with you; it certainly isn't the only way to go and is very much dependent on the problem at hand. The problem in this case being commands being wrapped up into objects with methods when what really should happen is the Python API being object-oriented to begin with, or at least wrapped up into one. Maybe this is what Red9 or MRV is doing, I'm not sure, but for anyone looking for OOP in Maya that would seem the more consistent way to go.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CABPXW4geLsbG4%3DjGqMP6PHk%2Bk3g6GtK9SjRihq5oQ3Dc8F%2BTmw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Geordie Martinez]

I look forward to seeing how these new wrappers pan out. But they are just wrappers like pymel. They'll encounter the same under-the-hood issues and have to find some way to deal with them.
Pymel has had years of development and is accepted by Autodesk. And I'm sure there will be similarities and overlap and compromises.

I do disagree with you about OOP vs. strings (maya.cmds). You can translate your python skills to other forms of python if you understand the OOP methodology and take advantage of oodles of modules out there  -- all using the OOP methodology. having a string reperesent an object in 3D space, itself an object-oriented world, also makes little sense to me.

I've spent years using pymel and I much prefer it to maya.cmds. (it has maya.cmds inside so if I had to use it I could).
Especially for getting and setting attributes, connecfting attributes, dealing with skin clusters, all rigging procedurals, shaders, and file system importing and exporting, it has the path and glob functions built in, references, namespaces... Pymel is powerful. As a creature TD I can't agree with your disagreement. It is very useful.

Anyway, to each his own.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAg%3D_v6CWPyG91Q2kQ_V-npQBvAFEPz8qdSBLWPUhpDmA%40mail.gmail.com.

[Justin Israel]

Hey Paul,

Thanks for joining the conversation. 

I had actually sat in on a demo you guys did at my studio. It looks really cool. Although the room did contain a number of low-level C++ programmers and I remember there being a negative reaction to the requirement of KL. Taking a glance at the Fabric docs I see there is a kl2edk tool that suggests support for writing extensions in C++? Was that a newer concept? I don't remember it being mentioned as an option during the demo at the time. 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/516a4049-0974-4b09-8a31-a5d926e42357%40googlegroups.com.

[Paul Doyle]

Hi Justin - I'm assuming we met one Sigg?

The KL2EDK tool was introduced a few months ago as a way to speed up wrapping existing C++ libraries as extensions. It's proven pretty popular at MPC and saved a ton of time. It's always been possible to write C++ extensions for Fabric, but it was quite laborious until we implemented that tool - there's more we can add to it to make things even faster, but as it stands it's proven useful.

Selling to C++ programmers is a tough proposition, since you can't argue 'now you can be as performant as multi-threaded C++' without patronizing them. Now that we're moving into GPU compute territory it's becoming more interesting, but generally the interest comes more around the cross-platform/portability aspects and the 'KL as a faster Python for TDs' - since the bottleneck of TDs->R&D can be prohibitive. 

Building a platform is not a minor undertaking :) We were quite naive but it's really come together over the past year - now we're about to make the jump to a new data flow graph and visual programming system and it's really quite awesome (obviously I'm unbiased). The really good thing is that the KL discussion becomes less important when we're looking at graphs, even though you'll be able to jump out and author KL at any point. We'll be showing it at Siggraph so let me know if you're about - we'll be doing user groups all day on Tuesday of the show, should be some good sessions.

Cheers,

Paul

--
You received this message because you are subscribed to a topic in the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python_inside_maya/jb0lD8SXk_M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2PAZ7Yt24LSibG%3DPkemgYBV-00K2wpGJONuQ043xjzPw%40mail.gmail.com.

[Justin Israel]

Actually it was at Weta, although we didn't meet directly. I sat amongst others in a conference room to see some stuff. This was most likely before the release of the new tool, as I hadn't heard it mentioned at the time when people had asked about KL. 

Sounds really awesome, offering the same low-level support that some people want, while catering to higher level access for TDs. 

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CALpUA1EP6ketzkwewSqSEtPhG8vTZOKMyvSEEZNF61Fyzy3_4A%40mail.gmail.com.

[yury nedelin]

Geordie

Just curious, do many guys at ILM using it?

Yury

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CABPXW4geLsbG4%3DjGqMP6PHk%2Bk3g6GtK9SjRihq5oQ3Dc8F%2BTmw%40mail.gmail.com.

[Marcus Ottosson]

I do disagree with you about OOP vs. strings (maya.cmds). You can translate your python skills to other forms of python if you understand the OOP methodology and take advantage of oodles of modules out there — all using the OOP methodology.

Not sure we’re understanding each other very well here, maybe it is a language issue. To try and summarise my opinion, I think PyMEL is great for certain things and less great for others. For the things I do with Python within Maya, I haven’t found it as useful as others might. It sounds like it works very well for the things that you do, or possibly to the way that you work, and that’s great.

However it also sounds like you are saying PyMEL, or Object-Oriented Programming for that matter, is the solution to any problem. Is this what you meant?

Hi guys - Paul here, I’m one of the founders of Fabric (previously at Softimage and Autodesk). Someone pinged me a link to this conversation and asked if I could contribute. I hope I’m not intruding.

A tad off-topic yes. I’d be happy to respond in a separate thread.

​

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CABPXW4iFB-cpt-Y1Nb%2B6QMQHztOwmDqSF0fSJq_dk%3DhQE7e9cw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marcus Ottosson
konstr...@gmail.com

[Jeremy YeoKhoo]

Hey thanks for that Paul. I will definitely try out Fabric Engine since you've cleared that up. Yep since this is a pyMel thread, I will start a new post regarding the Fabric Engine to keep the context relevant. Since I guess I opened this thread, Ill open another one solely for Fabric in this forum..