C++ or C# for Maya plug-in dev

Hey,
As my comfort level of python and Maya API has grown my knowledge of C++ has diminished. I used it years ago so if I started back it would be like starting all over again. Now that C# has entered the picture it seems like a good time to learn a new language.

What are peoples opinion on one versus the other when it comes to plugin dev for Maya? Any gotchas or things that would be better or easier than the other?

Thanks,
-Sean

I haven’t used it, but I love C# as a tools language, so in theory it sounds great.

If I was starting a pipeline from scratch, I’d strongly consider it. However, I won’t trust it until I use it.

I’m also interested to see what people who use it regularly have to say.

So both the Python and .Net bindings only cover a portion of the API. (Though coverage does seem to be slowly growing as time goes by)
This means that at some point you might run into something that will just flat out require C++.

But honestly I’ve yet to run into anything that I couldn’t do with Python.

As for the .Net stuff, I played with the samples back when it was first added, but haven’t done any real work with it yet.

We use python to protype plugins all the time. Then send off to a programmer to be done in c++. You can get by with python just fine, c++ will always be faster though. Dunno about using c# in maya though, I didn’t know that was surfacing.

Still in LA area?

Thanks for all the responses. Super helpful. Yea, most of my API needs have not been too computationally heavy. Basic dag and mesh stuff. But I have some deformer stuff I’ve put on the back-burner and wanted to see which way to go.

Nope, out of LA. In the bay area now (North Bay to be exact). Kind of nice to be out of there but you never know with this industry. I’ve literally been up and down the west coast and back again. If I do end up back in LA I will have down the west coast loop twice. Oy! O_o

Cheers,
-Sean

C++/C# plugins: yes.
Pipelines? Please no.

For us as outsourcers, the worst pipelines are the ones written in C++ or C#, because this is game dev, and most studios don’t seem to spend a lot of time to make their pipelines distribution safe. Many pipelines work in the “home studio” but once you give them away they clash with unfamiliar IT, OS and network environments. This affects pipelines from reputable studios too. We as outsourcers are then left to wonder over cryptic stack traces and exception reports and there is nothing we can do, other than waste a full work day to see if our clients on the other side of the world can figure out why. Often their TAs do not know either (because it’s a cryptic stack trace, who knows what it means and what causes it?) and then have to call in their programmers, which takes even longer. If pipelines were written in Python we could at least look into the problem ourselves, or the client’s TAs could to understand what causes the error. Often errors are caused by things which are easy to fix, but if you don’t get a good error report it’s hard to do anything about it. Also, making little customizations for your outsourcer are much easier to do in a scripted language, or the outsourcer can do them themselves.

The problem gets worse the more integrated pipelines become. So either write them in some code that can be inspected or spend more time on testing - but who has time in game dev? :frowning:

Personally I hope that Python will get more traction, now that 3ds Max supports it.

I use python for everything unless speed is important. In our toolset and pipeline at work it is like 90% pymel with some OpenMaya. Than only 10% C++ for things like deformer nodes that need to be fast. Also we recently moved to maya 2015 so it is nice having pyside out of the box.

I see your point Robert. I do have tools being used by a studio in an other country along with a 3rd-party plugin. Some studios need to keep their tech hidden I’d imagine. If they’ve written a fancy solver or a tool that could be exploited and eventually in the hands of another studio I can see why having the code not accessible.

@passerby
I’m still a bit on the fence with pymel. With some testing I’ve found it to be terribly slow for certain things. I feel like it’s this shiny object beckoning me to it and once I’ve grabbed hold it will let out a maniacal laugh.

@snolan it isn’t that often that speed matters too much, and when it does we got OpenMaya. Speed of development and more manageable code can be a huge thing even if it adds to executution time.

When we moved to maya I was adamant about keeping our exporters that were in c++ as simple as possible and only a couple options. I’ll do everything in python and let it simply export what i need. As robert mentioned, any changes are painful and slow, but in python they are simple and quick.

I’m also on the fence on pymel. Its dog slow when you have to loop on anything so i’ve stuck to cmds and OpenMaya.

same here, cmds and OpenMaya, with a (relatively speaking) simple C++ plugin for exporting.

I’m with the consensus: the less C++ the better.

Python is more portable, less prone to version breaks, and fast enough for most things. I’d only resort to C++ if for some reason perf became a big issue – but the cases where that happens are thankfully rare: the cases where processing time is significant compared to IO are pretty few and far between (and how many milliseconds to you have to save to make up for a single work-losing access violation or DLL debugging session? And wait till you’ve got to deal with non-ascii file systems, or mixed OS’s , or locked machines…

The C# api is looking kind of nice. C# offers some good tools for metaprogramming – attributes and so on – that easy the pain of the clunky Maya programming style. Without manual memory management is also less likely to randomly take down Maya completely. It’s certainly worth playing with.

Of course if you really want to get esoteric, I’ve been meaning to try to port the C# api to boo, which might be a good speed/code-style tradeoff. But honestly, I never feel the need for C++