Help Rope Tunnels Through Even With Continuous Surface Collisions

[Rangasoup]

Version 6.5.4

I would like ropes to stay threaded through my objects. (While writing this I noticed the same happens for plain ropes themselves: https://youtu.be/wZ3jyZ1TicU)

It works okay for simple setups, but fails and phases through once more forces are applied.

I use non-convex SDF colliders, surface collisions, and fully continuous collision detection.

Here's an example using another rope, but the force can come from anything, and happens when the rope length is not changing too:



Solver settings:



Rope settings:



Any help appreciated,
Thanks

[josemendez]

Version 6.5.4

I would like ropes to stay threaded through my objects. (While writing this I noticed the same happens for plain ropes themselves: https://youtu.be/wZ3jyZ1TicU)

It works okay for simple setups, but fails and phases through once more forces are applied.

I use non-convex SDF colliders, surface collisions, and fully continuous collision detection.

Here's an example using another rope, but the force can come from anything, and happens when the rope length is not changing too:



Solver settings:



Rope settings:



Any help appreciated,
Thanks

Hi,

What's the mass of the rope, and the mass of the object?

Also, could you share your full solver constraint settings? You're using 8 distance constraint iterations at 160% relaxation, if your collision constraints - not visible in your screenshot - have less iterations you're basically telling the solver "the rope not stretching is a lot more important that the rope missing collisions, so it's fine if you ignore collisions as long as the rope doesn't stretch".

Typically your iterations should all be set to 1 and 100% relaxation, then crank up your updater's substeps for better simulation quality. Then fine-tune constraint iteration counts if there's a specific constraint type that you want to spend more resources on. The manual contains a very in-depth explanation of substeps/iterations and how they affect the results: http://obi.virtualmethodstudio.com/manua...gence.html

kind regards,

[Rangasoup]

Hi,

What's the mass of the rope, and the mass of the object?

Also, could you share your full solver constraint settings? You're using 8 distance constraint iterations at 160% relaxation, if your collision constraints - not visible in your screenshot - have less iterations you're basically telling the solver "the rope not stretching is a lot more important that the rope missing collisions, so it's fine if you ignore collisions as long as the rope doesn't stretch".

Typically your iterations should all be set to 1 and 100% relaxation, then crank up your updater's substeps for better simulation quality. Then fine-tune constraint iteration counts if there's a specific constraint type that you want to spend more resources on. The manual contains a very in-depth explanation of substeps/iterations and how they affect the results: http://obi.virtualmethodstudio.com/manua...gence.html

kind regards,

Thank you for the quick reply.

The rope has a mass of 2 (Are the units per particle? Does that mean resolution and width affect the rope's kg/m?) and the object 1440, but tested with lower mass ratios as well, brought it down to 6 with no fix.



I was using 6 substeps and all the other constraints were at 1 iteration. I bumped the collision constraints up to the same as the distance constraints and am using 100% relaxation now but it does not fix the problem.

I had tried trading iterations for substeps but 6 is about the limit before performance goes < 60fps. Tried up to 42 substeps with 1 iters anyway but it does not fix it either.

---

How is collision resolved for SDF colliders? When continuous collision creates that velocity-based bounding box, are nearest contact points predicted, or does it only add more colliders to check for the broad-phase? I am wondering if the particle goes deep enough into the SDF, and if collision pushes it out in direction of the gradient, then maybe it is being pushed out in the seemingly wrong direction because the particle is going past the local minima/center of the SDF in a single step?

Also, I imagine it's the case that Obi physics is aware of Unity physics, but not vice-versa. So, for example, if an object moves fast enough in a single step that it phases through a stationary taught rope, there is no way for Obi's continuous collision to detect that?

[josemendez]

The rope has a mass of 2 (Are the units per particle? Does that mean resolution and width affect the rope's kg/m?) and the object 1440, but tested with lower mass ratios as well, brought it down to 6 with no fix.

Yes, all units are per-particle. Changing resolution and width will affect density (mass per volume/length unit). The reason for this is that you're typically more interested in the mass ratio between a single particle and another object than the mass ratio of the entire rope vs another object.

On a side note, a mass ratio of 1:720 will break pretty much any physics engine (except for direct/reduced coordinates solvers). Always try to keep mass ratios below 1:10.

I was using 6 substeps and all the other constraints were at 1 iteration. I bumped the collision constraints up to the same as the distance constraints and am using 100% relaxation now but it does not fix the problem.

I just tried a similar setup and couldn't reproduce any issues with 12 substeps, 1 iteration and a 1:5 mass ratio. Would it be possible for you to send your setup to support(at)virtualmethodstudio.com so that I can take a closer look?

How is collision resolved for SDF colliders? When continuous collision creates that velocity-based bounding box, are nearest contact points predicted, or does it only add more colliders to check for the broad-phase?

Obi uses speculative contacts for CCD. It sweeps bounding boxes (of both particles and rigidbodies) by their velocity, and then generates a contact constraint between their closest points. Velocities and positions of both are then constrained so that the contact planes don't cross each other.

I am wondering if the particle goes deep enough into the SDF, and if collision pushes it out in direction of the gradient, then maybe it is being pushed out in the seemingly wrong direction because the particle is going past the local minima/center of the SDF in a single step?

Yes, this is how it works. However a particle can only get past/inside the SDF if all previous contact detect&solve attempts have failed or if another constraint has forced it inside the SDF after contact constraints have been solved, both situations are very rare.

SDF collision detection in Obi is based on the following article, FYI:
https://mmacklin.com/sdfcontact.pdf

Also, I imagine it's the case that Obi physics is aware of Unity physics, but not vice-versa. So, for example, if an object moves fast enough in a single step that it phases through a stationary taught rope, there is no way for Obi's continuous collision to detect that?

Nope, Obi predicts rigidbody position/orientation and uses this information during CCD checks. Rigidbodies shouldn't be able to go trough stationary ropes even if it's speed is large compared to rope thickness.

Note however that CCD isn't perfect. In particular, collision detection is performed only once per step (see: http://mmacklin.com/smallsteps.pdf). If a particle is pushed trough an object during a constraint solve, there's no way to prevent this (only solution would be to perform full collision detection/resolution after every single constraint iteration, which is of course impractical).

kind regards

[Rangasoup]

Yes, all units are per-particle. Changing resolution and width will affect density (mass per volume/length unit). The reason for this is that you're typically more interested in the mass ratio between a single particle and another object than the mass ratio of the entire rope vs another object.

On a side note, a mass ratio of 1:720 will break pretty much any physics engine (except for direct/reduced coordinates solvers). Always try to keep mass ratios below 1:10.


I just tried a similar setup and couldn't reproduce any issues with 12 substeps, 1 iteration and a 1:5 mass ratio. Would it be possible for you to send your setup to support(at)virtualmethodstudio.com so that I can take a closer look?



Obi uses speculative contacts for CCD. It sweeps bounding boxes (of both particles and rigidbodies) by their velocity, and then generates a contact constraint between their closest points. Velocities and positions of both are then constrained so that the contact planes don't cross each other.


Yes, this is how it works. However a particle can only get past/inside the SDF if all previous contact detect&solve attempts have failed or if another constraint has forced it inside the SDF after contact constraints have been solved, both situations are very rare.

SDF collision detection in Obi is based on the following article, FYI:
https://mmacklin.com/sdfcontact.pdf


Nope, Obi predicts rigidbody position/orientation and uses this information during CCD checks. Rigidbodies shouldn't be able to go trough stationary ropes even if it's speed is large compared to rope thickness.

Note however that CCD isn't perfect. In particular, collision detection is performed only once per step (see: http://mmacklin.com/smallsteps.pdf). If a particle is pushed trough an object during a constraint solve, there's no way to prevent this (only solution would be to perform full collision detection/resolution after every single constraint iteration, which is of course impractical).

kind regards

To give this thread some closure I had figured out what was going on. I had a spring that only affected forces one-way, and the damping factor was causing the rope collision resolution to be less effective. Making it two-way fixed the problems. I can now thread a rope through the box, grab it, and use it as a makeshift zipline like intended.

Crossing two ropes so they look like two interlocking V shapes and shortening them still causes tunnelling, but I imagine that's just a consequence of the lengths becoming lower than that configuration can handle. I can with live that though.

Thank you for your help