I've always liked automation. I'm sure other tech artists identify with that instinct - after all, I've read on veteran blogs like Hamish McKenzie's that the niche of "tech artist" was first carved out by whichever animators happened to be the most procedurally-minded in the department. Those best able to fix the little things that go wrong during the process, and those most inclined to proactively create shortcuts through repetitive or tedious tasks. Automation lets us distill all the work into only that which demands artistic judgement.
3D animation apps enable this instinct to an absurd degree. I learn well from diving into projects and making mistakes, but sometimes I forget to come up for air. In a state of creative tunnel-vision, I acted out XKCD's famous script:
At least ongoing development has nice views of the original task. Credit xkcd.
Having rigged a couple of characters for the short film mentioned in my previous post, I saw the tremendous benefit of scripting to speed up the asset creation process. It seemed like the time to dust off my programming skills and teach myself MEL. I needed a project - and the whole breadth of creation seemed open to me. Having always been curious about procedural generation of natural systems, I decided to make a tree generator in Maya. With MEL, no less, which I eventually learned was outmatched by the ambition of such a project.
A simple tree generator would have worked just fine in MEL; in fact, I found several during my research. Lindenmayer systems (simple pattern-based branching path generators) were a good introduction to the sort of algorithmic thinking that rigging demands, but I wanted my trees to be animation-ready. Space-Colonization was a then-emerging alternative, but sounded too data-heavy to be used in MEL. I tried something different: using Maya's nDynamics system to create time-and-force-driven branches which, theoretically, would spread apart and fill whatever space was available over a given growth period. It was heavily influenced by research such as this, which provided a feasible basis for how to dynamically approximate the golden ratio so often seen in plants.
In this absurd iteration, the nDynamic-driven bud objects decided to grow inside-out, and just looked like a communications tower.
DerpyTree generated polygon objects from user-determined seed attributes such as branch frequency, branching angle, and main stem dominance.
An interesting side-effect of this method was that the growth direction of new branches seemed to randomly flip-flop between even 360° distribution and back-and-forth 180° flips. I never determined the exact branch genesis rate that caused it to go one way or the other, but was fascinated and thrilled that I had accidentally created a distinction which exists in nature.
The animation on the right was a proof-of-concept created using the algorithm, which I called DerpyTree. It succeeded in the creation of branching polygon structures whose shapes could then be easily altered via NURBS handles. Unfortunately, it was slow. Five minutes to generate a single young tree, and using the controls to reshape or animate it slowed Maya to a stuttering crawl. The nDynamics solution, while theoretically sound, just wasn't practical; I was in beyond MEL's intended depth. DerpyTree went into the project graveyard.
But the time spent on it was far from wasted. I learned about Maya under the hood, and the relationship between the scene and the application itself. A deep knowledge of nodes and connections is essential for making complex, efficient rigs and auto-rigging tools, and my rigging workflow improved from the experience. I tackled the technical problems of language limitations, UI/UX, and efficiency, as well as my own personal problems with an overabundance of determination (aka stubbornness).
If I were to undertake such a project again, there would be two major changes: first, I would rely on more proven methods to create branching shapes, and second, I would just use the damn Maya API.