Skip to content

Posts tagged ‘Rigs’

General/common approaches..

May 22, 2011

Charles

I do an general review of rigs and processes every few years. It’s by no means the be and end all of rigs – just what seems to be common and consistent throughout the industry.

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.

Who owns keys?

October 23, 2010

Charles

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.

Rigs: To update or use a new version?

June 18, 2009

Charles

I found a dilemma today involving updating rigs – firstly what’s the best approach to update one, and secondly when should a users just use a new version?¬†Should we just keep updating a rig with updates or at some point build a new version of the base rig with the said updates? I.e a new version. It’s a tricky problem for a development.

I guess the best paradigm for it is this – build a rig, and when changes happen apply them in a form of updates to users who are already using the rig. But in addition to the updates, update the original rig so that new users get the change instantly without being out of sync with the old ones.

Updating needs to be simple; simple enough for anyone to just drop an updated file in a folder and have the rig read it in.

As to any character pipeline backbone, the ability to update a rig without destroying the animation is crucial.

The problem of updating..

March 26, 2009

Charles

The issue of updating rigs is a complex one – you have multiple systems involved from the modeling, rigging, skinning and animation; even dynamics and muscle systems (though not so much to the latter in the games industry).

What are the soft constants in a rigging system? But that I mean systems that are susceptible to change and readily updatable? Well the skin, and model are updated pretty often until the rig works out, and deforms correctly; so I’d classify these as soft.

Now the hard constants would pretty much be the rig, its the framework that everything else lives off. But internally to the rig only the animation controls are integral to the animator and need to be constant. Else animation will get lost if controls are removed.

Now a framework can be classified as a soft skeleton riding hard controls, with soft model and skin riding the skeleton. Now we can see what’s easy to change!

The skeleton for starters could easily be changed if the animation controls are kept the same. And even if there are removed or new ones added all that’s lost is the animation on that control. Everything else that rides this is susceptible to change anyway.

So when building pipelines, take into account that the rigs are likely to change, only deal with the things that matter to people you pass the rig onto i.e the animators – all they want is the same controls or updated controls as before with the same animations.