Skip to content

Posts tagged ‘Controllers’

Who owns keys?

October 23, 2010


I think about rigging, frameworks, articulation  etc a lot Рin fact I think about it most days, fighting battles in my brain on how systems should work. The simplest, no the most elegant way to give an animator as much control without hiding them in layers of abstraction (something the current tools I work with, have a lot of issues with.)

Today its all about key ownership and whether TDs should interfere with them – with systems like fk/ik and space switching keys are essentially used for gluing the ‘state’ of each system together seamlessly. But I’m not sure if we should be be manipulating to support the mechanisms of the rig outright – i.e. for the rig to work.

I work with a lot of animators, who’ve come from all walks of life – the one thing I’ve learned over the years is to let them own there keys and not create them for them. I.e. they control the space, weight and mechanism of the rig. They tend to hate keys embedded on hidden controllers, deep within the graph or keys bundled in with mixed systems e.g a key automatically getting created for the transform of the fk/ik with another for the weight of the system.

It’s great as a technical demo i’m just not sure I should be making keys that are only there to allow a rigging mechanism to work. I’m actually learning towards openness in space switching as ik-fk does with separate controls for local, world and parent spaces.

I’d rather have an animation know exactly know how there rig works and take a extra time I think , than to make it seamless and embed hidden keys into the rig – that are hard to get at.

Encapsulation and incorporation without loss of independence.

July 4, 2009


No this isn’t about politics, more a case of keeping assets tied to a system, that allows them to be flexible with all departments – animation, tech and art, whilst being editable and exportable en-mass.

The most important factor is iteration. Assets, animation, and rigs will get iterated over time and you need the ability to change and update them whenever.

Assets need to be editable/exportable on mass and externally, to not slow production down. Version control systems generally have a locking process that means if all your assets are on one rig, another user will have to wait for the unlock or submitted changes to get it. Using externally linked or tied resource means, a tech guy can make changes to the file and user needs only to reload the resource back to get changes, even if the users had those assets loaded with the saved scene. Essentially dynamic referencing or passive referencing is crucial.

Animations are gold, and so need to be kept to the highest fidelity when loading them onto another rig. Crucially what needs to be kept between rigs is animation controllers, not bones. A mapping file then only needs to use what it finds to reload the animations back onto a rig.

The rig has to be updatable, and in a non-destructive way to the scene. It needs to get either dynamically changed – controller changes already existing and nodes that get removed and updated attached to the rig; or passively changed – where the entire rig along with everything attached to it gets loaded out and reloaded in with updates.