wrapping up a limb into an object type

[meshsmooth]

I am making a rig with separate limbs as object types / assets the arms and legs will be just one limb with an option to set it to be left or right. This means if you need to fix the legs you have only need to edit one and the other will be updated.

Also after a set of limb rigs have been made. To rig a new character you only need to grab the limbs that will suite the purpose. For instance you can have a highly automated arm that is fantastic for almost every use. But you have a need for a low tech arm so you attach that. There could be hand rigs with different numbers of fingers. The benefits go on.

The problems I don

[michael]

a few of us have been working on things like this since OTLs were first introduced...but I think most of us have put it on the back burner because we have too much other stuff on the go (jobs etc)

one thing that I've thought alot about is building an OTL that is a 'setup' OTL...you use it to define the rig (#of bones, orientation etc etc) then you run a script that uses that setup as a template to build the real rig....lots of tricky things can be avoided that way....

the separate limb idea is obviously a good one - really the only one that makes any sense...

[Jason]

How practical is that, really? Actor; how are your (COREs) experiences with building rigs as assets? That is, f you can comment..

Which is better, many seperate assets for each type of rig, or one big rig asset?

Rigs are so complex that I'd imagine its impossible to plug sections together without seriously crippling the ultimate power of the rig by all corners you'd have to cut.

[thekenny]

build big or go home

there are a few people here who are thinking it would be feasible to manage a otl library or rigged elements to make a character. To be effective I think they would have to be very flexible to allow you to monkey with them. Their setup would be as complicated as an overall rig if you want to do everything right. Being able to reposition bones, weighting, helper bones. Scale issues for squashNstretch. That scares me. It might be feasible to have the pieces as subnets or scripts to set up the basic things faster.

we build rigging OTLs as tools to help standardize channel names and the interface (viewport-centric) nature of the rigs. In the start we ran into a lot of problems capturing and weighting bones in other levels (inside and outside of a otl). That maybe corrected now the the gang but it is way easyer IMHO to managea your rig as a giant otl promote what you want, standarizd the operator's parameter view and use OTLs as helper tools.

I could go on but... maybe later after it is done.

the OTL rigs handle most of the updates correctly and work as avertised. going back to rigging, requesting an update and reinstalling is very cool and helpful. The biggest thing is to ensure that your work is non-destructive, parameter changes, channel renames.... bad things happen.

-k

[michael]

I guess I can say this much...

our characters are OTLs

but they are not OTLs that are a combination of OTL segments (arm otl, leg otl etc)

the trouble, IIRC, with the segmented method comes with capturing the bones to geometry - I think you'll run into some really crazy path problems, not sure if this is still thatcase with the latest 6.5 builds....

I think if I had the time I would try to build an auto rig set up like this:

a series of 'setup' OTLs...arm_setup.otl, leg_setup.otl, spine_setup.otl etc

each of these would have controls to allow bone placement, capture region editing, # of digits, 'handedness' - left, right, etc

then a build OTL that would have a bunch of callbacks to build the final rig based on the contents of the 'setup' OTLs, add things like FK/IK blends, eye look-at's etc (this would all have to be based on a previosly built rig that had all the stuff I wanted in it, or on more than one rig (high-res complex, low-res simple etc), then package the whole thing up into a character OTL that could be published shop wide, version tracked etc

one thing that was a bit of a suprise to me was the # of promoted parameters that we would have at the end of the day...and how best to organize thiem...

but bottom line for me is that character OTLs are the way to go...there are still a few rough edges with OTLs in general but I'll never go back

silly kenny....we sit about 10 inches away from each other....and responded at the the same time....

[meshsmooth]

I seem to be having some success to the point i am currently at. Maybe later i will run into other show stopper problems.

Another approach could be to wrap up the end goals, upvectors and controllers into object types and keep the bones on the next editable level referring to the kinematic solvers in the object type.

Even if it works to a degree and has its failings it will appeal to people who don

[old school]

I believe in Kenny's approach now: character builder asset that results in a character asset that contains nicely organized subnets for the different major character components that themselves contain smaller manegable assets. Houdini6.5's character tools now properly support bones burried deep inside assets. Proof is in the latest rigs Ken. Talk to Emanuel.

As for the nice rig set-ups for maya and XSI, the first thing a studio does when rigging their characters is build their own tools. I also think that Maya really has no higher level rig tools but there are many example rigs and mel scripts out there. That is what we need for Houdini as rigging is more literal in Houdini. Not as many head-scratch nested ik solutions to solve controller positions that then drive IK. In Houdini for most cases, you just use CHOPs to manage the solvers, one or two blend objects and you are there.

Now completely outside of CORE, I have built a few rigs with Zubin and Luca's help. The first rig had assets for each major component of the rig. The second version of the rig tools are now a lot more granular and is a work in progress. Hopefully in place soon.

First Rig version using assets for major components:

spine asset

arm asset

hand asset

leg asset

head asset

eye asset

etc...

plus a whole host of small rig tool assets such as sliders, controllers, proxy geo generator, etc...

Each asset had two or more inputs. The first input was the parent root for the actual bones. The second, third and subsequent inputs were the different spaces options for the controlers. This worked very well.

We eventually had all the internal assets unlocked inside the character wrapper asset and had to keep it that way. The assets ultimately became a delivery mechanism to enforce name conventions and simplify the rigging set-up.

