# Posts tagged ‘Rigging’

Sorry for the delay, pretty busy here at work essentially rebuilding some big pipeline tools, systems etc etc.

First up I’ve got a new idea for an animation controller which I’m sort of keeping under wraps. Basically rigs are hooked together by controllers which are animated, problem is most of these tend to be custom – what im planning is a very basic controller that does advanced transforms very well – on top of this customly defined controls can be added on top – which get sort of ‘wired’ into the system.

Secondly I’ve been trying to explain (hopefully) transforms over at CGTalk. A transform is basically a direction with a spin projected by an offset about a coordinate system. Now this sounds a little complex so over the next few posts i’ll explain them a little bit better hopefully with some interesting examples.

Just wanted to give a quick run down of how my brain works tackling a problem, I recently saw a video of a dynamic tail a friend of mine had sent me – the obvious approach would be verlet, a system where you can keep overlaying solvers ontop of solvers. But another key system the tail had was to maintain its shape whilst being dynamic this sent my brain into overide! How is this possible – here’s how my brain would solve it (this hasn’t been tested, all theoretical):

A chain of controls, points and bones. Get the transform space of the second control onwards, build a verlet framework of the points, with stiff rods connecting them and  point constraints made by getting the relative space of the control relative to its parent multiplied by the same points direction , i.e point 3 use the transform position  of control 3 relative control 2 multiplied by the direction of point 2 – point 1.  Finally build a matrix transform from this and apply it to the skeletal chain consecutively.

Now i dont know if this is correct, but this is how my mind thinks – i build little systems and stick them together, then i spend the biggest chunk of time getting the systems to talk nicely to each other.

Here are some notes on natural spine rigging, im not going into details about stretchy spines are most of this stuff wouldn’t apply especially to do with twist.

• Natural spines do not make ‘N’ shapes!, the top chest part never goes below the lower pelvis part. The lowest the mid section can go is 90 degrees perpedicular to the lower part and top part. – This can be easily accomplished to never go below by using simple dot product math. Which beings me on to my next point.
• The spine system i used and still do is three bones: bottom, mid and top with an IK chain running between the mid and top joints – this allowed me to always make good ‘S’ and ‘C’ shapes, with the spine always keeping its length.
• For deformation ride a simple chain with a complex one, the ribbon spine approach is elegant approach to this. It allows for deformation to still happen when controlling the simple chain in FK mode – my approach is similar to this but is grounded in math.
• Do not try and reach the ‘holy’ 360 degrees in all directions, the math is insanely complicated (trust me!) and more pertained to tentacle rigging where by its controlled by deforming a curves control points in position space rather than rotational. A combination of 180 degrees in yaw and pitch, with a twist of -180 to 180 is fine.
• The animation mechanism can should work in Euler rotation space, by the system underneath directly driving the spine can work in quaternions, in fact i strongly recommend riggers learn quaternion math – naturally most of rotations from the shoulder to the wrist work in a hemispherical space. The key is extrapolating the combined rotational systems creating the final deformation.

$Obj_{p} = ((IN^{-1})O)_{p}$

(A part of one of my equations)

I have to admit I love pure math. I’ve filled probably seven or so moleskine notebooks over the last several years with my version of it – it’s the quickest and  easiest way I find for me to express my ideas. The  syntax part has only come recently in the last couple of years or so; but the processes for me to formulate my work into this approach has been a long time coming.

The problem Im noticing now is how the interpretation of pure math can be so clumsy, muddy and down right bloated in comparison. One line of pure math can be so elegant it borders on being beautiful – interpret this line and you have some of the dirtiest scripting and code imaginable. Have I become a pure math snob??

I don’t think so, in fact I dont think i’ll ever write pure math in its purest form – I have too much software scripting/coding interpretation in my brain. In fact its become more a system I can interprete visually very quickly. I half-way house if you will, where my brain can ‘see’ what I write – A hybrid mix of scripting  and math wrapped up into a pseudo-pure math form.

I’ll be writing more of my hybrid-math on this blog, hopefully it will help you as it does me understand what the ‘essence’ and solution is to rigging problems.