Skip to main content

Installation routine programming in python for a 3d graphic artist workflow or how i made maya my bitch - Part 1

Every 3D artist who works with maya uses scripts. You'd be an idiot if you don't, as the base functionality of maya most often is not sufficient for every 3D modeling, rigging or animating task. But when you're in a bigger team (10 people) with a company-specific workflow, it's highly inefficient (or simply impossible) to work without a dedicated toolchain.

I wasn't sure whether i bit off too much to chew when i went on to set up the base for the toolchain at my company. My python skills and my understanding of maya's architecture sure improved over the last two years, but i felt nowhere near the level of security and control i felt with maxscript. But dang, i'd feel like the old man that i am if i would let myself scare away of that challenge!

The worldly conditions for the toolchain are pretty hefty:

  1. The target is an in-house engine and probably one of the most ill-conceived ones i've seen in my 15-year-life as a game artist. The story goes the management of this former purely 2D-focused company perceived 3D as a short-lived trend and the architecture of the engine reflects that. Add to that 3D-inexperienced coders and artists and you get an idea of the monster that i made myself a mission to tame.

  2. I'm only here for about 2 years now, but the company is far older (>20 years). Hence loads of structures are in place that i won't be able to change, no matter how much (or little) sense they make. The workflow for installing scripts was the old "copy it from the network in your script folder"-approach. Hence every artist has a different version of tools (if at all). Also due to loads of projects running pretty much parallel, every artist has different downloaded scripts that might tamper with the prefs. And ordering of new software is a painful chain of convincing superiors and waiting sometimes months for delivery. It's pretty much the wild west of 3D graphics and i'm only the deputy sheriff at best. At least i might not get shot...?

  3. Some programmers see artists more as a necessary evil, which over here seems to be grown over decades out of standard coder-artist communication differences. Creating tools for them is seen as an annoying distraction from their actual work. The philosophy "an engine is only as good as its tools to create content" is even in times of Unity3D and Unreal hardly widespread. Hence the in-house tools aren't more than a handful of buggy and unintuitive MEL-scripts. At the same time it seems the engine coders are overly protective of those hacky scripts. Conclusively i won't get rid of those scripts in the short run and will have to incorporate them in a safe way, until we manage to generate a more partner-like atmosphere.

  4. "Usability" is unknown or at best a futuristic concept around here. A script doesn't work? Well, obviously the user made a mistake! The general tools approach here boggles my mind to the point that i actually question whether the year is really 2017. As far as i understand it's a result of the company atmosphere, which is often more interested in holding somebody accountable than to actually fix a problem. And as long as "usability" is not a measurable value, it's easy to shift the blame for inefficiency between artists and coders.

  5. On the shaky plus side is the fact that projects here take "only" around 6 months and due to the inefficiency of the tools and the feedback loop, it's easy for me to make loads of iterations and tests in various workload-conditions on the tools.

So far so scary, lets research what we got on the technical side!

  1. MEL is a horrible scripting language. Its style clearly resembles a UNIX shell. I wouldn't want to code a toolchain as batch-files and as such i won't even consider using MEL.

  2. This only leaves python, which thankfully is the quasi-standard nowadays for technical artists. But which implementation to choose? With the quality of python there comes the quantity of options: Maya Python, PyMel, Maya Python API 1.0, 2.0, PySide, ... We don't want to over-engineer the codebase, as i seem to be the most python-adept around here (not a huge bar to jump though) and don't have or want to have the sole control over the toolchain. I really want to encourage collaboration with this one and further a sorta "band of brothers"-approach between the tools guys. Shit might hit the fan and i don't need pointy fingers then.

This background evaluation concludes Part one. Lets see when i get to the next one.