search

flexible-collision-library / fcl

Flexible Collision Library
https://flexible-collision-library.github.io/
Other
1.44k stars 416 forks source link

Primitive Sphere to Primitive Sphere does not use the primitive shape algorithm #337

Open Levi-Armstrong opened 6 years ago

Levi-Armstrong commented 6 years ago

I am curious why when checking a primitive sphere to primitive sphere it is using the GJK solver instead of the primitive shape algorithm?

SeanCurtis-TRI commented 6 years ago

Several questions:

  1. Are you sure it's not using primitive? The primitive tests are invoked via the gjk_solver types.
  2. Which gjk solver are you using?
  3. What query are you doing? (Collision is independent of distance.)
Levi-Armstrong commented 6 years ago
  1. I am stepping through the code and it is calling detail::GJKSignedDistance function then makes it way to ccdGJKSignedDist function
  2. GST_LIBCCD
  3. Distance
SeanCurtis-TRI commented 6 years ago

I haven't played as much with the distance queries -- so it's decidedly possible that it's using GJK. I know the recent improvements to EPA that @hongkai-dai did were inspired by the horrible solutions we were getting for distance between spheres and, at the time, I railed against the idea that it wasn't being evaluated by a primitive-specific function. So, in this case, it may be as bad as it seems.

Levi-Armstrong commented 6 years ago

Not sure if this make any difference but I using the Dynamic AABBTreeCollisionManager and I am calling its distance function.

I assume the desired approach would be to use the primitive shape method?

SeanCurtis-TRI commented 6 years ago

As near as I can tell, it should ultimately be invoking detail::sphereSphereDistance. Try putting a breakpoint in it.

The broadphase shouldn't make a difference .

SeanCurtis-TRI commented 6 years ago

Oops -- that's for unsigned distance. If you call signed distance, there are no primitive tests.

Levi-Armstrong commented 6 years ago

Would you all be opposed to adding ones for signed distance?

SeanCurtis-TRI commented 6 years ago

Of course not. In some cases, it should be the same function. For primitives like spheres, the cost of finding the signed distance is the same as finding the separating distance.

The most important thing is that there not be two almost parallel computations. Ideally, one should be expressed in terms of the other. Because as soon as we offer two functions that should provide the same answer in a particular domain, but don't use the same code, we're setting ourselves up for trouble.

Levi-Armstrong commented 6 years ago

Agree I will look into it.