28-06-2017, 10:15 AM
(27-06-2017, 05:34 PM)josemendez Wrote: 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!