通信信道中的碰撞检测
就是计算机边发送数据边检测信道上的信号电压大小。
当一个站检测到的信号电压摆动值超过了一定的门限值时，就会认为总线上至少有两个站同时在发送数据，表示产生了碰撞。在发生碰撞的时候，总线上传输信号产生了严重的失真，无法从中恢复出有用的信息来。每一个正在发送数据的站，一旦发现总线上产生了碰撞，就立即停止发送，以免继续浪费资源，再等待一段时间后再次发送。
以太网取51.2μs为争用期长度。对于10Mb/s以太网，在争用期内可发送512bit，即64B。则以太网在发送数据时，若前64B没有冲突，则后续的数据就不会发生冲突。如果发生冲突了一定是在发送的前64B以内。由于一检测到冲突就立即中止发送，这时已经发出去的数据一定小于64B，因此，以太网规定最短有效长为64B，凡长度小于64B的帧都是由于冲突而异常中止的无效帧。
发送数据的站一旦发现发生碰撞时，除了立即停止发送数据外，还要继续发送若干比特的人为干扰信号，以便让所有用户都知道已经发生了碰撞。
3D游戏中的碰撞检测
碰撞检测在3D游戏中至关重要，好的碰撞检测要求人物在场景中可以平滑移动，遇到一定高度内的台阶可以自动上去，而过高的台阶则把人挡住，遇到斜率较小的斜坡可以上去，斜率过大则把人挡住，在各种前进方向被挡住的情况下都要尽可能地让人物沿合理的方向滑动而不是被迫停下。在满足这些要求的同时还要做到足够精确和稳定，防止人物在特殊情况下穿墙而掉出场景。
碰撞检测做得好了是应该的，不易被人注意到，因为这符合我们日常生活中的常识。做得差了却很容易让人发现，人物经常被卡住不能前进或者人物穿越了障碍。所以大部分人都觉得写碰撞检测代码是件吃力不讨好的事情，算法复杂、容易出bug、不容易出彩。下面还是回到正题，看看我们该如何解决这个难题。
早期3D游戏的碰撞检测多数基于格子或者BSP树，基于格子的系统实现简单但精度不够，不属于严格意义的3D碰撞检测。基于BSP树的碰撞检测一度十分流行，算法基本已经成熟定型，但它的固有缺点却使它不太适合游戏。BSP树需要很长的预处理时间不适合加载时计算，BSP划分经常会产生原多边形数三到四倍的多边形，考虑到不用保存法线、颜色、uv等信息也要增加将近一倍的资源容量，在一个大的游戏中将模型资源的容量从200M增加到400M相信是大部分人都不愿接受的。对于任意复杂三角形集合（mesh）的碰撞检测多数基于BVTree（bounding volume tree），具体可以是aabb tree，obb tree或者K-dop tree，这也是当今各种物理引擎和碰撞检测引擎流行的做法。
上面是碰撞检测按数据结构不同的分类，按检测方式又可以分为离散点的碰撞检测和连续碰撞检测（CCD continuous collision detection）。离散点的碰撞检测是指定某一时刻T的两个静态碰撞体，看它们之间是否交迭，如果没有交迭则返回它们最近点的距离，如果交迭则返回交迭深度，交迭方向等。连续碰撞检测则是分别指定在T1、T2两个时刻两个碰撞体的位置，看它们在由T1运动到T2时刻的过程中是否发生碰撞，如果碰撞则返回第一碰撞点的位置和法线。连续碰撞检测是最为自然的碰撞检测，可以大大方便碰撞响应逻辑的编写，可以很容易避免物体发生交迭或者穿越。离散点的碰撞检测则没有那么友好，当检测到碰撞时两个物体已经发生了交迭，如果其中有三角形网格对象那么已经有许多三角形发生了交迭，如何将两个交迭的对象分开并按合理的方式运动是一个挑战。虽然连续碰撞检测是最自然的方式，但它的实现非常复杂，运算开销也很大，所以大部分成熟的物理引擎和碰撞检测引擎还是采用了基于离散点的碰撞检测，为了避免物体交迭过深或者彼此穿越，大多都要采用比较小的模拟步长。
成功商业3D游戏普遍采用的碰撞检测是采用BSP树及包装盒方式。简单讲就是采用一个描述用的正方体或者球型体包裹住3D物体对象整体（或者是主要部分），之后根据“描述用”包装盒的距离、位置等信息来计算是否发生碰撞。
基于DELMIA的船舶三维设计碰撞检测分析
碰撞检测传感器简介