Time to move on

Hey folks,

Just wanted to say hello, been a long time without news here :(

Well... where to start... I came back to my hometown (Santiago, Chile) a month ago or so, my time living in Spain was AWESOME but the project is over and it's time to start moving again.

In the meantime, my father passed away a couple of weeks ago, I don't wanna talk too much about it here, but it's a hard news to swallow.

Anyway... I have to move on and start doing things again!
I have a lot of unfinished personal projects waiting for a spark of motivation and a demo reel to make in order to start a job hunting. 

Let me press the reset button and I'll get back to you with better news soon.

Cheers!

csRigLab Preview #001

Hi guys,

Today I wanna share an early preview of the rigging framework I've been working on, there's still a lot of work to do but I think the core concepts are there.

Let me know what you think about it :)
Cheers!


BTW, sorry for my english :(

Naming Convention

Hey folks,

I've been working on the naming convention side of the rigging framework and I wanna share my take on this problem.

I know, this isn't the hotest subject to talk about, but as it's a so general problem I thought could be interesting for you too.

First of all: a disclaimer...

A lot of things I'm developing for this project are influenced by the way I'm used to work. I'm not trying to steal ideas from anyone, it's inevitable carry with me some concepts that I found interesting and make them mine.

Thanks to all who shared their thoughts on pipeline/coding with me along the years. Lots of inspiration comes from those talks!

What's a naming convention?

As you may know, a naming convention is just an agreement about the information and the format we will be using to define a name.

So, what's the big deal?

Well, let me break things up a little bit...

On the user side it's just a convention and we are clever enough to remember it, so it's completely up to the user assign names properly. Some studios provide sophisticated tools to help them on the task, but in my experience a simple renamer tool (string operations) with some batch capabilities is enough in most cases.


On the code side it's a completely different story, code/software is not smart enough to figure out a naming convention so we have to be very explicit about it.

One way to tackle the problem is just hardcoding names, we all have been there at some point. It just works, but turns out to be a really bad idea in the long run.

The conventions usually evolve/change between projects/clients, if you hardcode things then all your tools become useless unless you revisit the code and change everything name related.


The other way is create a layer to solve the names using the conventions and work with those names on your code, this way you have a centralized place where set the new naming requirements and all your tools becomes name independent.

I obviously recommend the second approach.

What has been done in the framework?

If we go back to the project goals, there is a specific one about naming convention, let me quote it.

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).

At first I worked in a metadata API to store everything, but as the project progresses, I realized that access metadata is not user-friendly at all and it would be very difficult to trust the data if it's not updated by the user... and the system must assign a name to new objects anyway!

So in an unexpected turns of events, I still use metadata to store specific things but I also worked on a system that allows me use the data stored in the naming convention (which are much more likely to be updated by the user).

A cool thing about the new manager is that ended up being software agnostic, so it can be used in mixed pipelines too.

You can see how it works in the video below.

API Design

When it comes to naming convention is really dificult design an easy-to-use API, it's difficult because we have to specify every 'token' value but at the same time we shouldn't be typing any longer than the name itself.

In my experience if you're working with a too intricated API, the temptation to hardcode names tend to be too high (especially in scripting) and the whole system becomes meaningless.

Here are a couple of simple concepts that helped me to create an easy to use design.

• Manager

If you don't want to be too explicit you are probably looking for a way to share 'global' information, in my case I decided to work with a manager as a layer for the 'naming resolution' stuff instead of just at a module level, this way I can work with some 'global' values instead of specified them each time.

• Active Rule

The manager expect an active rule to work with, you can set/get the active rule at anytime. Using this way to deal with rules allow us be a lot less explicit on each name solving and let the manager do some clever stuff to figure out how to arrange the name using the incoming arguments.

• Override

We can override default values at a manager level at any time, this becomes really handy when you're working on the same context and don't want to be explicit about every token on every name.


I hope this make sense,
Cheers!

Old Stuff

Hey guys,

Today I was looking at some old stuff on my vimeo channel and there're some of them that I still like (and a lot that should be removed xD), so why not put them here?

After all: no shame, no pain!

WIP: csRigIcon

Hey folks,

First of all: happy new year to everyone! :)

This time I wanna share a preview of some rigging tools I'm working on. They're highly inspired by Softimage null's implementation but with some advantages that you can see in the video below (sorry for my english :P).

The csRigIconEditor GUI was a really nice exercise, it's a simple UI but as Softimage has no native PyQt implementation we have to handle the sincronization with the selection by ourselves. At the end was a lot of fun and I learned a couple of new tricks :)

I will be sharing this and all my tools with the first public version of the rigging framework, so they should be available soon.

Cheers!

Justin and the Knights of Valour - Official Teaser Trailer

Here it is... check out the first teaser trailer for the film in which I've been working on, has been a blast! :)

More at http://justinandtheknightsofvalour.com

csRigLab 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!

A closer look at: csDevManager

Hi folks,

I've been working on a manager for my developments, something like softimage's plugin manager but better suited for my workflow (python modules for the logic and pyQT for GUIs).

When I was working at Kandor Graphics we had some similar tools (much more robust and sophisticated, of course), was one of the first things they tackled and turned out to be an excellent decision on the long run.

So, lets see some features...

csDevManager has 2 modes, the basic one works like a launcher for all my custom commands, nothing too exciting here.

The developer mode is where it gets interesting, in this mode you can see all the Addons/Developments and their plugins (including properties, events and almost everything you can register on softimage).

Through the context menu you can access the reload function, this allow you reload all python modules used in the addon, recompile the QT stuff and reload the softimage's plugin in one click (big time saver).

You can also edit UI files (using QT Designer), explore directories, create new addons, plugins and remove existing ones.

Another nice addition is a new sdk wizard with updated templates, this makes really easy create new plugins.

And at last but not less, you have access to an API that allows you do "everything" related to your addons, every you see in the GUI is doable via API in a OOP way.




I've to do some clean up in order to make it completely generic, I'll make a github repository with all my tools and share them as open source ASAP.

Next step: work on my rigging framework using all I've learned in the past years :)


Cheers!

Thoughts on editing

Just a quick tip...

When you make a tool, don't think about it as a 1-time procedure, editing will take most of the time and you should provide support for it.

I see this a lot!
Almost every autorig out there do not offer any control over the setups already created and rebuild is the only provided solution (which is not realistic in many cases).

So, think about it and make your next tool much more useful!

Cheers

Convex Approximation

Back to the basics!

I've been thinking about how to use a convex approximation to improve "volume preservation" on enveloped meshes and I finally had time to do a proof of concept.

There's a lot to do in order to make it usable in a production environment but seems to work!




More to come...
Cheers!