How to provide custom CollisionGeometry types?

[chhtz]

Hi, sorry for adding this as an issue, it is actually more of a question (but I did not find any other support channel).

Essentially, what I have is a data structure (a multi-level grid) which I want to collide with other collision objects. I understand that I can just inherit from fcl::CollisionGeometry, but I'm not sure what I shall return as OBJECT_TYPE and NODE_TYPE, (without patching these enums) and how I should register my custom type.

[jslee02]

Yeah, this issue tracker might be the only support channel other than Stack Overflow. 😓

I think adding new collision geometry type wouldn't be straightforward; you might need to implement all the glue algorithms to make the new collision geometry work fine with other objects and for all the queries (collision, continuous-collision, distance).

Wouldn't your data structure fit to any of current geometry types of FCL? BVHModel could contain either of convex/concave mesh or point cloud model (I haven't tested point cloud model myself though).

[chhtz]

Hi, thanks for your response! I started looking into BVHModel, and as far as I understood it I could try to provide some custom "tree" structure (which in my case is actually a grid of lists), right? Is there an example somewhere how to start this? My first assumption would be that I need to specialize BVHModel<MLSModel>, somehow (with a new custom class MLSModel). I guess I need to have a closer look into your source.

[jmachowinski]

Hi, I'm working with christoph on this. I also took a look into the source an must say I'm a bit puzzled. Is there somewhere a document that describes the architecture of fcl ?

What is clear to us, is that we need to provide all function to collide all supported shapes against our own collision object.

After we defined them all, we would then need to hard code them into the collision_matrix ? Or is there a more elegant way ? I guess we also then would need to implement the CollisionGeometry for our own object, and give out the AABB and the center etc.

[jmachowinski]

Hm, I just realized, I should give more detail on our data structure. We got a regular grid with a custom resolution. Each cell of the grid contains an ordered list of patches of occupied space.

Our approach would be to generate on the fly boxes for every 'height' patch that is in the vicinity of other shape (using the BB) and use the existing box / shape tests then. Does this sound like a good idea, or would there be a better way ?

[jslee02]

Sorry for delayed response. As far as I know, there is no documentation. Here is some background of the architecture of FCL for adding new collision object:

• Nothing to do with broadphase algorithms for adding new collision geometry type
• In high-level, all the collision geometries fall into three categories: primitive shapes (e.g., box or sphere), mesh, and octree
• Every collision geometry is treated as a BVH, which is a tree structure whose leaf is the elements of the collision geometry.
  • The triangles of a mesh are the leaf nodes.
  • A primitive shape forms a single node tree.
• Collision/distance/continuous-collision matrix resolves which algorithm should be performed for given two geometry object, which is hard coded.
• The most under the hood algorithm for mesh-mesh is the triangle-triangle collision.
• The collision/distance of primitive shapes are generally computed using convexity based algorithms (GJK, EPA, and MPR), where FCL selectively uses one of libccd implementation and own implementation. For this, the primitive shape should provide two necessary computations: center and support vector.
• Some pair of primitive shapes uses specialized collision algorithms (e.g., sphere-sphere, plane-sphere), which are faster than the convexity-based algorithms.

Here is a list of things to add new collision geometry to the best of my knowledge:

• Create a collision geometry that inherits CollisionGeometry
• Create template function that handles BVH procedure. You might need multiple handlers depending on the opponent collision geometries (e.g., shape, mesh, octree) also on types of queries (i.e., collision, distance, and continuous collision) (see (collision/distance/continuous_collision)_func_matrix.h and traversal directory).
• Add you new collision geometry to the collision/distance/continuous collision function matrices. You first add the geometry type to OBJECT_TYPE and NODE_TYPE.
• Implement the most under the hood collision/distance algorithms that will bed called by the BVH handlers.
• Add unit tests :smile:

I think OcTree could be a reference.

By the way, I suggest starting your implementations from inl_design_pattern branch because it includes significant source tree changes that will be merged I believe.