A Few Obi Collider Issues

[Skotty]

I was experimenting with a rope tethered on one end, with a loose rigidbody attached on the other end.  Then I had a mesh with a big hole in it that I added an Obi Collider to.  I pushed the rigidbody through the hole and it fell through pretty normally.  But then if I start moving the rigidbody it can start to cut through the mesh collider of the model with the hole.

This can seemingly be fixed by adding an Obi Rigidbody to the rigidbody (had to tinker with collision categories so rope wouldn't freak out due to having the end embedded in the rigidbody object, putting them on different categories), and then also setting the attachments dynamic.  I assume that is the correct procedure.

I'm still having issues with initialization though.  Even though the entire rope is suspended above the mesh with the collider before starting, after going into play mode sometimes part of the rope is stuck inside or beneath the mesh with the hole in it.  How to I avoid this reliably?

   

Thanks for any tips,

EDIT:  I added a couple of screenshots for reference.  Put them together in one image as I was having trouble getting it to accept attachments.  One is the layout as it looks in the editor.  The other is in play.  The rope has moved a bunch from it's starting position and part of it has embedded in the mesh beneath it.

- Skotty

[josemendez]

I was experimenting with a rope tethered on one end, with a loose rigidbody attached on the other end.  Then I had a mesh with a big hole in it that I added an Obi Collider to.  I pushed the rigidbody through the hole and it fell through pretty normally.  But then if I start moving the rigidbody it can start to cut through the mesh collider of the model with the hole.

Hi!

This is called tunneling, and happens in all physics engines  (not just Obi) as it's a consequence of how computers treat time as a discrete quantity.

What's happening is that when you set the position of a collider, you're essentially teleporting it to a new position instantly. So one frame, the rope is outside the collider. Next frame, it is inside the collider, without ever having "touched" its surface. If your collider is hollow (doesn't define a solid volume) like a concave MeshCollider, the rope (or other objects) will stay inside it.

The solution is to either use primitive colliders (boxes, spheres, capsules) or signed distance fields, as these are both solid and can perform depenetration (taking objects out of them once they're already inside.)

This can seemingly be fixed by adding an Obi Rigidbody to the rigidbody (had to tinker with collision categories so rope wouldn't freak out due to having the end embedded in the rigidbody object, putting them on different categories), and then also setting the attachments dynamic.  I assume that is the correct procedure.

Rigidbodies have velocity. This is a vector that tells the engine where the object is going to move *next*, so it allows the solver to perform what is called CCD (continuous collision detection): it checks the entire range of motion from one frame to the next for collisions, which helps reduce tunneling a great deal. For this reason, the correct way to manipulate objects involved in a simulation is to modify their velocity (by applying forces, impulses, or acceleration) instead of their position.

I'm still having issues with initialization though.  Even though the entire rope is suspended above the mesh with the collider before starting, after going into play mode sometimes part of the rope is stuck inside or beneath the mesh with the hole in it.  How to I avoid this reliably?

Depends on what your collider type is. If it's a MeshCollider, there's not a fail proof way to prevent this since MeshColliders are paper-thin by definition (only their surface generates collisions). Using primitive colliders instead (eg boxes with some thickness to them) is the usual approach.


Note that all we've discussed so far applies to any physics engine (including Unity's own rigidbody physics).

let me know if you need further help, kind regards

[Skotty]

Hi!

This is called tunneling, and happens in all physics engines  (not just Obi) as it's a consequence of how computers treat time as a discrete quantity.

What's happening is that when you set the position of a collider, you're essentially teleporting it to a new position instantly. So one frame, the rope is outside the collider. Next frame, it is inside the collider, without ever having "touched" its surface. If your collider is hollow (doesn't define a solid volume) like a concave MeshCollider, the rope (or other objects) will stay inside it.

The solution is to either use primitive colliders (boxes, spheres, capsules) or signed distance fields, as these are both solid and can perform depenetration  (taking objects out of them once they're already inside.)


Rigidbodies have velocity. This is a vector that tells the engine where the object is going to move *next*, so it allows the solver to perform what is called CCD (continuous collision detection): it checks the entire range of motion from one frame to the next for collisions, which helps reduce tunneling a great deal. For this reason, the correct way to manipulate objects involved in a simulation is to modify their velocity (by applying forces, impulses, or acceleration) instead of their position.



Depends on what your collider type is. If it's a MeshCollider, there's not a fail proof way to prevent this since MeshColliders are paper-thin by definition (only their surface generates collisions). Using primitive colliders instead (eg boxes with some thickness to them) is the usual approach.


Note that all we've discussed so far applies to any physics engine (including Unity's own rigidbody physics).

let me know if you need further help, kind regards

Thank you for the tips.  

Just to clarify, the red plug in the screenshot is a regular rigidbody; I wasn't moving it by changing it's position, but rather by pushing it with another kinematic rigidbody (part of game mechanic).

I think my next step should be to try box colliders.  Because that particular mesh has a hole it in, I initially had given it a mesh collider.  But it's still a mostly squarish shape, so I can pretty easily substitute the mesh collider with a compound collider using several box colliders.  Based on your reply, that should help.

However, I really feel like part of the problem has to do with initialization of the scene.  Sometimes the rope falls gracefully in play in the shape I made for it in the editor, but other times it kind of reacts a bit violently on scene load.  Do you have any tips for that?  This is not a simple test scene, but rather a full game scene that has a lot of other stuff going on.  Overall FPS stabilizes at well over 200 FPS on my system but it does seem like the first couple of frames can be slower.  Fixed timestep is the default 50.  I feel like the complexity of the scene with a couple of potentially slow frames on first load could be a factor.  If so, I need to mitigate it somehow.

I need larger sample sizes, but it seems like 9 times out of 10, the rope falls gently on scene start, but that 1 time out of 10 it kind of shoots off in some odd direction, and that is when the rope does things like getting stuck in/under the mesh.  I remember seeing something in the docs about burst synchronous compilation. Thought maybe that could be something, but on or off, problem exists either way.  I haven't done any testing in a full build yet, only running from in the editor.

[Skotty]

Additional diagnostic info.  I tried removing the attachments to the rigidbody and then no more violent start ups in my testing so far.  I then reattached it with just one control point, and also for the run test I physically separated the plug from the rope just to eliminate another variable and remove any collision there.  I also switched the panel beneath to use a box collider.  And the strange behavior resumed.  It usually gets the very end of the rope stuck.  

The plug is hovering just slightly above the panel.  I sometimes do that to avoid collision on startup, letting rigidbodies drop a fraction of an inch from gravity and land on the surface beneath them.  So that is suspect.  If the rope is trying to follow a dropping rigidbody, maybe that's why the end is often getting stuck.  I suspect collision issues also cause the violent reaction.

Will try to attach more config screenshots here.  3 are in editor showing configuration of the rope, plug, and the attachment 1.  The other is in play after I had physically moved the plug away from the rope but still attached.  When this happens the rope often shoots sideways like it was fired from a cannon.

EDIT:  To see if the plug falling was an issue, I set it Kinematic on the Unity Rigidbody so it wouldn't move.  However, the rope still darts around violently on start.  Which is odd.  Because if I remove the attachment, it seems to behave.  Though I only did like 10-15 play starts with the attachments removed, and I suppose maybe that's not a big sample size to be sure.  I was actually surprised setting the plug Kinematic didn't work.  The rigidbody motion isn't causing the problem.

2nd EDIT:  I removed the static attachments on the other end and turned off self collisions, but behavior still not fixed, so it's neither of those.

[Skotty]

I might be on to something now.

I ran a bunch more tests with only 1 attachment on the rope, a single attachment to the rigidbody plug.  I still had it set with isKinematic = true.  It frequently reacted violently when set dynamic, but had no issues when set static.  However, in playing with other options, I changed the ObiParticleAttachment Compliance from the default of 0 to 1, and the violent start up appears to have stopped.

So now I'm focusing more on compliance, which I'm not really super knowledgable about yet.  There is a compliance value under Distance Constraints as well, and it's values are Stretching scale 1, Stretch compliance 0.  Those are also I believe default values.  The ObiParticleAttachment Compliance default was also 0.  

Honestly, I'm not seeing much in the documentation on compliance setting.  I had to go over to the API docs, where I found a single helpful sentence for the ObiParticleAttachment that said this: "High compliance values will increase the attachment's elasticity."  I don't know if the Distance Constraint is similar or not.  But I think I might have finally isolated the problem child.

I don't yet see any information on what the sensible range is for ObiParticleAttachment Compliance.  But does it make sense that a value of 0 could be causing the problem for a Dynamic attachment?

EDIT:  A few observations.  By setting a non-zero compliance on the ObiParticleAttachment, the plug can now separate from the rope (it then tries to bounce back in a springy sort of way), and it is harder to move it by pushing it with another rigidbody.  I adjusted compliance all the way down to 0.01 and it still seems to be behaving, though still has some separation.  It seems like maybe the compliance value is distance?  If not, seems like it correlates.  To help address it being harder to push I reduced the obi material frictions, which helps.  Still trying to figure out what ideal values are and if adjusting these values will fully fix the problem.

EDIT2:  I put compliance all the way down to 0.005 which keeps it looking attached and turned self collision back on.  Then rope started acting violent and getting stuck again occasionally.  I wonder if I can dynamically change the compliance?  Maybe I can set it loose for the first few frames, like a value of 0.02 or a little higher, then reduce it down to 0.005 after things have settled.

[josemendez]

I might be on to something now.

I ran a bunch more tests with only 1 attachment on the rope, a single attachment to the rigidbody plug.  I still had it set with isKinematic = true.  It frequently reacted violently when set dynamic, but had no issues when set static.  However, in playing with other options, I changed the ObiParticleAttachment Compliance from the default of 0 to 1, and the violent start up appears to have stopped.

So now I'm focusing more on compliance, which I'm not really super knowledgable about yet.  There is a compliance value under Distance Constraints as well, and it's values are Stretching scale 1, Stretch compliance 0.  Those are also I believe default values.  The ObiParticleAttachment Compliance default was also 0.  

Honestly, I'm not seeing much in the documentation on compliance setting.  I had to go over to the API docs, where I found a single helpful sentence for the ObiParticleAttachment that said this: "High compliance values will increase the attachment's elasticity."  I don't know if the Distance Constraint is similar or not.  But I think I might have finally isolated the problem child.

Compliance is a basic physics concept: the inverse of stiffness, that is, how "soft" something is. The accurate definition is strain/stress: how much an object deforms per stress force unit. It works the exact same way for all constraints with a compliance setting. In the "how it works" page you can find this definition:

Obi also allows to specify a maximum desired stiffness, by assigning a compliance value to each constraint. Compliance is the inverse of stiffness, so zero compliance means "as stiff as possible given the current timestep duration". A compliant constraint is soft, a non-compliant constraint is stiff.

I don't yet see any information on what the sensible range is for ObiParticleAttachment Compliance. But does it make sense that a value of 0 could be causing the problem for a Dynamic attachment?

Compliance ranges from 0 (as stiff as possible) to infinite (completely loose). It's expressed in m/N (meters per Newton, remember that compliance = strain/stress,  strain is a deformation so its units are meters and stress is a force and its units are Newtons).

Why do we use compliance instead of the perhaps more intuitive "stiffness"? Because the common case of wanting something to be as stiff as possible requires setting stiffness to "infinite", this is awkward both for the user and the computer. Using 0 to mean "don't you dare move" and higher values for higher elasticity is a lot simpler.

EDIT:  A few observations.  By setting a non-zero compliance on the ObiParticleAttachment, the plug can now separate from the rope (it then tries to bounce back in a springy sort of way), and it is harder to move it by pushing it with another rigidbody. 

That's exactly what compliance is supposed to do: make the attachment softer/springier.

I adjusted compliance all the way down to 0.01 and it still seems to be behaving, though still has some separation.  It seems like maybe the compliance value is distance?  If not, seems like it correlates.  

It's distance per force unit, as explained above.

To help address it being harder to push I reduced the obi material frictions, which helps.  Still trying to figure out what ideal values are and if adjusting these values will fully fix the problem.

EDIT2:  I put compliance all the way down to 0.005 which keeps it looking attached and turned self collision back on.  Then rope started acting violent and getting stuck again occasionally.  I wonder if I can dynamically change the compliance?  Maybe I can set it loose for the first few frames, like a value of 0.02 or a little higher, then reduce it down to 0.005 after things have settled.

Maybe your rope is attached inside/overlapping the collider? This creates a physically unsolvable situation: collisions try to get the rope outside the collider, while the attachment wants it to be inside/intersecting the colliders. An object cannot be simultaneously inside and outside someplace, so as a result the rope will wriggle and jitter trying to escape the collider in vain. This situation - along with the solution - is described in the attachment's manual page, see "attachments inside colliders".

It would make sense for non-zero compliance to help in this case: making the attachment softer allows collisions to "win", ceasing the struggle. The proper solution is to use collision filters to exclude the particles near the attachment to collide against the collider, as described in the manual. All included sample scenes use this approach to attach ropes very near to/overlapping colliders. By doing this you can use any compliance value, including zero.

kind regards

[Skotty]

Maybe your rope is attached inside/overlapping the collider? This creates a physically unsolvable situation: collisions try to get the rope outside the collider, while the attachment wants it to be inside/intersecting the colliders. An object cannot be simultaneously inside and outside someplace, so as a result the rope will wriggle and jitter trying to escape the collider in vain. This situation - along with the solution - is described in the attachment's manual page, see "attachments inside colliders".

It would make sense for non-zero compliance to help in this case: making the attachment softer allows collisions to "win", ceasing the struggle. The proper solution is to use collision filters to exclude the particles near the attachment to collide against the collider, as described in the manual. All included sample scenes use this approach to attach ropes very near to/overlapping colliders. By doing this you can use any compliance value, including zero.

kind regards

I don't think it's an intersecting colliders issue.  If you check all my screen shots, I did two different things to explore this possibility.  In an earlier post and screenshot, you can see that one test I did was to completely separate the plug from the rope by a pretty sizable distance (as seen in screenshot) but still attached.  You can also see in a later post with screenshots how I have the rope and plug configured, where I put the rope and plug on different collision categories and set the "collides with" to not include the other.

My best guess right now is the problem might be related to a slow first frame or two, where the first frame or two might fall below the fixed update rate presumably causing multiple fixed update calls per frame just on the first 1 or 2 frames.  Maybe that's having a negative effect on Obi dynamic attachment startup.  I'm going to explore this more deeply to see what in my architecture is causing the slow first frame and see if I can eliminate it either permanently or temporarily to test if it affects the ObiRope behavior I'm seeing.  I've never really dived deep into it before because it's mostly transparent to the player so until now it was a low priority performance concern.

EDIT:  I've got some profiling going on now.  If I look at loading into the game, for an example test pass, the first frame (frame #7313) took 2696 ms.  I don't think that one counts though, because that is where it is loading state from disk, running the Awake and Start methods, etc.  However, the very next frame (frame #7314) took 214 ms.  Subsequent frames never got above 33 ms.  The typical average frame time is more like 4 ms. I specifically tracked some of my main framework classes, and they consumed about 16 ms on frame #7314.  I still need to look deeper to see what's using the other ~200 ms.  But point being, it probably ran fixed update several times in row on that frame I'm guessing, and I still suspect that contributes to the problem.

EDIT2:  Checked out the Unity Profile specifically (the other profiling was with my own tools).  Used a test case where the rope reacted violently on load.  I don't know.  Everything looks pretty normal to me.  There's a slow loading frame.  Seems normal. It's loading.  Next frame is 45 ms, but 15 ms is EditorLoop, and a big chunk of the rest was actually the ObiSolver at about 20 ms.  After that all frames were under 15 ms (usually just 4).  Attached profiler image for 2 frames, plus a freeze frame of the rope mid-launching itself across the surface seemingly taking the plug with it.

EDIT3:  I'm playing around with a new script where I start the rigidbody plug attachments with high compliance; the script waits several frames and then reduces the dynamic attachments compliance to a smaller value.  At first it wasn't picking up the updated compliance values.  But then I figured out if I disable, then set compliance, then enable the attachment, it does.  And so far this is looking promising as a way to successfully mitigate my issue if I can't outright solve it by some other means.

[Skotty]

I'm continuing to try and diagnose the problem.  Here's some new info.  For my latest test, I've switched to a Box Collider on the Rigidbody object, and I've made it way oversized for the mesh.  In editor, the rope goes in the middle of the back of the red plug.  But in play, it's off to the side.  See screenshot.  I've configured the categories.  Rope is on Category 1, the two attachments near the plug set to not collide with Category 2.  Then the rigidbody collider is set to Category 2, and set not to collide with Category 1.  From the oversized collider, shown in green outline, the rope is perfectly happy being inside the collider.  The whole thing sits there peacefully.  Yet it almost looks like the rope does not want to be inside the mesh.  Why is it drooping out the side?

The compliance trick I mentioned in previous comment (starting it off high, using script to drop it to 0 after a few frames) works to stabilize the whole thing.  But it still just seems wrong somehow.

EDIT: Added another image to show what it looks like in editor as well.

EDIT2:  Maybe the droop is unrelated.  In a followup test, I moved the attachments up quite a bit, so in editor they appear above the plug.  It helps having a box collider so it doesn't try to roll over or anything.  Anyway, then in play, they look mostly centered.  Hm....  Why the difference between editor and play?  At this point, it looks like I can "fix" the problem by doing two things -- positioning the attachments above the plug, and using the compliance dropping trick.  But I would guess I'm still just addressing symptoms of some other problem.  On the off chance there might be some distance from origin glitch, note that this test play position is at roughly world position (210, 100, 190).

[josemendez]

Would it be possible for you to share this scene with me, so that I can take a closer look? (by sending it to support(at)virtualmethodstudio.com) I've been unable to reproduce similar behavior in my tests.

The only thing I notice from your screenshots is that the blueprint resolution is at maximum (1). There's no reason I can think of for it to be this high, it will be exceedingly costly to simulate and the rope will be very elastic unless you use a crazy high amount of substeps - this gets even worse since your rope is pretty long.

The difference in editors vs play / droopping issue might simply be that the solver is completely unable to converge if your simulation budget is small for the sheer amount of constraints in your rope. At the very least I'd halve the resolution (0.5), but you can probably go even lower (0.2-0.4) if you use smoothing to generate the rope mesh. Also make sure you're using at least 8 substeps (I'm eyeballing it given the amount of particles in your rope).

kind regards,