Starting out with the Maya API

170 views
Skip to first unread message

Benjam901

unread,
Jan 6, 2016, 2:07:14 PM1/6/16
to Python Programming for Autodesk Maya
Hello all,

So I have wanted to jump into the Maya API for a while but have not had the need to, or really knew where to start, but is has come to a point where I really want to know it and feel I should to advance myself.

Firstly the Python API will be the ticket for me. My C++ is kinda sparse and I am not a dedicated programmer of that spectrum.

I am going to be looking through building a plugin with Chad Vernon as I think it might be a good starting block but I was after some extra advice from the group.

- What can the API (Python or C++) be used for and what is a good best case scenario in which you will need it?
- Where should you start, i.e. are there example projects/generic ideas that could be useful to build a plugin of sorts?
- Is it generally used quite sparingly? (In my experience so far I have had no need for it but am aware it is very powerful)

Any other advice would be awesome also.

As always thanks to the group you guys are awesome.

Cheers,

Ben

Justin Israel

unread,
Jan 6, 2016, 5:47:10 PM1/6/16
to python_in...@googlegroups.com
On Thu, Jan 7, 2016 at 8:07 AM Benjam901 <benandr...@gmail.com> wrote:
Hello all,

So I have wanted to jump into the Maya API for a while but have not had the need to, or really knew where to start, but is has come to a point where I really want to know it and feel I should to advance myself.

Firstly the Python API will be the ticket for me. My C++ is kinda sparse and I am not a dedicated programmer of that spectrum.

I am going to be looking through building a plugin with Chad Vernon as I think it might be a good starting block but I was after some extra advice from the group.

- What can the API (Python or C++) be used for and what is a good best case scenario in which you will need it?

You can get better performance on some things, doing it through the objects and iterators as opposed to strings with the commands module.

You usually have to use it to write plugins.

You may find features that are only exposed through the API as opposed to the commands module.
 
- Where should you start, i.e. are there example projects/generic ideas that could be useful to build a plugin of sorts?

It can be helpful to read through the bundled Maya examples that include both C++ and Python plugin code.
 
- Is it generally used quite sparingly? (In my experience so far I have had no need for it but am aware it is very powerful)

I don't have any official data to back this up, but I would wager that it is used quite often as a more powerful way to develop features for Maya. If you have to write a plugin, you usually write with the API. If you are doing your project in C++ already, then you have to use the C++ API anyways. 
 

Any other advice would be awesome also.

As always thanks to the group you guys are awesome.

Cheers,

Ben

--
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/f40b016b-3272-4b2a-a711-ed03108cb8bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Leonardo Bruni

unread,
Jan 7, 2016, 4:23:11 AM1/7/16
to python_in...@googlegroups.com
Hi,
with Python API, you can start without problems, but when you will start to need develop deformers, you will throw away Python API and you will need for sure switch to C++
I started years ago with David Gould books: http://www.davidgould.com/Books/ but i knew already a bit of C++
After some years i switched on Python API, for small nodes plugins that don't need heavy computation, first of all for portability (in Python you can write code for all Maya versions and platform, in C++ you have to recompile for different versions and platform)
Now, after some years i make everything in C++, because it's more standard and before Autodesk make less changements.
Anyway if you goal is build a deformer or heavy computation nodes, switch to C++ and take the hard way, is my suggestion.

Good luck and cheers  

Marcus Ottosson

unread,
Jan 7, 2016, 5:05:09 AM1/7/16
to python_in...@googlegroups.com
Slightly related question about C++11; given that plug-ins for Maya need to be compiled with a particular compiler (on Windows, at least), and that this compiler (MSVC 2013 for Maya 2016) doesn't provide good support for C++11, is it possible to somehow benefit from a later compiler, such as MSVC 2015, when building plug-ins for Maya; even if that means going the long way via interprocess communication or otherwise sharing memory space? Is that feasable at all?


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



--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Jan 7, 2016, 2:27:44 PM1/7/16
to python_in...@googlegroups.com

