Skip to content

Posts tagged ‘ordered systems’

Ordered Systems: Outside in approach

February 17, 2010

Charles

With rigging and animation the key is to allow the source to change whilst keeping the content the same.

Essentially the rigging is the variable, and the animation is the constant – mathamatically its like a corrective. The input shapes can change but the absolute mix we’ve made for them can’t so the difference that makes that absolute changes to meet the new demands of the inputs.

If we use this analogy with the ordered system aproach we can reverse our system.element idea for better results:

“lower.leg.root.character”

This is actually the lower leg bone, and from an outside in approach may work better.  A ctrl may be:

“ctrl.ik.ikHandle.ikSys.lower.leg.root.character”

I guess its where the prority is in the left to right schema.

Ordered systems: properties

February 6, 2010

Charles

As with an object existing as an index of a system, additional nodes, assets etc may affect the system directly or indirectly. For these the only reference thats needed is the system itself e.g.

011 = Root
011-21 = upperLeg
011-22 = lowerLeg
011.property[1] = polevector

This is very rough atm, and currently called a ‘property’ of the system. Anything can be a property of a system including, nodes, controllers, values – it’s just something thats related to the system.

Im assuming we can ask an object/controller/value etc if its the property of a system with x.isProperty returning the systems index its connected to.

Properties just aid the system – there created when the system is created. E.g if my system is a leg, a property in the form of a poleVector may get created. And this may be based on custom information with the system when its saved like “poleVector=True” etc.

Properties are what control the system, and there what get saved I’m assuming if we need to save animation.

How this animation is stored is something I’m not sure about – it would be a transform matrix, but whether it would be the transform relative to the system itself, character, base or the world i don’t know.

The interesting thing with this approach of
parent-system-index|property is that it can work with agile scrum type tracking.

A character maybe a system, with a set of indices denoting steps in its creation. eg.

project X|Assets|Characters|
project X|Assets|Characters|-|PlayerMale|Model
project X|Assets|Characters|-|PlayerMale|Model|-|Mesh|lowRez
project X|Assets|Characters|-|PlayerMale|Animation|-|ambient|aa

With properties of playerMale being ‘name’, ‘role’, ‘height’ etc..