Skip to content

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.


Post a comment
  1. October 23, 2010

    This is a great topic for discussion, and a good post.

    I am not sure what system your working in but for the most part I think animators feel more “secure” knowing what has keys and where they are because they don’t have to be as careful about adjusting timing and poses etc.

    But, I also don’t think they want to have to worry that they forgot to keyframe something that needed to be in order for the rig to work. There are also issues with this and Auto-key and animator working preference.

    There are ways to do both I think and both MotionBuilder and Maya have done some work in this regard. MotionBuilder has the concept of keying groups or sets of attributes that get key framed together when you key a control. They also allow reference or (instanced) animation properties to be added from one object to another so that you can create a master keyframe control object that always shows all the keys for a particular system

    Maya tried and (some people use them successfully) via the Character Sets system that creates a grouping of keyable attributes that you can have all live in one place or in sub groups/characters. A better and more powerful solution I think is to use the new Asset system in Maya allowing to you group nodes and publish /expose only the important animation attributes to the animator so you could group all the nodes that need to get keyed in say a space swtich , publish the channels to the asset with names that make sense to animation and this moves any hidden or mystical keys from the depths of the rig and places them front and center ready for animation to edit/fix/control and they can see right away what they are editing with out having to do anything more than select the control they were going to do anyway.

    In Max I have used this same idea but with copy past instance with the animation controllers, this allows for creating linked attributes and controls that allow the artist to select either object and get at the same curves.

    Anyway I would love to hear more of your thoughts on this as have been working at continuing to streamline and unRig the rigs, making them less overbuilt but still providing all the requested functionality..and I have found it , like any simplification task, extremely difficult.

    • October 24, 2010

      “I am not sure what system your working in but for the most part I think animators feel more “secure” knowing what has keys and where they are because they don’t have to be as careful about adjusting timing and poses etc.

      But, I also don’t think they want to have to worry that they forgot to keyframe something that needed to be in order for the rig to work. There are also issues with this and Auto-key and animator working preference.”

      This is crucial, security in knowing how the rig works will make the animator more confident in knowing how to use it. Worrying about forgetting to key an attribute is part I think of building an ‘explainable rig‘ to the animator – by this i mean, you build a rig that explains itself. For a system to work it has to be exposed to the user.

      E.g. Rather than automatically keying an internal ‘offset’ value, you instead expose the constraint itself and add functionality to key an existing transform. This way the user can see exactly what’s happening.

  2. October 24, 2010

    Well, this is a tough one.

    The problem is that animators come in all shapes and sizes. If you have 100 animators you’ll get 100 ways of doing similar things. (Nothing against animators, I used to be one. It’s just the nature of things, and there is nothing wrong with it)

    So, if you hide all the keys, some animators will hate it, others will love it. If you do it the other way around, the same will happen. Finding a happy medium is hard.

    Most of the animators I talk to say “Keep the rig simple, but give me absolute control” Well, that seems to contradict each other to me.

    At work we keep on talking about simplifying the rigs. (Because that’s what the animators want) And every day we add more and more controls and functionality. (Because that’s what the animators want)

    Anyway, back to the keys. I believe in not hiding them, but at the same time, most animators I know would rather not deal with what’s going on with the rig and just make it work, which means hiding them.

    Then again, I’m too far removed from Maya these days to have a good solution to the problem.


    • October 25, 2010

      Its less a case of hiding keys or not hiding them, but rather the animator knowing what a key means to a system – i think this is crucial. And also instilling a sence of commonality throughout the rig, we think in on and off, true false etc.. animators want values they can relate to especially in the graph editor which is essentially a graphical representation of interpolation.

  3. October 29, 2010

    I feel keys should not be hidden, but the innerworkings should. I’m trying to end up with 2 “layers”, one rig layer and one animation layer. The animation layer is completely exposed and transparant.
    In max CAT uses a similar approach (I’m not saying CAT is great) you have the setup layer where you could do a lot of rigging and the animation layers you can key blend etc. at will. I think this is very transparant. The layer you’re on is the keys you see in your trackbar or grapheditor etc. Now I also like as Brad said the motionbuilder way of thinking and that is in bodyparts and limbs. I’ve build a tool to mimic that behaviour with CAT and it works nicely, manipulating bodyports is a much faster and clearer way of approaching character animation imho, you always talk about the hand, the arm or the limb, not about leftUpperArm_twistbone_03.

    Regarding values I’d like to setup extra controllers and rigs that behave on a floating point base 0.0 -> 1.0, if all extra controls (not pos/rot) behave this way one could see all the curves together in a meaningful relation and the exchange of data is a lot more simple, exchange blinks data with a light flashing on and of (for example). Retargetting is also simpler, animation values can be processed with simple multipliers to copy facial animation from one rig to the other.

    Having said that I think you guys build more complex rigs then I do, so the validity and/or coherence of the above should be weighted by that 😉


  4. October 31, 2010

    Hey Johan,

    Nope your pretty much on the ball, our rigs are pretty complex – but its more down to the department and processes they go through. Lots and lots of interrelated systems, vo, dialog, cindes etc.. What i’ve learned is that you need clean understandable rigs, that are easy to extrapolate things from – animation, skinning info, bind pose, attributes etc. And data that is sharable.

    0-1 value are great to have – im thinking of space switching that way i.e like fkik. Having controllers for each space local, parent and world. And simple 0-1 blends for them.

    The hardest thing is understanding this relationship before going into production, you learn that on the job and try to remember it for the next project.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: