Feature Request - Collision Enhancements

[virtushda]

With the Unity's Cloth component still sucking(even after the 2017.3 update), I thought I'd bring up a couple collision-related things it seems to do better, in hopes that you might be able to add them.  

From my impressions, these are two features Unity Cloth appears to have that ObiCloth appears not to have:

1. Virtual Particles: Adds one virtual particle per-triangle to increase collision stability.
   
2. Normal-based Rejection(what I'm calling it): Unity Cloth seems to handle high-speed collisions far better, especially if they screw up, particles are quickly ejected along the closest surface normal(or perhaps the last encountered surface-normal they encountered). It also appears like there may be a position bias to this function so that collider's movement in-between physics time-steps is taken into account. At least, this is my impression of what it's doing.
   

Edit: While trying to fix my new problem(other thread), I ran into one of Jose's old posts about how primitive colliders aren't "hollow", so my second request may be pointless as I was referring to collision with primitives. However, the PhysX-based cloth still handles collisions much better. Maybe I need more collision iterations? But then why would it take more than one iteration to "project" to the outside of the collider? Only more questions...

[josemendez]

With the Unity's Cloth component still sucking(even after the 2017.3 update), I thought I'd bring up a couple collision-related things it seems to do better, in hopes that you might be able to add them.  

From my impressions, these are two features Unity Cloth appears to have that ObiCloth appears not to have:

1. Virtual Particles: Adds one virtual particle per-triangle to increase collision stability.
   
2. Normal-based Rejection(what I'm calling it): Unity Cloth seems to handle high-speed collisions far better, especially if they screw up, particles are quickly ejected along the closest surface normal(or perhaps the last encountered surface-normal they encountered). It also appears like there may be a position bias to this function so that collider's movement in-between physics time-steps is taken into account. At least, this is my impression of what it's doing.
   

Edit: While trying to fix my new problem(other thread), I ran into one of Jose's old posts about how primitive colliders aren't "hollow", so my second request may be pointless as I was referring to collision with primitives. However, the PhysX-based cloth still handles collisions much better. Maybe I need more collision iterations? But then why would it take more than one iteration to "project" to the outside of the collider? Only more questions...  

Hi!

- Virtual particles were supported in Obi Cloth 1.0 but were removed because they increased the cost of collision resolution, and ability to set individual particle radii using the particle editor pretty much renders them useless.

Basically they act as additional sample points on the surface of the mesh triangles, receiving and redistributing impulses to the actual simulated particles. They help in situations where cloth triangles are larger than the rigidbodies colliding against it. However Obi's ability to set a larger radius for the cloth particles solves the same problem, and the cost is zero. In the near future, Obi will add support for ellipsoidal -oriented- particles, which will allow for even finer collision detection.

- High speed collisions are handled by Obi much better (in fact it is almost immune to tunneling), but only against primitive colliders (spheres, boxes, and so on). Next update will feature ADFs (adaptive distance fields) which allow for extremely fast and robust collision detection against any shape, even "non-hollow" MeshColliders, at the cost of additional memory to store the field data.

Regarding your question:

Code:

But then why would it take more than one iteration to "project" to the outside of the collider?

It would take only 1 iteration if there were no other constraints active at the same time, and only 1 collider affecting the particle. However this is rarely the case.
Constraint iterations in Obi are interleaved. This means that if you have 10 distance iterations and only 5 collision iterations, then the simulation does this:
- Distance iteration
- Distance iteration + Collision iteration
- Distance iteration
- Distance iteration + Collision iteration
...
and so on. This is a technique borrowed from Maya's Nucleus solver. Every 2 distance iterations, a collision iteration is performed, for a total of 10 iterations. This means that every other iteration, only distance constraints are considered, and collision constraints can be slightly violated. You would need additional iterations to project the particles outside of the collider, simply because other constraints may be acting against the collision constraint's "interest" and undoing their work, if that makes sense.

hope this clarifies the situation! cheers

[virtushda]

Thanks for the in-depth reply, that clarifies everything!