(20-09-2026, 08:03 AM)josemendez Wrote: Hi!Thank you for the tips.
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
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.