Biotensegrity: The geometry of Anatomy

This is something I’m very interested in, its the study of tensional integrity (Buckminster Fuller) in biology. From an aesthetics point of view it would probably fit in the field of  dynamics – but I’m coming from the standpoint of evolutionary kinematic constraints. Essentially that the notion of our evolutionary movement can only conceivably  end up in our current form. Our wrists, shoulders, hips, spine etc can only work they way they work, because its the only way they can.

Now I’m not including ideas such as being double jointed etc, but from a general standpoint I find the ideas found in biotensegrity a sort of bridging of the mathematical  models we create in rigging and real world biology. We both end up with the same results – e.g. the spine in a tensegrity model and a mathematical one have the same limits, rotation spaces and constraints.

It is said that mathematics is a poor man’s representation of nature – but the fact that it can represent it with enough detail as being real its pretty exciting to me. Tensegrity i find is a beautiful connection between nature and maths.

http://www.intensiondesigns.com/geometry_of_anatomy.html

Encapsulation and incorporation without loss of independence.

No this isn’t about politics, more a case of keeping assets tied to a system, that allows them to be flexible with all departments – animation, tech and art, whilst being editable and exportable en-mass.

The most important factor is iteration. Assets, animation, and rigs will get iterated over time and you need the ability to change and update them whenever.

Assets need to be editable/exportable on mass and externally, to not slow production down. Version control systems generally have a locking process that means if all your assets are on one rig, another user will have to wait for the unlock or submitted changes to get it. Using externally linked or tied resource means, a tech guy can make changes to the file and user needs only to reload the resource back to get changes, even if the users had those assets loaded with the saved scene. Essentially dynamic referencing or passive referencing is crucial.

Animations are gold, and so need to be kept to the highest fidelity when loading them onto another rig. Crucially what needs to be kept between rigs is animation controllers, not bones. A mapping file then only needs to use what it finds to reload the animations back onto a rig.

The rig has to be updatable, and in a non-destructive way to the scene. It needs to get either dynamically changed – controller changes already existing and nodes that get removed and updated attached to the rig; or passively changed – where the entire rig along with everything attached to it gets loaded out and reloaded in with updates.

Transforms, matrices, ideas and the likes..

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.

A meta-data paradigm for rigging.

I was reading up on Bungie’s modular rigging and ILM’s block party – they talk about modular nodes that define how the character is made and built. I think it’s a great system to use and I’m still trying to get my head around it!

My aproach is to treat the system as searchable properties with values. Nodes with assigned properties can be then rigged based apon them e.g a bone may have a property called, “left”, “leg”. And have sockets and plugs (ala ILM) to tell it how to be rigged.

My only problem is that how are properties different to each other to be meaningful? I.e we can rig a leg it different ways – how does it know which way to use? It may be just another simple tag like “basic’ or ‘dynamic’ but im not sure.

Bone:Left:Leg:IKFK? – maybe its this simple?

Also, do we need attribute headers i.e properties – “Type”, “Description” etc or just the values themselves, “left”, “arm”, “IK” ? Personally I think you have to have properties as firstly not everything should be a string and secondly most importantly how do you differentiate between numerical values of 2 or more properties? e.g TYPE:2  LOD:2 now two values of  2 are essentially meaningless, unless they have some identifier.

I’m going to pursue  this further as i think its definitely the way forward.

How my brain works… a quick example.

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.

Notes on natural spine rigging

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.

Pure Math vs Interpretation

(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.