Throughout the years I was lucky enough to work on interesting projects. The tool i was feeling the most comfortable with was Maya:
- for compositing work my mind was really inclined around After Effect’s layer and composition mechanism. Combustion or Nuke node based work flow was never convenient in my line of work.
But for the very same reason i felt at home in Maya for rigging work. Mel was a scripting language solely defined to interact with your application. It will fell obsolete and cumbersome to some people by today’s standard but it was a stepping stone to study and grow along side Maya improvement.
The general architecture and the API design was everything i could wish for to combine element the way i needed them.
Its sadly shun over by the young generation or the python zealot who sometime forget that before writing something it might be worth trying to use your tool to its fullest potential .
Node writing obsession:
I think since 2009/2010 i start to study and learn the API on my own.
Back in the days the the only available resources were :
- http://www.comet-cartoons.com/3ddocs/mayaAPI/ : from michael comet
- http://nccastaff.bournemouth.ac.uk/jmacey/RobTheBloke/www/mayaapi.html : An in depth introduction to the maya API by Rob Bateman ,
- http://www.davidgould.com/Books/index.html : Complete Maya Programming I & II
- http://web.archive.org/web/20050308105432/http://www.ewertb.com/maya/api/ : a web cache of Bryan Ewert How-To’s and Tutorials .
So the learning curve the first years was quite steep but at some point i stop counting the number of custom nodes I wrote when i pass over the 300 count.
Node network and visual programming:
I was always reluctant about visual programming paradigm: it feels like people spend more time connecting boxes and organizing the space layout than working on the actual core logic of the task they are trying to accomplish.
Quick prototype are fine and its refreshing sometimes to fiddle around and test an idea quickly switching between expression(which use mel [sorry for the softimage audience]), factory nodes and custom ones.
Code feel more efficient at some-point as even the most simple of operation will expand a graph exponentially .
The real power of the hypergraph lies into the heat propagation mechanism and the visual illustration of the internal dgTimer of your nodes.
click to open in a new window
When you are designing your rig and animation system,or tweaking your asset architecture it will gives far more interesting feedback than the profiler which only give you raw data metric in a lifeless manner without any meaningfully representation.This can sometimes lead to incorrect assumption and diagnostic.
click to open in a new window
But it can prove invaluable as part of a programmer toolkit ( which is different from what a rigger can afford to learn or is allowed to use).
[Above you can see in the image that a skin cluster node take 70 percent of the frame to evaluate: sometime the mesh resolution can slow down the output but most of the time the rig design and small cycle design flaw will be responsible for the evaluation delay]
The magical power of words:
(magic is the bloodstream of the universe…)
It always come to mind when i think of rigging, animation system and software development the riddle asked by the high Aldwin in the movie willow:
- “The power to control the world is in which finger?”
As an old classic the answer was likely to be your own ( each candidate choose one of the wizard finger and failed).
I start to see it easier to teach programming to a look dev artist, modeller or rigger than to teach art to a software engineer . I had rather have a strong collaboration with them asking for a low level api or another task using their full potential and leverage their expertise.
Scripting complex rig and managing their interface through connection and metadata was a useful skill to learn and an obvious answer the network complexity.
The next step for me was to assert that this scripting phase could be though as node prototype:
- once the initial idea was layout we would then start to write a python node and start to study the the graph organization and improvement.
- Ultimately this node will become a first class citizen and be translated as a C++ operator.
I tried during those years:
- to study factory nodes
- combine some of them
- use inheritance to support variation
- mix different element and have a look at hybridization
- play with permutation of parameters and attribute layout.
I had a lot of fun and wasn’t too attach to coding style, not any other cosmetic considerations
After this long introduction i will try to share and publish in the Mayanomicon category my experimentations and code base.
Stay tune for the first plug-in example