[SOLVED]Prevent Mesh Twisting In Rigs?

[Atom]

Hi All,

How does one prevent mesh twisting in a rig? If you notice in the GIF the bones are rotating as I want, but the mesh deforms badly. Do I have to link something to the mesh Capture system to prevent this kind of distortion? The Deform Regions values are exactly the same as the Capture Region values.

Edited September 14, 2016 by Atom

[celd]

what I would do in my Maya rigging days was to add additional joints along the forearm and rig them, so they would rotate along with the wrist, multiplied by a value lower than 1. mesh would then be skinned onto them and they would interpolate it smoothly

perhaps same solution could be used, unless there is a more "Houdini" way to do it

[Atom]

The rig is pretty much a deliverable and I will be processing a lot of these so I don't want to get into modify each and every rig by adding more bones. If I get a new deliverable then I would have to re-do that work.

I am looking for a Houdini based solution, I don't have Maya.

Edited September 14, 2016 by Atom

[celd]

Nor am I suggesting you use Maya, having said that, I have not tried rigging in Houdini, but I assume the process would be similar and even easier to automate.

From what I can see, the rig is doing what its supposed to, but the deformation is simply too extreme. if you looked at your own arm doing that kind of a motion, it would be twisting almost all the way to the elbow, anything short of that will simply not look good with this kind of polygon density.

Edited September 14, 2016 by celd

[Atom]

This is a Motion Builder style rig I imported from a FBX. The bone I am rotating in the first image is called RightForeArmRoll, I think it was put into the rig just for this purpose. The RightForeArm starts at the elbow. If  rotate from there I just transfer the mesh twist to the elbow region.

 Which means to me that the mesh can deform correctly at the wrist.

[Guest tar]

2 hours ago, Atom said:

How does one prevent mesh twisting in a rig? 

Would be interested to see how Delta Mush deals with this.

[MrScienceOfficer]

Like Celd was saying, in order for your rig to work you need expressions.  Expressions will not be imported or exported over FBX, each package is different.   

From the look of it, RightForeArmRoll should have an expression on it that takes twist motion(rz) from RightForeArm and multiplies by like 2.5 or something.

 

Maybe you can get away with using DeltaMush, as Marty suggested, I would love to see how it handles it, but the answer to the question "Preventing Mesh Twisting in a Rig" (also known as "candy wrapper effect") is multiple joints driven by expressions, or a using a muscle system.

[Atom]

Thanks for the DeltaMush tip!

That does help reduce the extreme bending. It is no longer an extreme yuk, just a lack luster deflate. It does kind shrink in the mesh a bit. But the benefits from adding just one node are good.

My rig is driven from custom control parameters (in the GIF I am just rotating the controller instead of using the slider) so I have played around with splitting the difference between the rotation amounts using code. Now that DeltaMush is in place I may revisit that approach.

    slider_value = `ch("ctl_forearm_R_roll")`
    if slider_value < 0:
        tmp_mult = 90
    else:
        tmp_mult = 135
    influenceControlValue("RightForeArmRoll","ry",slider_value,tmp_mult,lst_bone_influences)
    influenceControlValue("RightForeArm","ry",slider_value,tmp_mult*0.5,lst_bone_influences)

 

With DeltaMush in place at default values.

 

With DeltaMush nearly maxed out Iterations 85, Step Size 0.986 it seems to fix the basic problem. (no expressions yet)

Edited September 14, 2016 by Atom

[michael]

just saw this thread now...

yes - the is called 'candy wrapper' and it's one of the basic issues you will always face in rigging.

the RightForeArm and RightForeArmRoll are intended to share the rotations between them - effectively cutting the amount of rotation for each bone in half and thereby reducing the distance between each point and the bone it is captured to.

if you can, upload your file and I'll have a sweep through it and weight it the way I normally would, and I can add some notes etc.

our docs and tutorials will be getting a much needed update in the near future so this kind of thing wont be such a mystery

[Atom]

I have attached the FBX that is shown in the images.

real_magic_male_1a.zip

[AaronAb]

1 hour ago, michael said:

just saw this thread now...

yes - the is called 'candy wrapper' and it's one of the basic issues you will always face in rigging.

the RightForeArm and RightForeArmRoll are intended to share the rotations between them - effectively cutting the amount of rotation for each bone in half and thereby reducing the distance between each point and the bone it is captured to.

if you can, upload your file and I'll have a sweep through it and weight it the way I normally would, and I can add some notes etc.

our docs and tutorials will be getting a much needed update in the near future so this kind of thing wont be such a mystery

Just curious if you have seen this old paper: http://research.cs.wisc.edu/graphics/Gallery/SkinFromExamples/skin-from-examples.pdf

It addresses the candy wrapper effect quite elegantly. I've used a tool based on this algorithm in the past, and it works quite well. Would love to have something like this in Houdini.

[edward]

Try changing the Deform SOP to use the dual quaternion method to see if that helps.

[michael]

yep - dual quaternion will help right away.

here is a few minutes of goofing around - I added a ctrl null to the left wrist - the LeftForeArmRoll will get (ch("../L_Hand_CTRL/ry") - 0.805894) / 2 for it's Y rotation, and painted the weights a little bit, turned on dual quaternion - the wrist can now rotate from -90 -> 90 without any candy wrapping or weirdness.

real_magic_male_1a.fbx.hip.zip

[Atom]

Thank you for taking the time to review and update the FBX file. It is nice to see how it should be done. I feel like my RIG looks and deforms a lot better with all these tips than when I made the first post for help.

 

 

[michael]

glad to help.

as I said above, we'll be doing much more work on our docs and tutorials in Character in the near future.