Skip to content

Posts tagged ‘Data’

Mapping data..

March 27, 2011

Charles

Data is becoming more and more important to share across multiple rigs, skeletons, skin etc. Data itself can essentially be dependent e.g. skin weights are dependent on a model and a list of bones or non-dependent, a skeleton in the scene for example. Mapping too can either be online i.e live captured or offline i.e baked/plotted down. I’m slowly working on a format the allows for mapping different types of data in max.

My idea is to first store a list of id’s for the source objects, and a list of ids for the destination objects. An objects controller (treated as a string – exprForMaxObject) would get mapped to several other objects via there id and im guessing some sort of expression. Mapping a value to multiple values is the trickiest part and also calling an expression on them. Heres an example:

1 "root_a"                                              1

2 "root_b"                                              2
3 "spine_b"

1 bezier_float "pos.controller[1].controller" 2         3
2 "pos.controller[2].controller"                        4
3 "pos.controller[1].controller"
"@2+@3 + 10.0" 4.0                                      5

So firstly (1) we store the ids for the source objects and there names, they could be hierarchal in theory if we add an additional id for there order. Secondly we do the same for the destination objects. The meat of the mapping (3) basically stores firstly the id of the object being mapped, then the class of its controller, and the controllers “object” lastly we store the amount of target objects its going to be controlled/mapped to.(4) we store the target objects id and there controller “objects” – we don’t need to define the class of there controller object i think because its an explicit approach i.e it inherits the type from the ‘mapped object’ – this my bite me in the ass later though as for example point3 and bezier_pos look identical.

(5) lastly we call and expression using the target objects id’s – this is a little messy as i have to determine if the expression is using the id or just a regular value. “@” is an idea for the minute. In theory you could call whole functions e.g “myFunction #(@1,@2)” as long as it returns a correct type . Lastly i store an offset value, why?, well if were not passing a function but still want a offset value applied – e.g. transform offset.

This just an idea for now, I’m not sure if ill store the target id’s in parenthesis “{“,”[” etc.. It’s pretty humanly readable which is good, and easy to change objects just by changing the string the id points to. Controller objects are harder to change, its why i specify a class type way at the front for them to compare against. How this works for simpler 1:1 mapping might get messier e.g. mapping a skeleton to another skeleton for skin weights..

1 "root"
2 "spine"

1 UndefinedClass "" 1
2 ""

BVH You evil, evil little man!

September 4, 2009

Charles

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.