You can't load the plugin if it was compiled with a mismatched compiler because it will want to dynamically link with libs in Maya that are not compatable. So that would mean your only option is to run an external process and communicate with it either over stdin/stdout or ipc. I don't think it's quite worth it just for c++11 features. You could always use boost of you need some stuff that is available in c++11. Or maybe even qt for things since it is already there


Chad Vernon

unread,
Jan 7, 2016, 4:43:42 PM1/7/16
to Python Programming for Autodesk Maya
Maya 2016 technically requires Visual Studio 2012


Although I have heard people have had success using 2013, there's always the chance you might run into weird crashing issues or something.  C++11 support gets kind of crappy when you need to support multi-platform since each platform uses a specific compiler with varying levels of C++11 support.  Maya is the only thing keeping me from using C++11 in a lot of code, which is a bummer.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.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_maya+unsub...@googlegroups.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_maya+unsub...@googlegroups.com.



--
Marcus Ottosson
konstr...@gmail.com

Marcus Ottosson

unread,
Jan 8, 2016, 2:16:03 AM1/8/16
to python_in...@googlegroups.com
Ah, is it 2012 even.. Then there doesn't seem to be as much as a glimmer of hope for C++11. Thanks Chad for confirming.

About going IPC - i.e. writing something completely external from Maya, and integrating by communicating across processes - I have a sneaky suspicion that Bifrost may do something along these lines.

I've seen three signs that point towards this; one, simulations with Bifrost happen asynchronously, where the timeline reflects the current status. That's not enough to indicate IPC, but at that release, ZeroMQ got added as well. Now that still isn't enough to prove they do IPC (via messaging in that case) or that it got added for Bifrost but seeing as Bifrost came from Naiad which was originally uncoupled to Maya, it's possibly written in C++11 to begin with which may have been reason enough to force the developers to look towards ways of integrating it with an older codebase, other than degrading it to C++03.

So, for a plug-in, maybe it's possible to develop entirely in C++11, as an external process, and compile a separate thin wrapper specifically for a version of Maya that handles communication with it? ZeroMQ looks fast, but is it fast enough to handle deformers (or simulation, pointclouds, for that matter)? Is it faster than pure standard in/out?

It sounds like a win, as you could reap the benefits of cutting edge technology, and C++11 won't be the last of that with C++17 around the corner, whereas Maya will always lag behind, while at the same time worry less about compatibility between your plug-in and future (and older) versions of Maya.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.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.

--
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.



--
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/a3177666-377b-4fb9-ab1c-0edac94b7320%40googlegroups.com.

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



--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Jan 8, 2016, 2:34:52 AM1/8/16
to python_in...@googlegroups.com
On Fri, Jan 8, 2016 at 8:16 PM Marcus Ottosson <konstr...@gmail.com> wrote:
Ah, is it 2012 even.. Then there doesn't seem to be as much as a glimmer of hope for C++11. Thanks Chad for confirming.

About going IPC - i.e. writing something completely external from Maya, and integrating by communicating across processes - I have a sneaky suspicion that Bifrost may do something along these lines.

I've seen three signs that point towards this; one, simulations with Bifrost happen asynchronously, where the timeline reflects the current status. That's not enough to indicate IPC, but at that release, ZeroMQ got added as well. Now that still isn't enough to prove they do IPC (via messaging in that case) or that it got added for Bifrost but seeing as Bifrost came from Naiad which was originally uncoupled to Maya, it's possibly written in C++11 to begin with which may have been reason enough to force the developers to look towards ways of integrating it with an older codebase, other than degrading it to C++03.

So, for a plug-in, maybe it's possible to develop entirely in C++11, as an external process, and compile a separate thin wrapper specifically for a version of Maya that handles communication with it? ZeroMQ looks fast, but is it fast enough to handle deformers (or simulation, pointclouds, for that matter)? Is it faster than pure standard in/out?

stdin/stdout are file descriptors. sockets are file descriptors.
Technically its all the same camp where you read and write and poll their status.
 

