When I started working at Mikros Image in Montreal, I knew only the most basic and fundamental things about Python and hardly any MEL at all.
I feel responsible for salvaging and recording some of the lessons I've learned through my experience over the past year. I think there's untold hours spent educating myself, so I think the best way is for me to describe some of the topics I have learned in the process of writing scripts and tools for myself and my department.
I feel responsible for salvaging and recording some of the lessons I've learned through my experience over the past year. I think there's untold hours spent educating myself, so I think the best way is for me to describe some of the topics I have learned in the process of writing scripts and tools for myself and my department.
...Here goes!
One of the first things I was tasked to working on was implementing a semi-dynamic system for the animators to use on one of the characters. This would reduce the amount of hand-animation they would be required to perform per shot to get natural overlapping secondary animation on this character's hair.
There was a great deal already existing in the character rig I did not understand. There was no way for me to implement the changes I needed, by hand, without taking a ridiculous amount of time and iterative saves, to preserve a history, in case something broke.
- I think it was at this point that I truly acknowledged the time-saving quality of even this amount of limited automation. I feel that the majority of rigging tasks can be made less tedious by using a modular scripting approach. In the end, I think I probably wrote around 6000 lines of code trying to deal with my problems. Although most of it was VERY verbose and inefficient, it was a fantastic exercise.
I was once told:
There was a great deal already existing in the character rig I did not understand. There was no way for me to implement the changes I needed, by hand, without taking a ridiculous amount of time and iterative saves, to preserve a history, in case something broke.
- I think it was at this point that I truly acknowledged the time-saving quality of even this amount of limited automation. I feel that the majority of rigging tasks can be made less tedious by using a modular scripting approach. In the end, I think I probably wrote around 6000 lines of code trying to deal with my problems. Although most of it was VERY verbose and inefficient, it was a fantastic exercise.
I was once told:
"If you want to truly learn how to code; script everything you would normally do in Maya, every day, for a week." - Dimitry Kachkovski
I started to learn the architecture Maya uses in it's node networks. I have read through books on programming for Maya, learning about the DAG and DG networks, UV space versus 3D space and the relationship between numbered components.
I learned the difference between using Python for Maya API versus just accessing the maya.cmds or maya.mel modules. I started creating my own modules for organizing and simplifying my code base and tools.
Because the maya.cmds module makes such heavy use of strings, I've become a master of string manipulation.
I have made use of lists/dictionaries, as well as list/dictionary comprehensions.
Modules I've started to use: (in addition to the maya.cmds/maya.mel and nuke modules)
sys, os, re, datetime, random, math, shutil
I started scripting for Nuke, and I really like it. On the surface, it seems to be much more... organized than using Python for Maya. Some things still don't make sense and probably won't until I invest the time into truly understanding OOP.
Using the maya.cmds forms, I've created a UI toolbox to handle various production-based tasks: Dealing with project directories,
handling global/local variables as set by the environment,
a LOT of scene-specific constants <hard-coded naming conventions etc.> made me kind of ill,
cameras, render settings, alembic imports/exports,
FX asset importing/exporting from/to file, FX rig re-creation
I took some time to learn about Maya's referencing system and how to unlock and import referenced objects.
(Unload, unlock, load, import... stupid.)
During production, I was responsible for trying to make the process of hair simulation... simple...
In the end, my tool dampened the movement of the characters through the world, cached necessary dynamic systems iteratively to file (non-destructive), and lastly; created a playblast of the shot camera for review also iteratively.
This enabled a user who had no previous experience doing simulation to process shots. This allowed me to simply give advice for parameters to adjust shot-by-shot.
(Similar tools allowed me to leverage 3 computers running 4 simulations each, at one [very stressful] point in the production, to complete ~15-20 shots in a single night.)
I wrote scripts to approach various problems:
- Building and assigning custom shader networks to objects (ie. parti-volume shader network for rendering Mental ray volumetrics <GOD RAYS!>)
- Offsetting/randomizing animation curves/keyframe points.
- Taking a paintFX stroke on a surface drawn from the camera's perspective and turning it into a curve (unique to the currentFrame on which it was created) for use as blendShape targets for making art-directable curve motion. (I then attached a hair system to the blended curve to give it more... natural behavior)
- Taking a set of nodes and copying all parameters of the nodes down to text files in an interpretable dictionary format which could be read and applied to the same node later (kind of like the presets in Maya...)
I've started learning about clean coding practices. How to organize myself and write readable, concise, well-commented, practical code. Incorporating some PEP8 standards into my own scripts.
My journey has only just begun...