Skip to content

Posts tagged ‘postaweek2011’

Understanding scene traversal..

February 21, 2011

Charles

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?

Re: Owning Keys

February 13, 2011

Charles

Maybe I was a little hasty. Crucially when it comes to keys, animators need to know the reference a value exists in – and that, it shouldn’t change.  For example if I animate a guy jumping from one platform to another – the curves of the jumping, moving from and to the platforms shouldn’t pop erratically to allow its reference space to change. More over the the space the values are relative to should be transformed.

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)