Zubin added auto-setup scripts for some of the assets as a proof of concept and that works very nicely.

Pros:

- really clean network. Exceptionally clean.

- Easy to see and manage the controller spaces. No spaghetti network wires criss-crossing all over with willy nilly blend objects

- far fewer blend objects than in a chaotic free-form character approach.

- quick set-up

- concrete naming convention enforced by brute-force asset locking

- all the limbs, head and tail hung off the spine otl very nicely. Used a fetch objects for the shoulders and hips. Head came off the parent output of the spine.

- Dialogs for all the assets were split in to two main folders: Controls, Rigging. The Controls part of the dialog script would simply be cut-pasted in to the top level asset in a folder. All scripted and slick. The Rigging parms would be for set-up.

Cons:

- Generalized arm and leg assets had to be unlocked and kept that way to handle left and right side differences. The asset could have been generalized but that would have meant promoting 100's of parms to support all the new parms for the new world-space pose parms and cregion options.

Since the assets were unlocked, it became very difficult to manage any changes. Parm changes on the left-side Leg asset would go to the right side Leg asset while network changes wouldn't. Heaven help you if you match current definition in this kind of a scenario. Not for the feint of heart.

- set-up sripts were embedded in the assets were an unavoidable overhead for the character.

- Too close-box for any exiting character pipelines in other facilities. Names were locked in the assets. They would have to build their own.

- arm - wrist asset link was a bit tricky to rig properly. If anyone thinks that this is easy, they are FOS. The hand and IK controllers need to sync spaces when switching between FK-IK which makes the wrist rotate and the forearm bone twisting a bit tricky. I have a couple sloutions now.

Issues Encountered:

- Ran in to recursion issues when I placed many expressions in the spine asset. Had to move expressions in to SOPs below.

Warning: Do NOT write expressions in to the asset's parameter interface. Evaluation of this parameter alone will force everything to cook in your asset. Not that big a problem in H6.2 but a real issue in H6.5.

- Parm promotion through two levels of assets became cumbersome. Change a channel name in the spine asset and it would impact two levels of assets if you wanted to maintain the name convention to the top. Other issues as well.

A great learning experience but a dead-end approach in the end. Now abandoned but extracting the bits for the smaller assets.

I should talk to Zubin, Rmagee and SESI to see if we can release the monkey-man in his final optimized state with no recursion and much lighter than earlier versions given that he is a dead-end solution. I don't want people to emulate this style of rigging given the above short-comings. It has a tremendous amount of real cool asset techniques in it though. Lots of real subtle stuff that you don't notice until you really study it.

The second Rig with smaller assets:

To avoid the massive parm promotion problem, we decided that any assets that were to have any handedness (left-right) were not to be locked off assets at all. They would be simple subnets that contain much smaller assets if at all. For example in the leg, there would be a simple rig for the controller on the leg but the bones and other tools would be freely placed in the subnet. The subnet would be generated by a script run in a set-up envorionment rig.

The work would then go in to the set-up rig that itself would be an asset that built all the proper bits and pieces then would still be around if you needed to re-create the rig. I don't know how far I can take this as a single change in the generated rig could kill the association and there is a 100% chance of that happening.

There goes the bone name convention enforcement.

Working on this right now with some others in the Toronto office.

As far as building the various bits like the arms, various legs, 3 or 4 versions of the spine (how many can there be?), that is no longer the issue. Have good solutions for all the bits in place now. It is the building of the rig that now is the front-end work. Our spine rig tools are pretty good now. Our rigs don't budge a bit when you tumble the crap out of them. No flipping, flopping or quivering any more. Thank Ed and the char team at SESI for that.

Rig development seems to be never ending though...

-jeff

[thekenny]

Thanks.

I know things have improved very much in the last year since I did the first rig:)

The guys in rigging are doing great things.

I just know that from what I've seen it is easier to keep things clean and simple but yet highly editable so updates are done smoothly. I'm not sure but if they, or anyone else uses channel aliases, you could even potentially save destructive changes.

It gets tricky when you have more people to support and a large numbe of characters to build and rig. With that kind of volume you need to be fast and flexible.

-k

[edward]

i like the auto-rig approach but more generalized.

[Wolfwood]

i like the auto-rig approach but more generalized.

So far I've agreed with you on the 1st and 3rd accounts. But not on the second.

[meshsmooth]

well that is certenly plenty to think about

[Jason]

Thanks for all the great information there, Jeff. I'm going to read it a couple of times, make some sums, have a bath and then try to formulate a sensible reply.

[Jason]

Acutally, some of this seems good news for Alex Lim, since he developed part of a very cool auto-rigger. He'd be happy to know that his work could be re-tasked to generate rig components in asset form on the fly. Alex, how 'bout it?

[Wolfwood]

Thanks for all the great information there, Jeff. I'm going to read it a couple of times, make some sums, have a bath and then try to formulate a sensible reply.

I like bean dip.

[Jason]

Thanks for all the great information there, Jeff. I'm going to read it a couple of times, make some sums, have a bath and then try to formulate a sensible reply.

I like bean dip.

No, Wolfwood. I was talking about ME.

[meshsmooth]

The trouble is that the rig side of things that controls skeletal animation, is simple in that it is relatively consistent between different characters

[edward]

For using simple vs complex rigs, OTLs are definitely the way to go. No need for CHOPs to transfer animation. That we know the right solution for.