View Full Version : MeshinMesh

21-03-2008, 06:07 AM

I need a function like MeshinMesh.

I want to know if two meshes collide. Perhaps first check the bounding boxes and the distance, and then checl the polygons or something.

I need it in 3D not 2D, I found a lot of stuff for 2D already.

Does anybody have already something like this? Or do I really have to use ODE or Newton, is this that complicated?


21-03-2008, 02:22 PM
Checking of two arbitrary meshes for collision is a quite complicated task. Even not any physics engine supports this. AFAIR Newton has polymesh colision support.

21-03-2008, 04:22 PM
... and I am sure you do NOT need this Eric :)

If you want to have it for the project I am thinking of then you definitely need a faster way to detect collisions. I guess games like Assassins Creed use this accurate collisions but a spaceshooter doesn't need it.

21-03-2008, 11:04 PM
You could also simplify your geometry and make spheres and boxes out of it. Checking those is a lot easier and faster. :) Flattening your collision-meshes to 2d (if possible) might also work.

I think in most cases this will give you satisfactory results. What kind of meshes are you using? Does your collision-checking really need to be THAT accurate ? :?

OFFTOPIC: Yeeha: Word lord now! :D

22-03-2008, 12:57 PM
Testing sphere collision is faster than boxes (for the very first check). You don't need sqrt() call at all if you power 2 the radius too :)

After that the detailed collision which could be each triangle, model defined as a shape or numerous smaller shapes...

22-03-2008, 02:25 PM
maybe this can help...

is working 100% here...


24-03-2008, 04:46 PM
Hi @all

how do you control the demo?
I am only moving the camera right now...

yes, this is for a spaceshooter, exactly.
I already have a collision check with sphere, but I find it not good enough.
I hoped to check the sphere first, and if that spheres collide do another check with the mesh or maybe the mesh simplified or something...


24-03-2008, 05:24 PM
how do you control the demo?
I am only moving the camera right now...

numpad 4,8,6,2

24-03-2008, 10:04 PM
Your demo does not work properly. When I move the right box so that it is behind the left box and then move "down", the box collides before it really hits the other box.

It is much faster if you attach a few invisible collision boxes to the models than testing Mesh2Mesh collision.

For example, if you have an airplane-like model you can easily use two boxes which are overlapping like a cross. This is much more accurate than a bounding box or sphere and is nearly as fast as bounding box-collisions. Think about it. You can "build" nearly every shape out of such simple constructs and use this for collisionchecks.

25-03-2008, 01:10 PM
Hmmm. I think this stuff with multiple collision boxes is the best idea until now.

Seems like I need some editor to load my model, then display and change and save 3 boxes or something, and in the engine when one box collides, I have a collision. Sounds good...and fast. :D

Just some additional new work with that editor then but that would be okay. Thanks for the clue Dirk. :wink:

26-03-2008, 11:41 AM

just a quick question to have a start:

Do you think it is more efficient to 1 or 2?

1) When a single Item is moved, check collision of this item only with all others. Do this each time a single item is moved

2) move all items one time. then check each item against each other item.

In my old spaceshooters made with DelphiX/Omega there was already a collision detection worked like 1.

I hoped this was easy to understand. What would you prefer?


26-03-2008, 03:58 PM
You need to check on every movement.

Otherwise the following could happen:

Object A and B are close to each other.

You move A in direction of B. They now collide but you do not test.
You move B in direction of A.
You move all other objects (not of interest here)
What to do now? You check collisions and your result is: A + B collide. But how do you know how far you need to move A and B in which direction to seperate them again?

You see the problem?

26-03-2008, 05:40 PM
Good argument, thanks :)

27-03-2008, 04:11 AM
Checking collisions on every move will kill performance later or sooner.
Usally the collsision test cycle looks like this:

for i1 := 0 to ItemsCount-1 do for i2 := i1+1 to ItemsCount-1 do CheckCollision(i1, i2);
CheckCollision(i1, i2) checks for collision between item with index i1 and item with index i2.

Or you can use an engine which supports collision checking and may be even response.

27-03-2008, 07:03 AM
The amount of collisionchecks should of couse be reduced to items that are near the checking entity.

Usually I "tile" my maps virtually in areas and in the update of the objects I only check entitys that are in the area of the checking entity, or in the bordering areas (to be sure you get the collisions when moving from one area to another).

In large levels this minimizes the collision checks.

There my be better ways but thats how I usually do it... and for a project like a space shooter this should be enough to keep performance up.

I mean, if there are 50 objects to check, this should not kill performance, especially if Eric does not use MeshInMesh collisions but some more abstract method like I suggested...