Rigging Experiment

[Mario Marengo]

Either way I guess the simple answers is there is no other simple way to get more control, quat slerping is as close as I can get to what I'd call simple.

14987[/snapback]

I'd have to agree... with the possible caveat that, as Edward mentioned, blending multiple quaternions may not be as successful as one may hope. But I'm not that familiar with them, so I'll let him elaborate on that.

Either way, at the end of the day, in some form or another, I think you're onto something that would be very useful here, so I'd vote for *some* kind of an implementation. And it's really great that you've made the effort (successful I might add) of prototyping the idea.

Cheers!

[TheDunadan]

I think the math terms* as they sound so vague and abstract are really good in making simple solutions sound terribly confusing and complex. In fact they aren't ... if you remember that provided that the mass stays constant:

acceleration is proportional to the forces acting on it, you only need to remember that if you integrate it over time you get the velocity .. and integrating the velocity again gives you the position.

In other words, those curves would work on the mesh points like a force field does on particles. Forces are cumulative so the curves would be like act buch of force fields. Since we have constraints etc. those forces (accelerations would need some adjustment). This requires likely some nasty math, but that's where SESI comes in

Jens

*it was a bit late when I wrote these lines: What I meant: math notation is pretty precise and useful, but as we're often not familiar very familiar with it, everything sounds so alien.

[edward]

Ok, first of all, let me warn you that I've been up for something like 17 hours now so I might not make sense and probably haven't absorbed everything said since I left. (btw, it was jason who had the hangover ). I apologize again for still not having looked closely at Simon's file yet and just going on the descriptions written here thus far. Mostly a rehash of everything said here though slightly differently.

Bones. They're dead simple. At each frame, we calculate the transform that goes from the rest bone to the deformed bone. Let's call this Ti which is the delta transform (ie. matrix) of bone i and its corresponding weight, wi. Then the final point is given by a linear combination of matrices:

p' = (w1*T1 + w2*T2 + w3*T3 + ... + wN*TN ) * p

So it's everything one expects from regular blending. Plenty of things wrong are immediately apparent. Uniqueness notwithstanding, it's also a linear combination of matrices. And I think usually the first thing they teach you in school about blending matrices is not to blend them that way.

So it comes down to the same point, we need something more complex. The question that then gets raised is how much are we willing to pay for in speed vs. quality? We need a balanced trade off here. Going to DOPs is not going to solve anything new here as that's just gonna go to a full simulation model and it seems that everything I've been hearing is that people want interactive feedback.

Here's a thought experiment for Simon. What if you just converted your resampled lines such that every line segment is a bone and then you capture everything using proximity?

And while we're at it, might as well think about example based approaches. I still think there's plenty of territory to explore in that area.

[sibarrick]

Bones. They're dead simple. At each frame, we calculate the transform that goes from the rest bone to the deformed bone. Let's call this Ti which is the delta transform (ie. matrix) of bone i and its corresponding weight, wi. Then the final point is given by a linear combination of matrices:

[edward]

I finally took a deeper look at the file and think I understand more now.

If we go with the curves idea, then perhaps one can just be generated by parenting PathCV objects as children of bones. Then wouldn't we get those curved blend regions for free as a result of the bezier generation? One can then control the "roundness" via scaling the PathCV objects. I'm not sure what other type of control you want for the blend region?

For the quaternions part, don't worry about it. I was thinking of a different way to address the same problem. Your solution is to try explicitly define how the blending at the joints look like. But are curves enough? In general, as points may be influenced by multiple bones, would you want a surface instead of a curve?

As for performance, I totally agree with you Simon. I just wanted to make the point that it can't be too slow esp. the diversion there about simulation methods.

[sibarrick]

The problem with using bezier curves is that the curves blend nicely but this doesn't tell you what to do with the point in the skin. The reason I was blending matrices in the first place was so that in the deformation sop I just look up the pre blended matrix Mn' and multiply the current P by it, I then do a weighted sum of all the points from the curves found in the search radius of the point cloud.

so the complete solution is

P' = (w1 * (P * M1' ) + w2 * (P * M2') + ..... + wN * (P * Mn'))/ (sum of w)

where Mn' is varying from point to point, each M represents the influence of a diiferent bone.

and n is the number of curve points with a radius specified at P.

But I only did it this way because of the limitations of using vex.

In a full implimentation you could store all the weights and matrices and not bother with the pre blending. But it seems to actually be quite a nice solution as it turns out.

