Unity3D中使用mesh collider和box collider的区别

踩坑过程记录。
设备是HTC的VIVE 和 Unity 5.x
CPU: Intel Xeon Silver 4116 * 2
GPU: NVIDIA Quadro P6000
RAM: 64GB

这个问题是在解决项目卡顿问题的同时出现的：

最近在用U3D做一个VR项目，需求是要给网格加碰撞体以实现获取手柄射线与网格碰撞的具体坐标，利用坐标去计算后面所需要的数据，并且看起来只有加碰撞体这一条路可以走。

这个project实际上是在前期已经做好了AssetsBundle，通过和用户的交互，来动态加载网格的这样一个过程。一开始我在想给所有的mesh手动加碰撞体，直接框起来加collider，结果证明超级卡，直接卡着不动了。

在制作Bundle时加上Mesh Collider

开始决定在批量制作制作Prefab的时候加上碰撞体，然后再制作bundle。在代码上加了两句 X.AddComponent<MeshCollider();
X.GetComponent<MeshCollider().mesh = MESHNAME;
MESHNAME是对应的网格名称，对应相应的网格。做完bundle，并且替换完开始测试。结果实在是太夸张了，原来运行的时候加载网格一帧只要0.18秒左右，加完mesh collider后用Unity的profiler工具监测每一帧发现在加载的时候加载一帧需要2s…结果如下图。

可以看到每一帧渲染需要2s，不管是CPU GPU 还是Memory都直线飙升，观察Overview可以看到主要占用资源的是唤醒下一步的协程，一项项展开后发现是一个名叫 Mesh.Bake PhysX CollisionData 的进程占用了98.7%的资源。 Google后知道这个其实就是网格碰撞器渲染的进程，建议将Play Setting中的Prebake Collision Meshes勾上，从名字可以看出来这个选项的功能就是提前烘焙网格碰撞器。事实证明这也没有什么卵用。

这个时候我就在想应该怎么解决这个问题，前面和用户进行交互采用的方法是添加一个Canvas幕布加上元碰撞器box collider，在它下面生成一个图形子类或者是用Canvas Group with box collider。我就在想mesh collider和box collider使用起来有什么区别（或者是对于网格资源来讲应用这两个collider有什么区别），百度了一圈好像没有什么相关结果，于是去Google了一下。发现Mesh Collider和Box Collider差别还真的蛮大的。

在unity中网格是长这个样子的：

如果看不清的话放大以后是这样的：

可以发现网格其实是由一个个小的三角形拼出来的，这些小三角形就是网格的最基础的组成单位，而每一个mesh里面有大量的小三角形。在渲染Mesh Collider时需要对这些不规则形状的三角形进行大量计算，这些计算十分耗时。相对而言元碰撞器Box Collider就容易渲染很多。从元碰撞器的参数来看，有size和center，意味着这是一个规则的三维方块，相比起来规则图形的运算就会简单很多，所以就算是一个规则图形的网格碰撞器的渲染也会比原碰撞器慢很多。

所以要慎用 Mesh Collider！！！

在将MeshCollider改成BoxCollider后速度明显快了许多，又回到了之前没加碰撞器的加载速度，但是BoxCollider也不是完美的。将BoxCollider的参数center修改至贴合网格的位置，再将size的x和z改为255 y改为0（Mesh Size定义为255 * 255这样就完美贴合网格了，但是因为将y置成了0，这个BoxCollider就是一个255*255的平面，将视角换成x,y平面时就看不见碰撞器了。这意味着在不同的高度进行射线碰撞检测的时候会造成比较大的误差，并且这个误差是根据视角所在高度而改变的。视角越高，误差越小，同理视角越低，误差将无限增大。 这就是另一个问题了。

最简单解决这个问题的方法就是设置一定的视角限制，以进行误差控制。

其实还有一种方案就是根据不同的网格来动态设置BoxCollider的大小 x,y,z都动态传入参数，选择最适合网格模型的方块来定义BoxCollider，前提是网格模型的高度变化不是特别大。
这个方案也会有不小的误差，但是比前一种方案将会好很多。

两种碰撞器各有利弊：MeshCollider的精度非常高，但是渲染需要消耗巨大资源。
BoxCollider的误差随高度变化而变化，但是资源消耗极少。

所以在选择碰撞器的过程中还是要按照需求来选择最适合的方案。