This blog has been moved to cesarsaez.me, sorry for the trouble.

Nov 13, 2012

RigLab: overview

I'm finally working on my rigging framework, I've been thinking about it for a long time and I finally have a clear picture of what I want as end result... and even more important, why I want it that way!

There will be plenty of new problems to be sorted out as I go with the development, but the overall design and workflows are clear on my mind now.

So, why a framework?

I already programmed 3 autorigs for different productions, 2 of them on 3dsmax (for advertising projects and a TV series) and the latest one on softimage (for a feature film)... The "autorig philosophy" allow us to work faster and helps to standarize things, but at the end it's not enough.

If you limit yourself to make a rig-builder/autorig, at some point it will be obvious that you're leaving a lot behind, the solution tend to be specific to the nature of the asset (bipeds, quadrupeds and so on) and sometimes it's difficult to update/expand it without refactoring the system. So we end up creating new autorigs to cover unexpected requirements (props, vehicles, environments, facial rigs, whatever) rather than unify and keep them under the same roof.

A framework lives in a much more general level and represents that roof, describes the way you manage/work-with rigs. The autorigs (I call them solvers) are built on top, so you always have control over your rigs no matter how they were built (including by hand).

Goals

In order to get this done in a reasonable time frame I've to set some goals for the project, the following list represent the main ones (in arbitrary order).

Metadata:

The system will be based on metadata rather than any specific naming convention. The naming convention will be based on a config file in order to integrate the system on any pipeline (the same is true with colours, animation controls and all the standard rigging conventions).

Multipose support:

The framework should allow us to define a rigging pose (by default will be the same as the binding pose). This is important because the binding pose isn't always the best for rigging/animation purposes (nonorthogonal limbs and stuff like that).

Macro support for solvers' creation:

This is HUGE! When you're on production and there's a need for a new kind of rigging solution, code it and update the rigging system isn't the fastest solution (sometimes it's not even possible). Support a sort of macro to facilitate the solver's creation will help to keep the rigging system alive and updated.

Non-linear workflow:

The rigging process is an iterative one, the system should allow us go back to the creation state for editing/updating. A rig is never really finished and we need a bidirectional way to work with them.

Robust API (application programming interface):

From my point of view the system has 2 clients: the gui (graphic user interface) and another programs/tools, the system should be able to work with both (this include batch processing).

Current status


The overall design and the workflow are finished (I'm still documenting, but I have a clear picture of how everything should work). Right now I'm working on the metadata manager and starting the multipose part.

There're a lot of work to do in order to get it up and running, but this time I really want to materialize these ideas into something useful, I will be working actively in the coming months to complete the project as soon as possible.

Hope to have something interesting to show in the next post, we'll see ;-)
Cheers!



Categories:

7 comments:

  1. sera open source, para uso privado, a la venta?

    ReplyDelete
  2. Por ahora prefiero concentrarme en desarrollar una primera versión estable, el proyecto me hace bastante ilusión y creo que puede salir algo chulo de todo esto.

    One thing at a time :)

    ReplyDelete
  3. Muy bueno todo esto!! Vas a postear progress?? Muchos exitos con esta idea!!

    ReplyDelete
  4. sounds interesting. been working on a rigging system myself, so im curious as how you'll setup the metadata?
    also guessing it'll be in maya?

    ReplyDelete
  5. @chris:
    Espero que si, a medida que tenga algún avance significativo iré poniendo cosas en el blog.

    @Toke:
    Softimage, but I'm pretty sure that the concepts can be applied to any software (and I'll try to describe them that way in the blog).
    About metadata: I'll use dictionaries on the python side and save them using hidden attributes on the 3D side. The trick is to make a nice API such that you don't have to think too much about it as you work.

    Thanks guys!

    ReplyDelete
  6. cool, havent touched softimage so it'll be interesting to see your concepts.

    would be awesome to generalize the framework enough to easily port to other apps, via translation scripts or something. dunno if thats something you are thinking of as well?

    ReplyDelete
  7. The GUIs are pyQt and the base classes are software-independent, so seems quite possible expand it to another packages... but one thing at a time :)

    ReplyDelete