One more thing, irrelevant to the PyQt discussion but relevant to the thread:
- dragging a long list of objects to another (to reparent) in the Explorer results in individual CopyPaste() commands for each object which is crazy slow compared to a single ParentObj() command if I were to use the Parent button. Sometimes I forget and have to wait a while for a thousand commands to trigger. It should be smarter than that. :/ On Tue, Sep 4, 2012 at 12:23 AM, Raffaele Fragapane < [email protected]> wrote: > Agreed on all accounts, but that's a shortcoming of the API's design and a > show of its age in some regards, not a flaw in the idea, given the material > they worked with it's actually more than ok, especially when compared to > the way things were before. > And practically anything beats by a mile the original joke of importing a > commands module and writing excel macros in python ;) > > Soft's cpp API actually has a respectable design and layout when it come > to OO IMO, and would lend itself well to being bound. > > SWIG to be avoided whenever possible though :p > Boost offers much better mileage even if it's an additional chunk of work > from the semi-automated header parsing approaches. > > > On Tue, Sep 4, 2012 at 1:30 PM, Serguei Kalentchouk < > [email protected]> wrote: > >> Well Maya's slow implementation of Python followed the natural >> progression based on their MEL their scripting interface. Wrapping the >> commands into python was cheap and effective. Alternative would've been >> equivalent to building a new SDK framework from scratch which wouldve >> delayed the introduction of python into Maya. >> >> Maya's cpp API doest lends itself wall to object oriented programming >> either. The original straight swig bindings are pretty uncomfortable to use >> in a Python environment. Their new version is better but missing a fair bit >> in functionality and thus the adoption is pretty low. >> >> This is where pyMEL came to play which wrapped the python commands and >> the python API hooks into an object oriented framework. However there is a >> performance hit that comes along because all of the sudden you are >> generating hundreds of python objects while doing simple operations that >> would otherwise be blazing fast in MEL or python commands. >> >> This performance hit is the reason why Im currently in the process of >> rewriting an object oriented API for Maya I've been using istead of pyMEL >> into C++ and exposing it back via boost bindings. It's a time consuming >> process but so far I've been seeing a significant improvement with some >> tests showing execution time drop by more than half, that makes me hopeful >> that this effort won't go to waste! >> >> I'd be happy to share my experiences in case anyone is serious about >> doing the bindings for Softimage. >> >> >> On Monday, September 3, 2012, Raffaele Fragapane wrote: >> >>> Which is ironic. >>> MEL and their first python implementation were so FUBAR that they could >>> just do (buy, really) what needed doing by introducing a completely >>> separate way of working. >>> >>> They had no object orientation or coherence worth speaking of outside of >>> the cpp API before then, so even with all the gaps it was hugely well >>> received. >>> >>> In XSI there's a better track record, which means you will have to give >>> up something, but at this point there's enough goodness in the CPP API, >>> beside just the performance aspect, that I reckon it'd be worth doing. >>> Not to mention the viewport API in pyton would be cool to have, like >>> Maya manips are (somewhat) accessible through the bindings, even if you can >>> segfault maya hard every other minute when working with them :p >>> >>> On Tue, Sep 4, 2012 at 11:12 AM, Ahmidou Lyazidi >>> <[email protected]>wrote: >>> >>>> Maya has both, standard scripting and cpp API binding, which is a good >>>> thing! >>>> >>> >> >> -- >> Technical Director @ DreamWorks Animation >> [sent from mobile] >> > > > > -- > Our users will know fear and cower before our software! Ship it! Ship it > and let them flee like the dogs they are! > >
