Skip to content

Posts tagged ‘Hierarchies’

Mapping data..

March 27, 2011


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

Re: Scene Traversal…

February 21, 2011


A very simple way to unify all this is to make everything use the same basic tag structure, and semantically traverse through it using the ‘type’ property. This makes more sense in max as everything would need some sort of custom attribute tag. A simple example:

‘tag_arm’ would have three children referencing tags: ‘tag_upper’, ‘tag_lower’ and ‘tag_hand’ – it could have  a child ‘tag_ik’ and ‘tag_fk’ too,  which in turn would reference the ik/fk bones, controls etc..

Functions would get passed via the .children property, and probably by a cleaner function to get a child ‘type’ from a tag. Functions could in fact point to types of tags, held in the children property. For instance an fk/ik snap function held on the arm_tag could check if in its children existed a ‘tag_fk’ and ik type.

Just thoughts atm..

Understanding scene traversal..

February 21, 2011


I’ve been looking into Bungies approach to scene traversal, and thinking about how it would work for max. I look at it from time to time – but have recently taken a greater interest into as I’m solidifying a lot of my methods and need a way to traverse there hierarchies.

Essentially (from what i understand), they have metadata nodes which contain standard attributes: type, version etc, children which reference other metadata nodes attached and any additional custom attributes which reference nodes that are attached. Nodes are attached via a .metaParent attribute to allow recursion up to the ‘meta parent’

Im assuming both meta nodes, and nodes themselves use the ‘.metaParent’ attribute to recurse up until a ‘meta root’ is found, and if not how does a meta node find its parent?

In max, i think this would mean single or multiple attributes on the same or different objects could reference each other using the .metaParent’ and ‘type’ attribute.

Where a metaNode or Tag as i like to call it, contains custom attributes pointing to the nodes attached for a specific system such as ik, it essentially becomes a ‘Hub’ with the ability to inherit functions of the tags connected to it.

Would this make the ‘meta children’ attribute redundant though?


July 29, 2010


When constructing heirachies do not use the ‘next child’ method of connection/visual display. More-over build the heirachy as one system and visualize its connections with another E.g.

With a hand do not build the hand as connection between the forearm and the hands first child. Rather construct the heirachy with connections between them I.e.

Elbow > Elbow To Wrist > Wrist > Wrist To Index Finger

This should be noted for all hierachal construction methods.