[Sidefx-houdini-list] Holding Bone Weights

ken ken at corefa.com
Tue Jun 12 22:36:38 EDT 2007


technically that is what the second input on the editSOP is supposed to 
do. It should be creating a local coordinate system on the deform and on 
the rest and then use a quaternion to move the geometry around. Thing is 
in practice the more the deformation changes the less likely the editSOP 
will be valid. I think of it like a noise field.. the noisier the field 
the less  likely you will get a wide range of use out of the blendshape. 
strictly speaking that's what we used for character finaling on the 
wild.  the problem is no matter what they do with the coordinate system 
it still gets a bit wonky in certain deformations over time. I was 
intrigued with the radial basis functionSOP Simon put out, but it can 
take a while before you get a strong relationship between the mapping 
points and the changes you want.

for rigging on the other hand this system should be able to give you a 
higher percentage of success when you use it for bone angles and the 
like. the reality is however, that any deformer after a deformSOP is 
slow, so you avoid it. Which means you can use the createeditsop hscript 
command to generate a preDeformSOP editSOP result so you can do use it 
in a blendSOP above the deform. Again, you can only get so many in 
before you start paying the price.. in memory and performance.

you idea would be helpful if it was done in the deformSOP. Anything else 
isn't as fast or nice once you start getting complicated.

we have implemented a nice rig system now with preBlendshapes, 
wiredeformer, then a deformSOP. when used correctly it is very nice to 
control the deformation and still give the animators the freedom. Thing 
is it can be slow. I know about the assume coordinate changes toggles 
(blend and deform), the morph mode in the blendSOP etc.  The blendSOP 
will cook only those inputs with values above 0, but you still pay the 
price for numbers here and you are bound to get multiple floats in there 
somewhere. the morph mode helps since only the deltas are stored in the 
editSOPs once the file has been saved after you toggle it on and reload 
the file, so the memory hit is less. The wire deformer isn't optimized 
with the assume coordinate changes so that isn't much help either.  the 
difference in attributes also can be a pain as well, but you deal with it.

I haven't played enough with the metaball system yet to know if it is 
potentially easier to get more out of the rig. I saw the videos Calin 
put out. It looked great, but I was worried about the workflow quirks 
you had to do to set it up.

-k



Louis Dunlevy wrote:

> I'd be curious to see what people think of this idea of a "relative" 
> deform for Houdini bones/metaballs. Any takers?
>
> Cheers
> Louis
>
> Louis Dunlevy wrote:
>
>> I was going to suggest the spreadsheet but you're there already I 
>> see. A bit messy though. I quite like the sliders on the bones too.
>>
>> For facial rigs have you had any joy with the Morph tool giving it a 
>> rest position? When you hit the "Save Deltas" button it will do an 
>> Attribute Orient style deform based on what you've done in your edit 
>> SOP. I'm sure you're already aware but just in case..
>>
>> I really would like to see a new type of bone behaviour like the 
>> "relative" mode in Maya's cluster deformer. That lets you throw in 
>> tons of extra deformers that have no affect whatsoever until their 
>> transform channels have changed. I find the problem with Houdini's 
>> bones is that they *always* have an effect on the geometry whether 
>> you like it or not. I think it's a big issue for facial rigs and 
>> secondary deformers.
>>
>>
>
>




More information about the Sidefx-houdini-list mailing list