Skip to content

Posts tagged ‘modular rigging’

Disney’s dRig

December 16, 2012

Charles

I really like Disney’s approach to rigging – with their latests paper instead of building modular units such as ‘arm’ or ‘hand’, they’ve instead devised a method to make the coding itself humanely readable and easy to understand.

Variables & Operators

I’ve been thinking about this myself and essentially it breaks down into two things 1) you need to be able to assign variables and 2) pass operators.

If we take a simple class based function:

create.box(length=1.0, height=1.0, width=1.0)

We have have some base fields – the class, its method, and some arguments passed as assigned types. So what does a field need if it was humanly readable?

  1. Firstly it would need a value for the fields name.
  2. It would need to know if it can pass multiple values.
  3. It would need to know if it passes values or fields.
  4. It would need some sort of rule on its syntax and definition.

So for the above method we’d have something like this:

CLS create DEF box ARG  3 FLOAT length 1.0 FLOAT height 1.0 FLOAT length 1.0

So pretty straight forward – each of these CLS, DEF etc is a field type, with its own rules that govern what the next input should be. An example with a list field could be as follows:

LIST none 2 FLOAT none 1.0 VECTOR none [1,0,1]

So this is a list field type, which has no assignment (thats why its none), has 2 for the next input because it allows for multiple inputs. The reason why the next input is FLOAT is because crucially, fields need be able to pass other fields as input. So the code would compile to something like this:

#(1.0, [1,0,1])

The ‘#()’, is a syntax definition for the field, along with the ‘,’ – values/fields passed to a field could and probably should have a syntax definition too.

With something like this we could code a framework pretty easily, and because these are just one lines they are pretty easily modded. Here’s an example of say an ik chain:

CLS ik_chain create METHOD none chain ARGS none 3  VECTOR none [0,0,0] VECTOR none [10, 0, 10] VECTOR none [0,0,20]

This would evaluate to something like this:

ik_chain=create.chain([0,0,0], [10,0,10], [0,0,20])

What i don’t like about this is assignment is using none when its not really  needed – which i dont like. Crucially i think the string you’d pass should only have what you need. E.g.

CLS ik_chain METHOD chain ARGS 3 VECTOR [0,0,0] VECTOR [10,0,10] VECTOR [0,0,20]

And even the field types themselves could go possibly?

ik_chain create chain 3 [0,0,0] [10,0,10] [0,0,20]

But now we have a problem – by stripping field types etc.. we start to lean towards a structured string. 3 for example can’t be placed anywhere – in fact what does it mean without some association?

So defining fields allows for customization, but we have to be careful to only give enough information for the data to be compiled. My hiccup is that anything can be assigned e.g.

var=1.0

So do we type ‘FLOAT var 1.0’ for it to be assigned and ‘FLOAT none 1.0’ –  for it not to be? It’s seems the none is just extraneous info we don’t really need. Could value that gets passed to the rule allow for assignment? e.g.

FLOAT ‘var=1.0’ – we’d have to split this string based on the ‘=’ and then pass the second half to the rule.

CLS ‘ik_chain=create’ METHOD ‘chain’ ARGS 3 [0,0,0] [10,0,10] [0,0,20]

Advertisements

Modular Rigging

March 5, 2010

Charles

So starting to think about modular rigging, discussed on the CGTalk forum. The basic process for this I’m thinking about is having a common  skeleton (player, creature, etc) where its used as a template  to build an animation skeleton.  Animation data can get baked down on to the skeleton, or mapped up from the skeleton. And the skeleton itself can be used for generating FBX, mocap, etc

This sounds pretty common, but Im just starting to see the benefit of it. Alongside this ILM’s block rigging paradigm could be used for the animation skeleton- rigging blocks for legs, feet hands plug-n-played for different shots, scenes etc. Some remits:

Common template skeleton

  • Must have a non-broken hierarchy, including end (nub) bones.
  • Must use a common coordinate system throughout.
  • Must have a common naming convention throughout

Animation Skeleton

  • Rigging blocks can be created in isolation.
  • They return outputs/inputs to allow other blocks to connect to them.
  • They can be removed easily without ill affect on other blocks.
  • They have common attributes that can be shared.
  • They can be traversed easily, back to a common ‘grandfather’.
  • Optional: A common markup language for there creation, XML etc.