Hello everyone,
I’m relatively new to being a dedicated full-time technical artist, but I’ve been following Tech-Artist.org for a couple years now as I steadily grew into being a TA. So, thanks for all the great knowledge you’ve all shared over the years.
On to my topic! I’ve been digging around the forums a bit and it seems like several of you are using Maya with PythonNet to create WPF tools that communicate with Maya. I’m looking into setting this up at my studio as well and wanted to ask a few questions:
-What kinds of things do you like to use it for?
-What are some advantages to using WPF and C# to develop the tools as opposed to working solely within MEL and/or Python?
-What are some disadvantages or limitations that you’ve run into?
Thanks for the input!
The short answer? Use a .NET app for anything that is already in .NET, or which can’t easily be done otherwise in Maya. Everything else should stay “virgin”. Of course there are exceptions to every rule.
So, if you have an application that is already written in .NET that you need to access from Maya, for instance, a runtime shader editor, and you want to be able to populate those shaders with info from Maya (say with texture names), then this is a perfect case for PythonNet. You can recompile the application (or some portion of the application) as a .NET assembly, then latch on to it from Maya to pump data back and forth.
What I don’t recommend .NET in Maya for is for “standard” Maya tools.
[ul]
[li].NET is compiled code, and as such is not as easily debuggable, not that scripting for Maya has ever been very “debuggable”. You can do stuff like throw up a modal dialog from your assembly, and then use “attach to process” from DevStudio to do debugging, but it feels like debugging in stop-and-go traffic.
[/li][li].NET does not have access to Maya’s internal functions unless you wrap them in Python and explicitly expose them to .NET. In other words, you aren’t going to do “ls -sl;” from C#. (yes, I know that’s MEL)
[/li][li].NET windows are not owned by Maya, and therefore do not sort the way Maya native UI does. The application will have its own taskbar item. You can play tricks with USER32 to accomplish this, but it is serious voodoo, and still doesn’t really do what you want.
[/li][li]Passing event callbacks from .NET to Maya is a crashy pain in the butt, but doable. Most people will not want to bother. You have to deal with both event spam from .NET and python threading in Maya which can be tricky.
[/li][li]Changes to your assembly require a recompile of the assembly and a restart of Maya. In theory, you should be able to just reload an assembly, but I haven’t had much success.
[/li][li]You can’t display any Maya native UI in a .NET window (such as a viewport, or the outliner) without some SERIOUS engineering effort/hackery. Perhaps this is easier with QT in 2011, but I haven’t tried. Perhaps when I’m feeling masochistic.
[/li][/ul]
There have been rumblings from AutoDesk about “.NET support” in Maya, but I wouldn’t hold your breath. If it comes, it likely won’t be coming any time soon.
Agree with Brett, if you have code you need to recover that’s already written, sure it’s nice not to have to rewrite it. Having seen it attempted twice now, I think I would actively discourage anyone from trying to build a pipeline from the ground up on the assumption that you can use .NET in Maya via Python .NET. For the most part, it’s only really reliable and stable when doing simple stuff, but most of those simple things can be done with python builtins. To add a few points to Brett’s list:
[ul]
[li]Error Handling - yeah there pretty much is none. Usually a .NET exception means bringing down Maya.[/li]
[li]Yet another opportunity to get tools out of sync because one of your scripts relies on a binary (.net assembly). Sure, in a perfect world, people would try to be aware of this sort of thing, but no, it happens. [/li]
[li]Another thing i’ve seen at some of the studios i’ve worked at is that people tend to test the Maya C# code less because it’s seen as “just maya code, so it’s no big deal”. That’ really a social engineering issue, but like i said, i’ve seen that mentality.[/li]
[li]Another social engineering issue, and i hate to toss out the us vs them thing after Rob’s great GDC talk, but it does encourage people who aren’t well versed in the inner workings of Maya to write tools for Maya, usually in insanely complicated ways. Before coming to 343 Ind, I would’ve thought that writing a pipeline to pass an FBX file back and forth between Max and Maya was a simple problem, but when you have people who don’t really know Max, Maya, FBX, or the scripting interfaces for any of those writing the tool, you get this hydra-esque thing that relies on WCF, System.Process, and all sorts of other .NET functionality that could’ve been done with Python builtins and native Maya functions. Specific example, but again, that mentality can become pervasive…ask me about our material system or some of our attempts at a custom light node sometime when i’m less sober.[/li][/ul]
So yeah at the end of the day…i wouldn’t if you don’t have to. Seriously, especially if you’re not using any tools code, don’t write your own shit that’s JUST for Maya in C#. Learn Python. And that’s coming from the guy that posted the Python .NET in Maya tutorial on T-A.O. Full disclosure though, my experience with it is colored way more by people who shouldn’t be writing Maya code writing broken Maya code and producing horribly bloated and unstable pipelines vs the actual Python .NET codebase itself.
In a perfect world, our tools engineers would just be exposing stuff in C/C++ code to Python or something along those lines…I’ve heard that works well.
Thanks for the input everyone. Sorry to hear it wasn’t more useful! I guess it’s back to more MEL and Python for my standard pipeline tools.