Skip to content

Posts tagged ‘Animation’

Isolation at the neck, head or both?

May 29, 2011


Most bipedal rigs tend to have isolation at the head, but a lot of quadrupedal rigs have it at the neck – is it really a case of spreading the isolation from the chest to the head over the length of the neck? This doesn’t seem true of a giraffe – in its case the neck is a column that can be independent of the spine, with secondary bending at its center.

I’ve done both, but am thinking if there’s a commonality between – i.e an approach that can use both.

Who owns keys?

October 23, 2010


I think about rigging, frameworks, articulation  etc a lot – in fact I think about it most days, fighting battles in my brain on how systems should work. The simplest, no the most elegant way to give an animator as much control without hiding them in layers of abstraction (something the current tools I work with, have a lot of issues with.)

Today its all about key ownership and whether TDs should interfere with them – with systems like fk/ik and space switching keys are essentially used for gluing the ‘state’ of each system together seamlessly. But I’m not sure if we should be be manipulating to support the mechanisms of the rig outright – i.e. for the rig to work.

I work with a lot of animators, who’ve come from all walks of life – the one thing I’ve learned over the years is to let them own there keys and not create them for them. I.e. they control the space, weight and mechanism of the rig. They tend to hate keys embedded on hidden controllers, deep within the graph or keys bundled in with mixed systems e.g a key automatically getting created for the transform of the fk/ik with another for the weight of the system.

It’s great as a technical demo i’m just not sure I should be making keys that are only there to allow a rigging mechanism to work. I’m actually learning towards openness in space switching as ik-fk does with separate controls for local, world and parent spaces.

I’d rather have an animation know exactly know how there rig works and take a extra time I think , than to make it seamless and embed hidden keys into the rig – that are hard to get at.

Ordered Systems: Outside in approach

February 17, 2010


With rigging and animation the key is to allow the source to change whilst keeping the content the same.

Essentially the rigging is the variable, and the animation is the constant – mathamatically its like a corrective. The input shapes can change but the absolute mix we’ve made for them can’t so the difference that makes that absolute changes to meet the new demands of the inputs.

If we use this analogy with the ordered system aproach we can reverse our system.element idea for better results:


This is actually the lower leg bone, and from an outside in approach may work better.  A ctrl may be:


I guess its where the prority is in the left to right schema.

Generalized ordered systems

February 6, 2010


Im working on an ordered theory for building rigs and loading animation. This is a general approach that isn’t reliant on rig construction at all, just an paradigm for ordered processes.

‘parent > system > index’

The theory follows some basic strict rules to determine an objects id in a system, and generalize relationship – not in any way its physical parent etc (though i can be used for it). An object is first represented by its parent, then the system its in and finally its index of that system. A root object for example can look something like so:

‘011’ or [0][1][1] or [0]system[1][1] – the first part denotes the systems parent, in this case ‘0’ represents nothing or ‘undefined’, the second part is the system index – in this case its the first system of the rig. Lastly the index denotes that its the first object in that system. Note that the parent index, and the last part ‘index’ and co-habit with each other. This will be explained now:

Once a root/base/first system has been establishes with its id; 011 extending this to cover new relationships is easy. Adding a leg system to this can be referred to as:



parent|system|index| – |system|index|

Reading this id (right to left) we can see its the 1st bone of the 2nd system, which is in turn parented to the 1st bone of the 1st system, which has no parent.


System can have multiple objects , we just need to determine there index. On creation of a system, an index of 1 always follows as a system or object cannot exist without one or the other. Object represented by an index do not need to be parented – they can if need be, but its not necessary.

Rigging information such as the how the object in the system are setup is purposefully left off, as this is more of a generalized approach than a finite one. Addition information about the system could be held in a’custom’ variable such as #(“leg”, “ikfk”,poleVector”) etc..  This is to allow a system be constructed in any manner we see fit I.e. there maybe a system for the entire leg, or one up to the ankle and another for the foot.  Crucially its dependant on how you want to build your systems.


