it may be obvious, but a (axis aligned) bounding box intersection before the mesh intersection can speed up the process quite a lot.
In case - the proper aabb intersection here (2d, but easy to extend)

bool BoxesIntersect(BoundingBox a, BoundingBox b) {
if (a.Max.X < b.Min.X) return false; // a is left of b
if (a.Min.X > b.Max.X) return false; // a is right of b
if (a.Max.Y < b.Min.Y) return false; // a is above b
if (a.Min.Y > b.Max.Y) return false; // a is below b
return true; // boxes overlap
}

Are you sure your meshes are seperated more than the distance you specified? You probably want a very, very small distance. But note that such a value still can cause clashes to happen for non-intersecting meshesâ€¦

Indeed this is a good suggestion by @atair. Checking for a boundingbox overlap first will make your isearch faster as it discards sets that are not close to eachother. However, if you know the meshes will be close to begin with itâ€™s a pointless additional check.
-WIllem

bounding box intersection is meant as an early discard of intersection pairs, so yes - first bbox and then normal collision. This can speed up the process orders of magnitude, but only if you are dealing with many meshes. If it is just about two, it wont helpâ€¦

Another optimisation that is often used are convex mesh collisions (e.g. in realtime physics engines). Unfortunately Rhino has them not implemented.

If you supply more information on your problem (number of meshes in question, distribution and average vertex count, maybe we can give you better advice

But then wondering how to speed up this collision detection below instead of using mesh fast intersection.
Any ideas would be much appreciated. I am seaching in rtee by distance of one element diagonal length:

foreach (int m in _rtreeId) {
if (!(p == id[m].Item1 && (i - 1) == id[m].Item2 && j == id[m].Item3)) { //if not current
Line[] array = Rhino.Geometry.Intersect.Intersection.MeshMeshFast(t.Geometry, manyTiles[id[m].Item1][id[m].Item2][id[m].Item3].Geometry);
if (array != null && array.Length > 0) { //here I break the loop if at least one intersection is found
flag = false;
break;
} // if
}
}

I mainly working with this kind of geometry below or similar:

Hi
My expirience tells me that MeshMeshFast() is fast.
I used to solve some similar problems and applied same technic to yours - mesh/mesh collision detection, my sollution is attached in cs file.
I use RTree to find all meshes whose boundingBoxes intersesct and only these meshes I check for cillision by MeshMeshFast() method. Hope that this helps.

Hi @dale
But would checking if the bounding boxes of these meshes collide before doing any MeshMeshFast function calls improve the performance or does this happen internally in MeshMeshFast anyways? (I mean this idea is so simpleâ€¦ I guess you did a lot more to improve performance.)
The question is, should I invest time in trying to optimize this or is it a waste of time?

As i was the one that proposed the box thing, i just ran a test with 1k to 4k objects, and 8 to 32k Vertices.
The Boundingbox test speeds it up by about the factor of 4, when used in a c# GH component, maybe more when compiled.

So the speedup much less than i suggested - the native intersection is already fast.

â€¦using some kind of octree / KD-tree would be the next thingâ€¦