Yesterday I turned my autorig github repo to from private to public. I’ve been working on this for the last two years. This is a modular auto rigging tools that I was longing to do but unable to find time in my last job. To me, being able to develop your own autorig system is basic for a studio, instead of using only off-the-shelve solution.
https://github.com/nickyliux/nl_rigging_tools
This is not production ready yet. I’m going to capture some demo videos to show what it can do so far.
An idea comes up suddenly … priority.
I can’t remember for how long when I animate a character in Maya, I turn selection filter to nurbs curve only. When I need to select non-curve objects I turn back on for all. It is simple. It works always.
One day I was scripting for the corrective joint logic for fingers and I could always select the joint because of priority. Oh wait ! I then started to look for priority setting in the preference. I changed the preset to “Custom” and found that the priority for nurbs curve is larger than mesh (4 > 2) !!! Yo ~
Still feel great to find little improvement in everyday work. Or maybe much more shocking to switch to Blender one day.
While I’m almost done with my own modular rigging tool in python, finally I found a good reference of how a custom node editor can be written. https://github.com/golubevcg/maya_node_editor.
At the very beginning I was trying to build the entire tool into a node graph interface. This is not trivial as the coding of the UI can be a big project itself. It is really tempting to build this way for better usability. I’ve forked the project in github and hope that it would be useful in the future.
This is an update about the soft IK video I made almost 10 years ago. I got a question from an audience about adding stretchiness on top of it. While the original source of explanation for Softimage is gone, I had better jot it down before forgetting again.
Here is the updated scene file Soft_IK_END2.ma.
For anyone who haven’t heard of soft IK, it is about “softening” the pop when the ikHandle moves from fully extended to un-extended position. The solution here is to limit the ikHandle’s position such that the joint chain never go straight no matter how far the control goes. We need the equation below.
When x → infinity, y → 1 but never equal to 1
See the graph below. We use a variable soft to define a starting point Ds = D * (1-soft), which is slightly smaller than D.
When the ctrl is moving away from the root joint, and reaches Ds ( along x-axis ), the ikHandle starts to slow down ( along y-axis ), moving toward but never equal D.
You could test and play with the graph interactively at https://www.geogebra.org/calculator. Download and Unzip my graph SoftIK_graph.zip. Load it by Open > LOCAL FILE.
Below is the expression in the scene file. Stretchy works by multiplying the scaling ratio to both joints’ scale x and the offset for the joint softJ_end. You may also note that I’m using D * (1-s) instead of D – s in the old version. It seems that the result would be more consistent for characters of different size.
float $D = 9.715;
float $soft = foot_ctl.soft;
float $d = distanceDimensionShape1.distance;
float $Ds = $D * (1-$soft);
float $stretchy = foot_ctl.stretchy;
float $scaling = (max($d / $D,1) - 1) * $stretchy + 1;
if ($d > $Ds)
softJ_end.translateX = $scaling * $D * (1-$soft * exp( -($d-$Ds)));
else
softJ_end.translateX = $d;
joint1.scaleX = $scaling;
joint2.scaleX = $scaling;In my own autorig they are all done with utility nodes. But it seems handful to keep the expression scene as it is faster to experiment with ideas and equation. There are some free plugin solutions which should be more efficient. But I think this is not too difficult and is worth learning if I could apply it somewhere else in the future.
For the last few months I’ve been building my own modular rigging framework and tools. As a very early version, I try to make the UI as simple as possible. There are a few professional projects around. I’ve just added a page Gems to jot them down. Some UIs are quite “stunning” to me. Although rigging could be complicated, I hope I can simplify things unless neccessary.
Here I find the Python Style Guide by Google. I did write years of MEL and it could be hard to manage when it goes over several thousand lines. I’m now learning to refactor codes as frequent as possible to shorten pick-up time.
Having subscribed another month of ProRigs in April, there are always little thing to learn. For example, the outsole of a running shoe is usually a bit off the ground. In the past I would see it as pure flat. In their rigs I found that a simple extra set-driven-key is added at the very start during the foot roll. The action is more believable with this tiny detail.
I came across an impressive reel by Mateusz Poplawski https://vimeo.com/mpoplawski This is inspirational on how rig features could be shown in a concise way. Recently I’m checking with the characters by ToyRig www.toyrig.com. Not only they are free, the smearing feature is amazing. Just like some of the rigs some joints and meshes are locked and hidden. So if you want to see them for study purpose, open the file in an editor. Search with the hidden node name. The answer is quite obvious 😀
Recently found a great resource of skeleton reference for animal : vertebres3d.fr
For some times I’ve been collecting skeleton models as basis of my auto-rig tool. They are good as a template to work on but some of them are edited by modeler and polygons are reduced. The skeletons in Vertebre3d app are detailed and accurate by scanning from museum collections. It would be cooler if download is available. 🙂
Giant Man, ProRigs.com
There’s always a lot to learn in other’s rigs. The characters by ProRigs are affordable and the models are nice. The arrangement of attributes is clear and the ribbon setup is well designed.
I would subscribe later for further study since my current month’s subscription is about to end. Time to jump back to previously unfinished tutorials for a clearer picture of rigging a complete character.
While learning thru advanced tutorials, it’s time to consolidate some basic concepts in Python. The explanation about property at https://www.programiz.com/python-programming/property is very clear. I’m writing an example below to remind myself of the private variable _cm being a convention only. Name like temp_cm works too.
Also cm is no longer a normal instance variable when property decorator is used. The design of adding @property allows backward compatible to keep codes unchanged!
class Unit:
def __init__(self, cm=0):
self.cm = cm
def toInch(self):
return self.cm * 0.3937
# @property
# def cm(self):
# return self.temp_cm
#
# @cm.setter
# def cm(self, v):
# self.temp_cm = v
unit = Unit(cm=100)
print(unit.__dict__)
# {'cm': 100} Without getter setter. The old way.
# {'temp_cm': 100} With getter setter. The code still runs. It's backward compatible !