Mass Collisions for Rope

[PhantomBadger]

Hi all,

Im looking to see if it's possible to have the Obi Rope collide with essentially everything in the scene. From reading the docs it seems the only performance issue is during the transfer between C# and C++, which is a performance hit we're fine with having at the start assuming that's the only place it is present.

My current solution is to run something like this:

Code:

   /// <summary>
   /// Collects all the MeshColliders in the scene and attached it to ObiSolver
   /// </summary>
   private void CollectAllColliders()
   {
       //Get all mesh colliders in the scene
       MeshCollider[] allColliders = FindObjectsOfType<MeshCollider>();

       //Make a collider group
       Obi.ObiColliderGroup colGroup = new Obi.ObiColliderGroup();
       colGroup.colliders = new List<Collider>(allColliders);

       //Attach it to the solver
       ObiSolver.colliderGroup = colGroup;
   }

in the Start() method. This runs fine, but then Unity promptly crashes on the following first frame. The number of colliders is around 924. My main questions stemming from this are as follows;

• Is this approach possible, but we're just exceeding some kind of upper-limit with colliders?
  
• Is there an alternate approach to getting all possible colliders to interact with a single rope instance?
  
• Does the performance hit from C#->C++ happen only st the start when they're registered, or every frame as their positions are updated?
  

I would assume the solution should this not be possible is to simply cherry pick the most important colliders.

Thanks for your response!

[PhantomBadger]

As a small update, I am running into issues when setting up collisions through the intended way, as it seems only objects in the scene that don't move are actually being affected by collisions, and even then the rope seems to pass through the colliders a lot of the time.
So to reiterate, the large machine in the middle of the room is affected by collisions, but the table the rope starts on is not for some reason.
Any ideas? The rope and solver are on their own layers.

EDIT:
Let me tell you a tale of my current woes;
If I put the rope above a simple box collider with the Obi Collider script, the ONLY way I can produce a collision is when the GameObject, The Rope, both rope ends, and the Obi Solver are on the SAME layer (A new layer I made called 'Rope'), which goes against the docs completely... 
Based on this, I set the above objects to the Layer of the objects I want it to interact with, and it immediately stops registering collision with the above GameObject. In fact I can set it to any layer except the layer I want, and it still works. So I thought it could be that the Machine layer (the one I want) has a lot of stuff already on it, and that's giving it some grief somehow. So I set every object in the scene to the Rope layer... and it collides perfectly fine whilst also on the rope layer.
There are no differences on the Machine Layer Collision Matrix that could cause this, so why is it that one layer doesn't work? Is it something to do with the Layer number??

[josemendez]

Hi PhantomBadger,

I'l try to answer your questions.

You assumption that the cost of copying collider data from C# to C++ hits you only once is incorrect. The data has to be copied every frame (just once per frame, not once per simulation step), because colliders can move (except those marked as static), can have parameters modified at runtime, etc... For this reason the ObiColliderGroup exists, to let users specify upfront which colliders should be considered for collision.

This is of course less than ideal, but since there's no way to get callbacks on collider property modifications or map the memory regions where the colliders reside in Unity, this is the only option left. 

In ObiRope 3.1 you can set per-particle layer values. This means that once you Initialize the rope, its particles are kept in the layer the rope was initialized on. If you later move the rope to a different layer, this won´t affect the particles themselves unless you click on "Set particles to layer" (found in the rope inspector). You can also explicitly set per-particle layer values using the particle editor.

The layer collision matrix is not used at all by Obi.

Based on your statement that "only objects in the scene that don't move are actually being affected by collision", I have to ask: are you using MeshColliders? If so, then: are you moving them by altering their transform directly? If this is the case, you're running into tunneling issues, and I´ll explain further.

cheers!

[PhantomBadger]

Hi PhantomBadger,

I'l try to answer your questions.

You assumption that the cost of copying collider data from C# to C++ hits you only once is incorrect. The data has to be copied every frame (just once per frame, not once per simulation step), because colliders can move (except those marked as static), can have parameters modified at runtime, etc...  For this reason the ObiColliderGroup exists, to let users specify upfront which colliders should be considered for collision.

This is of course less than ideal, but since there's no way to get callbacks on collider property modifications or map the memory regions where the colliders reside in Unity, this is the only option left. 

In ObiRope 3.1 you can set per-particle layer values. This means that once you Initialize the rope, its particles are kept in the layer the rope was initialized on. If you later move the rope to a different layer, this won´t affect the particles themselves unless you click on "Set particles to layer" (found in the rope inspector). You can also explicitly set per-particle layer values using the particle editor.

The layer collision matrix is not used at all by Obi.

Based on your statement that "only objects in the scene that don't move are actually being affected by collision", I have to ask: are you using MeshColliders? If so, then: are you moving them by altering their transform directly? If this is the case, you're running into tunneling issues, and I´ll explain further.

cheers!

That single button has saved so much hair pulling and inconsistencies in our implementation! Thank you! I had expected tunneling was the issue with the finer parts of the mesh colliders yes, is there a solution to this? If not we'll have to go for some broad-phase colliders.

Thanks for your help!