Constructing a  system we first build the base system and object, ‘root’ in this case. Addition systems need to know about the system there connected to, and as before this does not need to be a physical parent just a connection to the entire system.

BVH You evil, evil little man!

September 4, 2009


BVH (Biovision) motion data is evil and I for one hate it! I wish when they had come up with the hierarchy, rotation order and transform methods they have firstly in world space, treated rotations as vectors and treated parenting as loosely as possible.

All you want for an animation format is a position of the joint, its direction and its spin – all in vectors with the position being in world space. This way any additional info like parenting can be bolted on without affecting firstly the initial pose or the animation. (as there keyed and set in world space)

The power of this is that, you could just have a set of positions and animation data without any vector info for direction or spin eg.

pos dir spn
[10,10,10] [0,0,0] [0,0,0]

And use it for raw mocap data such as TRC, or Vicom. But also by giving each joint an additional vector value for direction and spin you can use it as an intermediate format to a character rig. Parenting can still exist.

The power of this is that additionally, joints arent tied to the parents local space, and therefore you could store stretching infomation.

Encapsulation and incorporation without loss of independence.

July 4, 2009


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

May 25, 2009


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 ‘raw’ animation format

August 3, 2008


I was thinking over the weekend about a simplified animation format – something that takes out the two main issues I’ve been dealing with (and it appears a lot of other people have) in general: hierarchy and axis of joints.

I’ve worked on two motion capture shoots so far, and am currently helping pipeline issues on another project. The biggest problems i see with solving the data are first the hierarchy of the joints – if the aren’t exactly in the right order your BVH ends up truncated on the finally rig, or if the joint axis order is wrong (BVH is ZXY generally) rotations break.

Compounding this is that you can have different channels, different axis orders and custom hierarchies in BVH make it a nightmare solving to custom rigs. A skeleton also cant be broken – something that can be a pain to deal with in BVH.

I was thinking of an intermediate  file format possibly in XML, that would be only contain the position of a joint, its direction and twist – all store as world vectors. The format could also hold ties to a virtual hierarchy in the form of ids similar to Valves proprietary format. Something roughly like this:

<joint id=”0″>





I wrote an importer for BVH, that used a simple sorting order to work out the hierarchy ‘0’ would always be the root, followed by 1,2,3,4 etc.. if the numbering was sequential i.e 2,3,4 or 3,4,5,6 then id know they were children of the preceding numbered joint eg.


0 to 4 would be one chain but the next number 2, would become a child of the 2nd joint in the first chain and then be sequential until it broke sequence. Nifty! The format idea would only use this virtual ID if it needed to make a hierachy for BVH etc..

Outputting to this format though would still need end joints/nub bones to determine length as this is worked out using the <direction></direction> vector. Really its just a simple quaternion animation exporter using vectors for key properties.

Some rigging notes & ideas today

October 9, 2007


What is rigging?

  • It’s very important to be aware of what rigging really is – in essence is a system for the animator to pose a character effortlessly and and efficiently.
  • It’s a control mechanism that ties the character to time.
  • It’s a marionette for a puppeter (you could classify a mo-cap rig as this, the actor being the puppeter)

Automation Vs Manual Controls

This is an area that really takes a long time to get grip with, the trick is finding the right balance of controls for the animator,  over use-ability and efficiency. Essentially you have to think, if I automate this does it out-way controllability if I was to manually control it – and is it more efficiency.

automation/manally = posability/efficiency

More on animation pivots – the offset position.

August 30, 2007


Edit: My last post was more of a hinderance  than a help, so i took it out.  

In my  last post I discussed a possible way of doing animation pivots – it sadly was just notes in my book and spare of the moment ideas. I think i missed out a vital chunk, and i think in theory I can make it a little cleaner – weak referencing not needed.

So this is still theoretical, but if we examine a standard object matrix3 transform it contains the transform space and its pivot space i.e the offset to keep it in the right position. So if we essentially generalize this idea (i.e making itself over the top of itself) i think we can work it out.