Handle negative security margin

[jcarpent]

No description provided.

[jmirabel]

This PR is big and not easy to review. Before reviewing, I would prefer to have an overview of the theoretical aspects.
Is it already written somewhere ?

If no, maybe we should write it down somewhere. It does not have to be very detailed but it is worth explaining:

• how BV checks behaves
• the main difference(s) with positive only security margin.

[jcarpent]

Yes, I do agree it is big, but it was needed in fact.
Briefly, the first idea was to shrink primitives to account for the negative security margins. This was in fact not needed.
I kept the inflate property for basic primitives as it can be useful for extra users (such as us).

Finally, the solution is to compute the penetration distance and subtract the negative margin to collect or not a collision.
I've added it with a large set of testing to correctly check the values. Following this idea, I've adapted the AABB and other used BVs to account for negative margins in overlap functions.

[jcarpent]

May I merge this PR?

[jmirabel]

On the algorithmic side, there is still something that puzzles me.

Consider two objects A and B. A is made of 2 triangles (A1 and A2) in the same plane. B is a single triangle. Let m < 0 be the security margin. There are cases where d(A1, B) > m and d(A2, B) > m but d(A, B) < m. Do you address those cases ?

[jcarpent]

Currently, the notion of penetration is only valid for convex volumes.

[jmirabel]

So you should not allow negative security margin for BVH models.

[jcarpent]

Yes, good point. I will add this check then.

[jcarpent]

Yes, good point. I will add this check then.

@jmirabel In fact, this is already done ;)

[lmontaut]

For me the PR looks good. It has a lot of commits because @jcarpent tested the deflation idea which might be useful for later. But in the end, the negative security margin doesn't change anything fundamental in the code. The security margin is simply subtracted to the distance computed by GJK/EPA. The deflation idea might be interesting to explore in the future to avoid calling EPA?

[jcarpent]

The deflation idea might be interesting to explore in the future to avoid calling EPA?

An interesting idea indeed.

[jmirabel]

Sorry for the very long delay. I'm very busy at the moment. I won't be able to do a thorough review in a reasonable time so I stick to a overall look at it.

Thanks for the hard work.

On an organization point of view, I'm wondering if there is any good way of making PRs in this project easier to review. Some ideas :

• avoid reformatting changes for big PR. We can leave them either for a commit pushed after review and before merge or leave for another PR. They make it very hard to focus on important changes.
• put some github comment in the code that requires special attention.
• try to split core changes and cosmetic / convenience changes.

PS: This discussion can probably go in matrix instead.

[jmirabel]

The deflation idea might be interesting to explore in the future to avoid calling EPA?

An interesting idea indeed.

For primitive shapes that are not meshes, it is rather easy to achieve deflation and EPA is particularly bad for them so this could be done in a first iteration.
For other meshes, it isn't trivial at all.

[jcarpent]

Sorry for the very long delay. I'm very busy at the moment. I won't be able to do a thorough review in a reasonable time so I stick to a overall look at it.

Thanks for the hard work.

Thanks for the feedback.

[jcarpent]

Sorry for the very long delay. I'm very busy at the moment. I won't be able to do a thorough review in a reasonable time so I stick to a overall look at it.

Thanks for the hard work.

On an organization point of view, I'm wondering if there is any good way of making PRs in this project easier to review. Some ideas :

* avoid reformatting changes for big PR. We can leave them either for a commit pushed after review and before merge or leave for another PR. They make it very hard to focus on important changes.

* put some github comment in the code that requires special attention.

* try to split core changes and cosmetic / convenience changes.

PS: This discussion can probably go in matrix instead.

I do agree an all these points. As usual, the main issue is time to order contributions.
Next time I will try to split into various PRs to enhance the readibility.