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!
