Add CollisionResult::nearest_points

[jmirabel]

This supersedes #198 .

Work left to be done:

• agree on the API
• handle shape-shape collision
• add some unit test
• revise the distance lower bound (does not take the security margin).

Class ShapeCollisionTraversal should be removed.

As a bonus, this also solves #199.

[jmirabel]

@nim65s does it make sense to turn off travis (except for osx) ?

[nim65s]

I prefer not to have opinions about travis. If someone wants to use and maintain it, that's perfectly fine for me, but on my side I have enough work and results with one CI stack :)

[jmirabel]

After some effort, I ended up with the following.

• for collision queries, all the returned distances take the security margin into account,
• the collision result stores valid nearest_points whenever the distance lower bound is inferior to break_distance. When the distance lower bound is higher, their validity depends upon the pair of object type (maybe we should add a boolean that says whether they are valid).
• the distance lower bound can be negative, in which case it is the opposite of the penetration depth (the security margin is taken into account).

This leads to one strange thing. With the current changes, when the distance lower bound is inferior to the break distance, we don't have ||AB|| = distance_lower_bound but ||AB|| = distance_lower_bound + security_margin(A and B being the nearest point). i.e. the nearest point are not on the shapes inflated bysecurity_margin/2`

Some improvements, kept for later:

• For BVH, the minimal distance between two bounding volumes could be decrease as the algo finds smaller distance lower bound. This is especially useful when the break_distance is set to a high value.
• Rename break_distance to something easier to understand from the user perspective.
• Clean API of CollisionTraversalNode:
  • remove ShapeCollisionTraversalNode,
  • merge the two CollisionTraversalNode::BVDisjoint prototype into one. The squared distance lower bound attribute is not useless.
• The above API should be enforced by some unit-tests.

[jmirabel]

This PR is ready for reviews.

[jmirabel]

TODO: sometimes the contact distance takes the security margin into account. Sometimes it does not. It should be homogenized.

[jcarpent]

Why to not apply the change here?

[jmirabel]

I plan to do it. I wrote it so as not to forget.

[jcarpent]

Maybe, this should fix another bug

[jcarpent]

@jmirabel Could you consider adjusting this PR for merging it?

[jmirabel]

Not sure what you are asking exactly. I can definitely resolve the git conflicts quickly. Adding unit test, finalizing the code and maybe update the API is another story. I know I won't have time before beginning of March. Then I am not sure yet.

[jmirabel]

I assigned myself so that I see this in my list of assigned PRs.

[jcarpent]

@jmirabel Why do you remove that here?

[jcarpent]

Supersedes by #303.