It sounds like a win, as you could reap the benefits of cutting edge technology, and C++11 won't be the last of that with C++17 around the corner, whereas Maya will always lag behind, while at the same time worry less about compatibility between your plug-in and future (and older) versions of Maya.

But what features of C++11 are you itching for that would make your plugin so much more performant or easier to maintain?
 

Marcus Ottosson

unread,
Jan 8, 2016, 3:17:18 AM1/8/16
to python_in...@googlegroups.com
stdin/stdout are file descriptors. sockets are file descriptors.
Technically its all the same camp where you read and write and poll their status.

Ah. I was under the impression that sockets had to go the TCP route, through the network card, but this would make more sense.

But what features of C++11 are you itching for that would make your plugin so much more performant or easier to maintain?

Haha, nothing in particular. You know you could have said the same thing about newer versions of anything, right? "What about Maya 2016 will make your work so much better looking and easier to make?" :)

I would like to progress, wouldn't you?

Justin Israel

unread,
Jan 8, 2016, 4:40:06 AM1/8/16
to python_in...@googlegroups.com


On Fri, 8 Jan 2016 9:17 PM Marcus Ottosson <konstr...@gmail.com> wrote:
stdin/stdout are file descriptors. sockets are file descriptors.
Technically its all the same camp where you read and write and poll their status.

Ah. I was under the impression that sockets had to go the TCP route, through the network card, but this would make more sense.

Unix domain sockets don't go through TCP. they are more like named pipes

https://en.m.wikipedia.org/wiki/Unix_domain_socket


But what features of C++11 are you itching for that would make your plugin so much more performant or easier to maintain?

Haha, nothing in particular. You know you could have said the same thing about newer versions of anything, right? "What about Maya 2016 will make your work so much better looking and easier to make?" :)

I would like to progress, wouldn't you?

Well that would just be like following marketing hype, right? "newer, faster, better". 
But if you aren't going to use any c++11 features, then what is the point of going to extra trouble to use it in a portable way? You could just keep coding in more portable c++ for a bit longer until the stragglers fall off and C++11 is a minimum requirement. Vfxplatform 2016 still only specifies gcc 4.8 
http://www.vfxplatform.com

I haven't been writing production c++ for too long yet (almost a year) but I have managed so far using boost or qt. Maybe lambdas would have been nice? I could have used those. 


--
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.

Marcus Ottosson

unread,
Jan 8, 2016, 5:02:56 AM1/8/16
to python_in...@googlegroups.com
What are we arguing here exactly? :) Marketing versus Progress? Looks like a stalemate to me.

I got what I was looking for; if you are to use C++11 with Maya, you'll need to go the long way around. Whether it's worth it or not depends on what you do. In your case, maybe it isn't worth it, in my case, maybe it is, hence the question.


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



--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Jan 8, 2016, 3:14:57 PM1/8/16
to python_in...@googlegroups.com

I am responding to your suggestion that one wants the latest and greatest cutting edge technology. I didn't understand why you would require c++11 just to be cutting edge and up to date. I was asking what exactly you wanted from c++11 that would justify the effort? It felt to me that your only reason was the it was newer. What would you use from it?


Justin Israel

unread,
Jan 9, 2016, 2:24:48 AM1/9/16
to python_in...@googlegroups.com

I'd actually like to hear input from those that have used c++11 in a production capacity, about what features they have found most useful.

"auto" is just a convenience really
Shared pointers are nice without needing Boost or Qt.
Move semantics seems cool if you are trying to write some efficient code.
Lambdas for sure would be great.

Paul Molodowitch

unread,
Jan 9, 2016, 2:38:43 PM1/9/16
to python_in...@googlegroups.com
Hmm - so C++11 isn't usable in windows maya plugins yet? Bummer... their linux spec supports it, sort of:

https://knowledge.autodesk.com/support/maya/getting-started/caas/CloudHelp/cloudhelp/2016/ENU/Maya-SDK/files/Setting-up-your-build-environment-Linux-compiler-requirement-htm.html

