Whats the best way to do a simple collision of a rig with an object, e.g. putting a hand on a table and having the fingers collide properly.

I was putting together a quick attempt but couldn't get it to work:

Hi Michael,

there's going to be some trials with this, as you're more than likely going to hit a dependency problem: bones -> collider position -> IK -> bones…

Depending on the shot you were going for, you might be able to get away with parenting the colliders to the root of the hand instead, at a ‘rest position’… this would break that dependency loop. I only managed to grab a quick look at the file, but the other problems you're hitting have to do with trying to export a world space position from the collide_pts SOP, and putting that into the translates of the IK goals, which already have pre-transforms on them. Here the ‘transform object’ parm on the geometry CHOP won't help because you want to export to multiple objects, each with their own transform space… I've gotten around this in the past by enabling the ‘per point path’ attribute in the object merge (for the colliders) so you can grab the pretransforms in a wrangle and perform the adjustments per object at SOP level before importing with the Geometry CHOP.

Simpler things to fix are making sure that the Geometry CHOP is set to ‘animated’… this will bring in the point attibutes as separate channels rather than just 3 channels with 4 samples (as it is with yours… of course you could shuffle this too). Also be wary of the order of channels when they get exported. By default they will be: tx0 ty0 tz0 tx1 etc… the export will want to send them tx0 tx1 tx2.. ty0 ty1 etc. A reorder CHOP set to base name sort gets around that.

Hope that's of some help!

do you need “collision” for the bone targets or the geometry?
if you only need geometry on flat plane and do not go below…
maybe add a point wrangle with:


you can use something similar maybe for the bone target.
If you need it in chops maybe a math with a constant is better than a channel wrangle.
==========================
add:: sorry, did not seen friedasparagus explanation, which has much more
information than my post.

Attached is a chop solution with wrangle…
hope it's helpy
You'll need H16 to see the effect.
and a combined version: points do not go below 0, too.

Hi Henry,

Thanks for your reply. I had a go at your suggestions but I can't seem counteracting the pre-transforms, any chance you could take a quick look?

Hey matthias!

Yeah, nice elegant solution to the ground plane… I was going to take a look at this today if I got a bit of time, the chop constraints make this kind of thing much easier to approach! I reckon the kind of setup you've gone for could well be extended to taking in a different condition and adjustments from some SOP attributes (i.e. test if inside geo, and then adjust the constraint position by the normal of the collision surface, for example).

Oh! Hey Michael,

it's all kicking off here I'll try and grab a look later, basically you want to be getting the world space collision positions (as you've already done) and then multiply those positions by the inverse of the ik controls pre-transforms:

v@out_p = @P * invert(oppretransform(s@the_path_attribute))

The path attribute being created by the object merge

EDIT!! Bah, that's absolute rot! Sorry… The path attribute from the object merge won't work cause we're addressing a different object. You'd have to create another string attr pointing to the correct IK goal

not able to test this right now… but I *THINK* this is right! Give me a bit more coffee time and I'll smash that out…

Did you check out matthias' scene? Reckon there's mileage in attacking this along those lines.

Hi Michael,


added a second file… [sidefx.com]

which should show a poormans solution.
Advantage is, that you can animate the goal as usual.

Hi Matthias,

Thank you very much for the file, thats really interesting, I didn't even know about that constraints option! Cheers

OK, now that I've had a think and decided to stop being a plonker… the oppretransform stuff was completely unnecessary, really sorry for the blind alley All we need to extract is a difference between the intial collider position and the result of the ray…

Nice! Thats very cool and pretty simple! Thanks a lot

I guess the best option would be to combine both of your solutions so that you can still animate the goal objects, i'll look into it today!

Also check out this [www.sidefx.com], lots of collision stuff in 'ere

@friedasparagus
great link
Looks like my approach Wire fire [vimeo.com]
but much better, many thanks :-)

Another old technique: http://aboeinghoff.com/soft-contact-deformer/ [aboeinghoff.com]
(I think inspired by https://graphics.pixar.com/library/CartoonCollision/ [graphics.pixar.com] )