Adding swept-sphere radius + removing dead code #558
Conversation
|
Hello @lmontaut |
Hi @florent-lamiraux, yes! However, it is sometimes usefull to compute the support function of shapes while taking into account their swept-sphere radius, so I added the support for that. |
|
Isn't it redundant with security margins ? |
Yes, it's a redundant information if only the distance between the shapes is considered. In the end, I think swept-sphere radius and security margin are two complementary information:
|
All right. I understand. |
Serialization works normally for derived class. @lmontaut Have you encountered any issue? |
Yes, I can't serialize a Again, maybe I am doing something wrong on the C++ side. I will delete this todo after investigation :) |
lmontaut
force-pushed
the
topic/swept-sphere-primitives
branch
2 times, most recently
from
25dd169
to
2fa9a00
Compare
There is never the need to normalize the support direction when computing a support point. This is because the argmax support function (the support point) is invariant by multiplication by a positive scalar. So the support in the direction dir or alpha * dir (with alpha > 0) will always be identical, no matter the shape.
GJKSolver has direct access to GJK's distance_upper_bound field, so there is no need to store it in GJKSolver. We don't remove max iterations and tolerance fields because they are used in the constructor of GJK and EPA. Of course we also don't remove things related to cached guess.
GJK and EPA don't need to inflate the supports by the swept sphere radii of the involved shapes at each their iterations. This is a very nice mathematical property, which allows to run GJK/EPA on the original shapes and simply correct the solution GJK/EPA found after they have converged. However, it is sometimes usefull to have access to the "true" support function of a shape swept by a sphere. Hence the template parameter. The rule is simple: when interacting with GJK/EPA, this template parameter should always be `false` (except for debugging purposes). When interacting directly with a shape and using its support function, the template parameter should always be `true`.
The ShapeShapeDistance function is responsible for either calling directly GJK/EPA or calling a specialized function.
I previously deleted these attributes (woopsie). It's actually important that they appear as attributes as most methods of `GJKSolver` are const. The idea is that only the API functions of hpp-fcl (like collide/distance or ComputeCollision/Distance functors) are the only one functions which can set up the GJKSolver. Then, any other internal functions (like ShapeShapeCollide or BVHShapeCollide etc.) only work with `const GJKSolver *`. This way, we make sure that the settings of the GJKSolver are not modified.
- Certain primitives can be "inflated". This returns a pair of new primitive and a new Transform.
An inflated primitive is simply elongated/shrinked along its primary dimensions.
An inflated box is simply the original box which vertices have been elongated along the primary
axiis of the box.
Note that the inflation does not need to be positive. A primitive can be deflated ("inflated negatively").
- Swept-sphere radius is different: the shape is not modified. Swept-sphere radius is a property
of a shape which mainly softens its sharp corners (a box will become a box with rounded corners).
The swept-sphere radius cannot be negative.
To fully distinguish between these two features, I made sure any comment/template/variable referring
to swept-sphere radius did not have the word "inflation", as this word is reserved to talk about
the "inflated" methods of certain primitives.
Previously `GJKSolver::shapeDistance` was specialized for Triangle-Triangle`. This was removed, and now `ShapeShapeDistance` is the one taking care of the specialization.
To remove any possible confusion, a signature of ShapeShapeDistance is created which has no mention of `DistanceRequest/Result`. This function is used in complex structures like BVHs, Hfields and octrees.
Added a comment in EPA that explains it all. In a future PR, I will remove the `NonConvex` status of EPA, as it useless. Even when EPA is called "when it should not be" (i.e called on non-colliding shapes), it will work just fine and return the correct result. This is a very very cool property of EPA.
The doxygen_xml_parser.py script complains when an empty template param is found (`typename = `). This happens for `GJKSolver::shapeDistance` applied to TriangleP-TriangleP. In any case, the `GJKSolver::shapeDistance` should not be template instanciated for this pair of shapes as EPA does not work for TriangleP-TriangleP. This fix actually makes sure the specialized TriangleP-TriangleP algo is used instead.
jcarpent
force-pushed
the
topic/swept-sphere-primitives
branch
from
85958db
to
a7e5f31
Compare
## [3.0.0] - 2024-11-20
### Added
- Renaming the library from `hpp-fcl` to `coal`. Created a `COAL_BACKWARD_COMPATIBILITY_WITH_HPP_FCL` CMake option for retro compatibility. This allows to still do `find_package(hpp-fcl)` and `#include <hpp/fcl/...>` in C++ and it allows to still do `import hppfcl` in python (coal-library/coal#596).
- Added `Transform3f::Random` and `Transform3f::setRandom` (coal-library/coal#584)
- New feature: computation of contact surfaces for any pair of primitive shapes (triangle, sphere, ellipsoid, plane, halfspace, cone, capsule, cylinder, convex) (coal-library/coal#574).
- Enhance Broadphase DynamicAABBTree to better handle planes and halfspace (coal-library/coal#570)
- (coal-library/coal#558):
- [internal] Removed dead code in `narrowphase/details.h` (coal-library/coal#558)
- [internal] Removed specializations of methods of `GJKSolver`. Now the specializations are all handled by `ShapeShapeDistance` in `shape_shape_func.h`.
- [new feature] Added support for Swept-Sphere primitives (sphere, box, capsule, cone, ellipsoid, triangle, halfspace, plane, convex mesh).
- [API change] Renamed default convergence criterion from `VDB` to `Default` (coal-library/coal#556)
- Fixed EPA returning nans on cases where it could return an estimate of the normal and penetration depth. (coal-library/coal#556)
- Fixed too low tolerance in GJK/EPA asserts (coal-library/coal#554)
- Fixed `normal_and_nearest_points` test (no need to have Eigen 3.4) (coal-library/coal#553)
- (coal-library/coal#549)
- Optimize EPA: ignore useless faces in EPA's polytope; warm-start support computation for `Convex`; fix edge-cases witness points computation.
- Add `Serializable` trait to transform, collision data, collision geometries, bounding volumes, bvh models, hfields. Collision problems can now be serialized from C++ and sent to python and vice versa.
- CMake: allow use of installed jrl-cmakemodules (coal-library/coal#564)
- CMake: Add compatibility with jrl-cmakemodules workspace (coal-library/coal#610)
- Python: add id() support for geometries (coal-library/coal#618).
Packaging changes:
- renamed package
- removed patch 522, merged upstream
- updated patch aa
- replaced common Makefile from HPP to JRL
- turned on backward compatibility with hpp-fcl
- updated required version to 3.0.0 (coal < 3.0.0 does not exist)
Ok, it's a big PR, haven't finished it yet but it's almost done.
Before I rant, note that there are absolutely no changes to HPP-FCL API, it's only internal stuff.
It started with a simple premise: adding swept-sphere radius for all shapes of HPP-FCL.
However, it got a bit out of hand.
When making simple modifications to the library, I would always encounter compilation errors which were coming from dead code.
This is very frustrating to deal with because 90% of the time is spent fixing code that is not used and not supported.
Most of the problems come from a single culprit: the
GJKSolver. This solver had specializations for specific pairs of shapes.However, these specializations were already dealt with in the
ShapeShapeCollide/Distanceinternal functions. So this means having to keep track of multiple specializations. On top of that, most of these specializations were located in adetails.hfile which contained about 2000 LOC of dead code. Also, many functions had conflicting convention on their return value.The solution: I moved all the specialized algorithms to the
ShapeShapeCollide/Distanceinternal functions and skinned theGJKSolver. NowGJKSolver, as its name indicates, is only used to run GJK/EPA.This also has the benefit of being able to test the specialized algorithms against GJK/EPA.
The overall philosophy is the following: no internal functions in HPP-FCL should directly call the
GJKSolver.All internal functions should use either
ShapeShapeCollideorShapeShapeDistance, which take care of either using a specialized algorithm or GJK/EPA.TODOs regarding the original swept-sphere PR:
Inflation[...]toSweptSphere[...]MinkowskiDiff::setandgetSupportNext PR:
computeLocalAABB).