I've made a few small plugins that used C++11, and they seemed to work.  (Word on the street about the split

I haven't used C++11 much yet myself, but there's a bunch of features that I kept thinking / wishing were in C++, that when I looked up, found out would be in C++11.  The unique_ptr / shared_ptr - would probably be worth it alone, for me (they were the most common reason I would add boost dependencies, which was obviously overkill).  Other things I've wished I'd had at various points included static asserts, ability to call a construction from within another constructor of the same class, and initialization lists for classes.

Justin Israel

unread,
Jan 9, 2016, 3:06:43 PM1/9/16
to python_in...@googlegroups.com
On Sun, Jan 10, 2016 at 8:38 AM Paul Molodowitch <elro...@gmail.com> wrote:
Hmm - so C++11 isn't usable in windows maya plugins yet? Bummer... their linux spec supports it, sort of:

https://knowledge.autodesk.com/support/maya/getting-started/caas/CloudHelp/cloudhelp/2016/ENU/Maya-SDK/files/Setting-up-your-build-environment-Linux-compiler-requirement-htm.html

I've made a few small plugins that used C++11, and they seemed to work.  (Word on the street about the split

I haven't used C++11 much yet myself, but there's a bunch of features that I kept thinking / wishing were in C++, that when I looked up, found out would be in C++11.  The unique_ptr / shared_ptr - would probably be worth it alone, for me (they were the most common reason I would add boost dependencies, which was obviously overkill).  Other things I've wished I'd had at various points included static asserts, ability to call a construction from within another constructor of the same class,

True, I also could have use delegating constructors recently as well. Although for shared pointers, at least the boost dependencies is header-only.
 

Justin Israel

unread,
Jan 9, 2016, 3:16:19 PM1/9/16
to python_in...@googlegroups.com
On Sun, Jan 10, 2016 at 9:06 AM Justin Israel <justin...@gmail.com> wrote:
On Sun, Jan 10, 2016 at 8:38 AM Paul Molodowitch <elro...@gmail.com> wrote:
Hmm - so C++11 isn't usable in windows maya plugins yet? Bummer... their linux spec supports it, sort of:

https://knowledge.autodesk.com/support/maya/getting-started/caas/CloudHelp/cloudhelp/2016/ENU/Maya-SDK/files/Setting-up-your-build-environment-Linux-compiler-requirement-htm.html

I've made a few small plugins that used C++11, and they seemed to work.  (Word on the street about the split

Also, maybe this is the reason?

Bits and pieces of C++11 features are available as far back as GCC 4.3
So maybe the compatible gcc for your target Maya supported the constructs you specifically needed?

Paul Molodowitch

unread,
Jan 9, 2016, 3:30:31 PM1/9/16
to python_in...@googlegroups.com
Ooops - realized I didn't finish my post - I was going to say:

Word on the street about the somewhat ambiguous compiler recommendation is that they were going to just officially recommend 4.8.2, but encountered a compiler bug (perhaps the one subsequently fixed, as noted here? http://www.vfxplatform.com/#footnote-gcc), and emphasized 4.4.7 as a result.  Can't remember who I heard saying that, though, so take with a grain of salt.

And yeah, it's possible that whatever feature we used would have worked in 4.4.7.  But they do specifically say you're allowed to use 4.8.2 if you want C++11 support.

- Paul


Rudi Hammad

unread,
Jan 9, 2016, 5:00:10 PM1/9/16
to Python Programming for Autodesk Maya
I strongly recommend http://www.cgcircuit.com/course/maya-python-api
I was exactly like you. Didn´t know where to start. I bought this course and it is awesome. very well explained in a blackboard to understand the concepts
and then plenty of examples step by step.
Chad Vernom´s dvds are awesome too, but I think it more c++ focused. So I would go for the course by Chayan Vinayak. I have it and it is great.
Reply all
Reply to author
Forward
0 new messages