I don't see the shoulder as being any more complex than 5 fingers branching from the palm. To deal with any number of bone inflences you just build them up in pairs. That way you still only deal with 2 at a time. Then for a point that is inflence by more than one curve it's just a weighted sum of all the curves, which themselves already take into account the bridging between bones. It's a combination of saying the curve blending represents where bones cause the skin to bend, and the proximity weighting is saying that more than one curve might influence a point.

Thus in the shoulder you would do something like -

clavicle to scapula = M1

scapula to humerus = M1'

sternum to rib1 = M2

rib1 to humerus = M2'

and so on

Mn is built like this

Mn = (bone1 M) slerp to (bone2 M)

Mn' = Mn slerp to (boneN M)

(not sure how you denote this as a formula, sorry, limited maths ability)

and then feed these in formula above

do you see?

I'll probably be rigging a full body this way just to prove it can work every where. I can't see why it won't though. Hands branch just about as much as anywhere else in the body....

[edward]

Sorry, I've been modifying the same post. Let me repost.

For the quaternions part, don't worry about it. I was thinking of a different way to address the same problem. Your solution is to try explicitly define how the blending at the joints look like. But are curves enough? In general, as points may be influenced by multiple bones, would you want a surface instead of a curve?

[edward]

Ok, now that I've read your msg. I guess the answer is yes then.

[edward]

er, yes to the question that curves are enough.

[sibarrick]

Just to end this discussion I thought I'd post up a few more pics. Maybe I post some more when I've rigged a whole character but in the meantime hear is the shoulder. Remember this is all done wiithout painting a single weight.

Thankyou to all who contributed it was very useful to get feedback and get to a formulised version.

this should animate, try clicking on it if it doesn't work

[edward]

Wow, that's pretty good!

[sibarrick]

Ok I've simplified everything, fixed the chop cooking bug ( I hope), repackaged all the otls, and added some callbacks to make life easier. I've also ripped out the old bone rig and put a new light weight one in so you can hopefully see the wood for the trees now. I've also discovered that there is very little need to override the radius of the capture at all, but I've left it in as an option on a per curve basis. I've also added a weight override so that the influence of each curve can be adjusted, although again in this example I didn't really need it.

On top of that I've added a bunch of other ops but they aren't included in this example. But I can tell you a little about them. The main one uses the jiggle chop to allow the curves to move around dynamically with the animation, which creates a very nice effect in areas that are supposed to be flabby. It's in the otl but there is another problem with chops not cooking which I can't think of a way round at the moment, and it causes the whole capture/deform process to fail, so needs more work yet.

I've also been playing around with an op that will let you model the curves manually to add deformation in a way similar to the current wire deformer. Of course the thing with this is in my setup this deformation gets calculated right in with the rest of them. nice.

Really the only major things to do now are to rig a whole character and add some help....

flex_hand.zip

Any and all comments are still very welcome.

P.S although the chops driving this now cook better, you still need to go to the sop level of the flex object before they will cook. Which is a real pain.....

[Jason]

Thanks Simon, this is getting easier to grasp now. Thanks for all the effort!

[sibarrick]

Thanks Simon, this is getting easier to grasp now. Thanks for all the effort!

15085[/snapback]

Here's the latest version with help.. flex_hand1.zip

[sibarrick]

One bug fix on the bypass toggle for flex_carve

Better wrist setup.

flex_hand3.zip

[sibarrick]

some more piccies, been messing around with the hip area working out the best way to rig it. These are the results so far. I've modified flex carve to add fillets which help a lot for maintaining volume even through very extreme deformations.

Flex.zip

[sibarrick]

few more bug fixes, chiefly in flex carve

Flex.zip

[TheDunadan]

All very nice, thanks for continueing to share those rigs with us In particular I like that it's much less messy then the way I used to rig those things, i.e. rigid binding + flexors / lattices and other deformers (with driven keys/expressions). Nothing worse then trying to figure out which deformer was responsible for weired behaviour in certain animations etc

Jens

[sibarrick]

I still hope to post a full rig soon, not just piccies. Which I also hope will be easily transferable to other models. And I'm still very confident that this method is extendable to doing nice muscle deformation on top off the basic rig. And since it has great similarities to wire deformers I can't see any reason that it can't do face animation too. The only down side at the moment is speed, but concidering it's all knocked together with Vops and Chops it's not that bad. Testiment to the power of Houdini, especially for prototyping ideas. So cool. Watch this space!

[edward]

In particular I like that it's much less messy then the way I used to rig those things, i.e. rigid binding + flexors / lattices and other deformers (with driven keys/expressions). Nothing worse then trying to figure out which deformer was responsible for weired behaviour in certain animations etc 

15121[/snapback]

That's a good point. I'll have to remember that next time I talk to a Maya rigger. Thanks.