Help Ways to reduce rope tunneling through meshes

[whack]

It seems that rope in particular, because of the way it bends and is subject to concentrated forces, is prone to tunneling through even non-moving mesh colliders. Even with surface collisions enabled, it seems to eventually find a thin place to clip through, and then the weight of the slack just pulls it through the rest of the mesh.

Are there ways to mitigate this?


I've tried:

- Increasing collision, distance and bend iterations (helps a bit, but at cost)
- Increasing substep count (helps a bit, but at cost)
- Increasing resolution (helps a bit)
- Surface collisions (doesn't help much)
- Increasing stretch compliance (helps, but not the behavior I'm looking for)
- Lowering gravity (helps a bit, probably because the slack is not pulling it down as much)
- Increasing collision margin and max depenetration and setting continuous collisions to 100% (doesn't help, probably because this isn't a problem of missed collisions)
- Making the mesh collider convex (doesn't help, seems Obi is just using the original mesh instead)


I've thought about maybe turning everything into a softbody with 0 softness, because then at least it would provide some volume for it to have to tunnel through, but that seems rather wasteful, and there's also a loss in accuracy with meshes of non-round object. (Would be really cool if we could manually place particles in softbody blueprints.)

Unless I'm misunderstanding something, what might be ideal is if, for example, something like skin constraints were available to other kinds of actors, or if the inner volumes of meshes could be "filled in" with composite convex hulls that can enforce depenetration better.

[josemendez]

[...] or if the inner volumes of meshes could be "filled in" with composite convex hulls that can enforce depenetration better.

That's roughly what distance fields do: have you tried them?:
http://obi.virtualmethodstudio.com/manua...ields.html

They're designed specifically with the case of robust complex concave/convex collliders in mind. Unlike MeshColliders, distance fields are "solid", meaning they do have a volume and any particles inside them will be projected outside.

As a bonus they're also much faster than MeshColliders since distances to their surface are precalculated. At runtime, collision detection reduces to just reading from an array: no BVH traversal, no triangle/point shortest distance calculations. As drawbacks, they don't support non-uniform scaling and concave regions can sometimes produce jitter.

Other than distance fields, the list of things you've tried is pretty much complete.

Keep in mind that mass ratios still have a great effect of convergence: large mass ratios are the bane of iterative solvers like Obi, so they should be avoided at all costs. Large mass ratios will require more substeps to converge, making the simulation costlier. As a rule of thumb, no very heavy objects hanging from a light rope. If the mass ratio between them is larger than 1:10, either make the object lighter or the rope heavier.

[whack]

That's roughly what distance fields do: have you tried them?:
http://obi.virtualmethodstudio.com/manua...ields.html

...

Keep in mind that mass ratios still have a great effect of convergence: large mass ratios are the bane of iterative solvers like Obi, so they should be avoided at all costs. Large mass ratios will require more substeps to converge, making the simulation costlier. As a rule of thumb, no very heavy objects hanging from a light rope. If the mass ratio between them is larger than 1:10, either make the object lighter or the rope heavier.

I could have sworn I'd read the entire docs, but I guess this is why you shouldn't read technical documents as a sleeping aid LOL

I think the combination of distance fields and adjusting the weights should do the trick. Thanks!