Skip to content

Posts tagged ‘Updating’

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.

Rigs: To update or use a new version?

June 18, 2009


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


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.