Maya: OBJ is not FBX!

Not that that would be a surprise. But even with things that should be standard Maya finds ways to fuck things up. If you export an object as FBX from Maya, it exports the material with it. If you export the same object as  an OBJ-file, the .MTL-file (which has the material definitions) uses the shading group names as references! And of course, those have no direct relevance to the material name... Why, Maya, why?

"Bad UI"-Quicky #1

Because it's better to enable the "ignore" of a setting than have the setting itself actually enable something...

What's wrong with "Show in Outliner" and "Use Outliner Color"...? This happens when people don't think before implementing stuff.

Another funky maya quirk!

I'm trying to write a function that selects all top level objects that have a child object. In maya that's tricky. First we need to filter out top level objects

{obj for obj in ls(transforms=True) if obj.firstParent2()==None}

This works okay. But figuring out wether it has children is a tough call in maya, because:

1. Group objects are transforms without shape nodes
2. Shape nodes are the first child of transform nodes

Hence when you check a node, you cannot simply ask how many childs it has. If you filter for nodes with one or more children, you're basically get all meshes, cameras, lights and so on. If you filter for two or more, you don't get groups with only one child. Anyhow you need a lot of filtering for what should be a really small issue.

Maya scripting crap - The 3rd

I stumbled over some more marvels of maya scripting. This time it's about user interface layout. You see, sometimes you don't know the parent of a certain UI, so you have to ask maya. And how do you do that?

form = cmds.setParent(q=True)

Yes. You're pretending to set the parent, but actually get the parent! All because of that "clever" way of calling command in query mode. You hardly can get less python-codex than this.

Also there is a command called "iconTextScrollList". And it has nothing to do with icons. Nothing. Nada. Niente. How crude must the development of this program been that these kinds of errors/lazynesses happened...?

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 wether 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 inhouse 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 shortlived 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 inhouse 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 unkown 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 wether 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 measureable 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 scar, 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 overengineer the codebase, as i seem to be the most python-adept around here 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 toolsguys. 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.

More Maya Scripting crap

My favourite target to complain about maya is the questionable transform node - shape node duality. This creates so many problems and i haven't really found a moment where it actually solves one. My limited knowledge of computer- and programming language design tells me that it was implemented to easier adress transform components in C or C++.

Nevertheless this system creates some unique behaviours of commands. The LS command for example doesn't know or care which transform is connected to a light shape node for example. Hence you can't ask it "Give me all light transform nodes", even though it has a "transform"-parameter. So we have this command:

ls( lights=True, transforms=True )

which returns all light shape nodes and all transform nodes of a scene. The parameters create the union of two different sets. In contrast this command:

ls( sl=True, dag=True, transforms=True )

returns all nodes that are selected, part of the hierachy and transforms. The parameters create the intersection of three sets. Or you can visualize this henceforth:


Not pretty.

Gamerz... ARG!

Wow, i'm embarrassed for calling myself a gamer since the whole shitshow around "No Mans Sky". 

Crying on internet boards for weeks about how a product is not what it was advertised as, that at least sorta sounds to me like "not having all too much of a life". I'm pretty sure at the time he said those things he thought he could make them work. In that regard you can call it a "broken promise". And yes, if you're butthurt enough, you might equate a "broken promise" with a "lie"... It's still a rather petty way to distract from the fact you paid for a product without knowing anything about it. But yea, call the people that like it "apologists", way to go doublestandard there. This shitcampaign is so out of proportion by now, it's beyond ridiculous. The "He just wanted to make a quick buck"-argument is just pure and utter evil. I work in the gambling industry and i know what "making a quick buck with idiots" really looks like. Konami took a dump on gamers and is big in gambling now. Does any gamer care? No. A guy tried to make a game that was far beyond the scope of an 8-person-team and failed, yes, that's the target for all your hate.

Just sad.

MEL is crap. Maya Python is crap. And even PyMEL is crap!

Yes, PyMel is crap. It's the best crap you get in Maya, but it's still crap. Take a look:

pm.autoKeyframe(state=True)

This SETS a value. And this

pm.autoKeyframe(query=True,state=True)

RETURNS a value. Finally this

pm.autoKeyframe.state()

delivers an ERROR. This is not how you're supposed to use Python ffs!!!

Also the "sets"-command is an abomination in Maya python. Actually, it's already in MEL, but at least it sorta follows the idiotic MEL-logic. In python it just batshit crazy. To remove an object from a set, you do this:

cmds.sets( myObject, remove=mySet )

Yes. You tell the "sets"-command to remove the mySet from myObject to actually remove myObject from mySet... *head explodes*... Oh yea, in pyMel it seems to not accept it's own objects anymore... I give up.