Commit 62e03cc3 authored by Sreekanth Arikatla's avatar Sreekanth Arikatla
Browse files

DOC: Update documentation for Collision detection

parent fce13ffa
......@@ -496,26 +496,106 @@ The radiance cubemap in particular should be mipmapped.
Collision Detection
===================
Collision detection (CD) is the process of detecting collision between
two geometrical shapes. The geometrical shapes, as explained earlier,
can be represented as a collection of one or more primitives (eg:
points, lines and triangles). Therefore, the CD determines the collision
between two sets of primitives. The collision data that is produced as a
result of the collisions is passed on to the collision handling module.
Any collision detection algorithm results in one or more of the
following data types:
- VertexTriangleCollisionData
- EdgeEdgeCollisionData
- MeshToAnalyticalCollisionData
- PointTetrahedronCollisionData
- PickingCollisionData
iMSTK currently supports analytical geometry to mesh and inter mesh
collision detection. Continuous collision detection (CCD) is made
available in imstk through selfCCD library. CCD algorithm extends the
collision in time thereby capturing the collisions otherwise missed by
the traditional collision detection algorithms.
A typical simulation scenario can feature multiple objects interacting with each other in real-time. Collision detection (CD) is the first step to resolving the physical contact between the objects that are typically represented using a collection of simpler geometric primitives such as vertices, edges, and triangles. Collision detection algorithms are tasked to not only detect and but also report the geometric details of all the points of contact. Accurately and efficiently detecting collisions between interacting objects and handling them using appropriate mechanisms can enhance the accuracy and the realism of application.
Collision detection is typically divided into two phases: (a) the broad phase where a set of candidate collision primitive pairs is identified, and (b) the narrow phase where the geometric intersection tests are performed on these candidate primitive pairs [cd1]_. The narrow phase intersection tests are computationally expensive and hence the broad phase algorithms aim to achieve smallest possible candidate set of collision pairs (with all the actual collision pairs being a subset) with a minimal computational cost.
The broad phase algorithms typically employ hierarchical spatial partitioning data structures such as octrees or BVH to organize and store geometric information for efficient retrieval and processing. Collision detection has been researched extensively in the computer graphics area and its implementation can vary widely depending on the assumptions that are valid for the problem at hand and the target hardware.
Broad Phase
-----------
iMSTK's broad phase uses octree data structure to perform quick culling of the primitive collision pairs.
Octree Collision
~~~~~~~~~~~~~~~~
An octree is an axis-aligned hierarchical data structure that is generated by recursively subdividing the axis-aligned bounding box (AABB) into eight equally-sized cells as necessary. Generally speaking, the choice of whether to subdivide an octree node or not depends on the density of information present at that node which in this case is the geometry of the primitives.
A brute-force way to find collisions between a set of n disjointed primitives can mean testing all the possible pairs which can be computationally prohibitive requiring O(n2) work. The broad phase of the collision detection aims to efficiently eliminate a subset of primitive pairs (also called culling) that are guaranteed not to collide thus leaving only fewer combinations for which expensive geometric tests are performed. An efficient broad phase algorithm aims to minimize the size of the left out pairs while still retaining guarantees (i.e., all the colliding pairs are part of this set).
The broad phase of the octree collision detection consists of two stages:
**Tree update**: In this step, each primitive under consideration for collision are assigned to an octree node depending on the spatial extent, position, and orientation. For this purpose, the AABB of each primitive is recursively checked against the cells starting at the root node. A primitive will be assigned to a node if either the primitive size exceeds the extent of the cells of the child nodes or the current node cannot be further subdivided due to a preset limit on the maximum depth of the octree.
**Culling**: This step aims to take advantage of the spatial partitioning of the octree and eliminate as many non-colliding primitive pairs as possible from the list of all the possible pairs. Given a primitive, it is first checked for intersection with the boundary of the root node. If the primitive does not intersect with the node boundary, no further operation is performed with the tree node. Otherwise, it is then tested for intersection with all the primitives stored in the tree node. This process is then recursively called on the child nodes until reaching leaf nodes. With n primitives, detecting a collision between them has a time complexity O(nhk) in the worst case, where h is the height of the octree, and k is the maximum number of primitives at any octree node. In practice, h is around 10 and most primitives are stored at the leaf nodes; thus, the cost of detecting collision for each primitive is bounded and can be very cheap.
In iMSTK, OctreeBasedCD class embeds the implementation of the above-described functionality. Users can both access the list of primitives at any given node in the hierarchy and collision data through public API. The code snippet below shows how an octree is built and used to detect collision between two mesh objects that contain triangle primitives:
::
// Initialize the octree
OctreeBasedCD octreeCD(Vec3d(0, 0, 0), // Center of the root node
100.0, // Side length of the root node
0.1); // Minimum allowed width for any octree cell
// Add mesh objects containing triangle primitives to the octree
octreeCD.addTriangleMesh(triMesh_1);
octreeCD.addTriangleMesh(triMesh_2);
// Build the Octree
octreeCD.build();
// Add collision pairs between meshes
octreeCD.addCollisionPair(triMesh_1, triMesh_2,
CollisionDetection::Type::SurfaceMeshToSurfaceMesh);
At any given frame during the simulation, querying the generated collision data:
::
// Update octree (primitives might have moved in the prior frame)
octreeCD.update();
// Access the collision data for the mesh pair
const auto& colData = octreeCD.getCollisionPairData(
indx1, // Global index of triMesh_1
indx2); // Global index of triMesh_2
Narrow Phase
------------
iMSTK provides numerous narrow phase intersection tests between primitives
and are implemented as static functions within the *imstk::NarrowPhaseCD* namespace. The current list of functions provide the following intersection tests:
- *BidirectionalPlane-Sphere*
- *UnidirectionalPlane-Sphere*
- *Sphere-Cylinder*
- *Sphere-Sphere*
- *Point-Capsule*
- *Point-Plane*
- *Point-Sphere*
- *Triangle-Triangle*
- *Point-Triangle*
Continuous collision detection
------------------------------
Continuous collision detection (CCD) algorithm extends the collision in time thereby capturing the
collisions otherwise missed by the traditional collision detection algorithms.
CCD is typically used in cases where there are fast moving objects in the scene causing the traditional *discrete* CD fail to detect collisions. CCD performs collision of the volumes swept by the colliding primitives
in order to detect the exact time of intersection (if any). In iMSTK, CCD is made available
through selfCCD library. The class *SurfaceMeshToSurfaceMeshCCD* imlpements this feature.
Note that in addition to the geometry information resulting from intersection tests, CCD
outputs a scalar 'time' that is normalized between 0-1 for the time period between the frames being considered.
Collision data
--------------
The collision data that is produced as a
result of the collisions and is passed on to the collision handling module for processing. Any collision detection algorithm results in one or more of the following data types:
- Vertex-Triangle
- Edge-Edge
- Mesh-AnalyticalGeometry
- Point-Tetrahedron
- Position-Direction
The definitions of the above collifion data types can
be found in *imstkCollisionData.h*.
Collision Handling
==================
......@@ -1123,6 +1203,8 @@ Bibliography
.. [sph5] Teschner, M., Heidelberger, B., Müller, M., Pomeranets, D., and Gross, M,
“Optimized spatial hashing for collision detection of deformable objects”. Proc. VMV, 47–54.
.. [cd1] Christer Ericson. Real-Time Collision Detection. CRC Press, Inc., Boca Raton, FL, USA, 2004.
.. |image0| image:: media/logo.png
:width: 3.5in
:height: 1.28515625in
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment