{
“myObject” : {“a property” : “a value”, “another property” : “another value”}
}

The template

At its heart you simply want to build a skeleton apply a template to it and let it build the rest – you don’t need a visual template or guide, infact the skeleton doesn’t need to know anything about the template or vice versa – all thats needed is inputs to the template.

What is this template? To me it’s essentially a hierarchy of functions, with each function defined in a schema. The hierarchy aspect comes in when a function can pass its results to the input of the next function. The ‘intial’ function in the chain could have inputs that get passed to a gui – and the nice thing with this is that it satisfies users needs at each level. At its simplest a layman builds a skeleton, assigns a template to the whole skeleton or a part of it.

The intermediate  user doesn’t need to understand each function of the template, ( defined by the schema) but is skilled enough to build templates mix functions and pass inputs correctly.

The expert user would have full understanding of the schema that drives the functions and the code of the function itself.

The power of this approach is you have a schema that defines functions that are ordered in a template. You can change the order of the functions, remove functions etc in the template, and allow the template to point to a different schema to completely change the results. Very much how an html document uses css to structure the data.

How would a schema work? Something like this I’d imagine:

{
“schema” :
[
{"id" : "ik_system", "path" : "path.module.def.function", "arguments" : [{"name":"joint", "type" : "node"},"boolean", "node"], “returns” : ["float","list", "boolean"]}
]
}

How would a template use this schema? This is the hardest part; i’m guessing something like this:

{
“passedToGui” : [{"id" : "joint", "type" : "node"}, {"id" : "allowStretch" : "boolean"}],

“functionHierarchy” :
[
{"id" : "buildLeg" , "type" : "ik_system", "arguments" :["passedToGui.joint", "passedToJoint.allowStretch"] },
{“id” : “buildFoot” , “type” : “foot_system” , “arguments” : ["buildLeg[0]” , “passedToGui.allowStretch”, 10]
]
}

With objects/attributes following ‘.’ or ‘[#]‘ methodology –  argument passing is still something i’m looking at. But the nice thing with this approach is that is could be used with pretty much any 3d package all your doing is associating functions/defs/methods to a schema and using that schema in a simple template  that users could edit ‘visually’ in the viewport or just by the script itself. Error handling would be to validate the template can work (function results allowed to be passed to other functions) using the schema.

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

With rig, essentially what’s coming across is independence and counter rotation avoidance:

Gross Torso control
Independent hips/chest control
Break joints (Bendbone) at the spine, neck, arms & legs
Isolation in the head, arms and legs in FK (local/parent/world space)
Independence of the head, hands & feet in IK (local/parent/world space)
Natural/Reverse Foot
Stretching in spine, neck, arms & legs
Pinnable Elbows/Knees

Keyable pivots are appearing in several rigs but its definitely not mainstream yet. With facial rigs, one common approach is rising through – morphs, driving on face controls driving bones.

Surface capture has made its debut with LA:Noire. Wonder if there will be a bridging of disciple between both approaches.

http://mariyakarpenko.wordpress.com/

http://www.coroflot.com/mariyakarpenko

]]> http://charleslooker.wordpress.com/2011/05/15/a-request/feed/ 0 charleslooker http://charleslooker.wordpress.com/2011/03/27/mapping-data/ http://charleslooker.wordpress.com/2011/03/27/mapping-data/#comments Sun, 27 Mar 2011 22:20:06 +0000 Charles http://charleslooker.wordpress.com/?p=2772 ]]> 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 ""

• Import models, objects, point cloud data – possibly create nulls etc
• Transforming wouldn’t need specific connections (i.e a transform handle node in Houdini)
• Parenting would be done in the viewport and possible show up in a schematic type view

MotionBuilder similarities:

• Each object would appear as a node or cluster (point cloud etc) – inputs/outputs being position/rotation/scale/xyz
• Local/world space could be used as input output

XSI/Houdini Similarities:

• Nodes could be grouped/compacted into digital asset/compound like object. i.e you could build an IK/FK compound
• Vector operations on the models etc

Operations E.g.

• add, subtract, multiply, inverse, transpose, dot, cross, power,exp, factorial, abs,ceil,floor,mod,arcLength,tangent, binomial
• sin,tan,cos, acos

Case Types E.g.

• If/else/elseIf/finally/then, continue/while, try/catch/throw/break

Value Types E.g.

• integer,float,point2,point3,point4, matrix n*n
• custom variables
• pi, e, etc

Questions..

• Importing data – simple xml data, open customizable
• Animation support?
• Skinning support?
• UV support? Masks?
• Reference space – At one level we want to work on the object itself, at another we want to work on its vertices/knots etc. Operators need to handle both levels of abstraction.
• Is this just for prototyping? (i like this) – need XML to export data to be readable in a standard web browser for translating in final app max/maya etc..

Maybe I’m just describing Houdini/ICE, but this would be purely for visualizing/manipulating object relative data –  custom subsystems e.g. iksolvers, rendering, animation layers, custom constraints etc etc..

More on XSI Compounds here: http://softimage.wiki.softimage.com/xsidocs/ICE_compounds_OverviewofICECompounds.htm

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

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?

Offsets

The offset is a great mechanism for retaining space – it wouldn’t be a good mechanism for FK/IK systems because your trying to force the IK/FK into its opposite – i.e you want its value to change. Can we form a rule here?  When you want the value to change directly transform the object, when you want to retain the value transform the objects parent space.

But..

You still need to allow this approach to be understood by the animator. The offset needs to be understandable, accessible and crucially clean-able!. Any system  that transforms an object by an offset will encounter pops and hitches if the keys of the offset change, get moved or deleted. (Another reason to place them in there own area – attributes etc)