Collision

The most accurate collision check is to ray trace all polygons. Take every triangles edges of fist model and check if there is an intersection with triangle of second model (first with second). Then try second with first. It may hardly hit CPU :-(

Use D3DXIntersectTri() function to that.

Despite the occasional rumour about 'DirectPhysics' there is no physics or collision detection functionality in the DirectX suite - this thread is more appropriate for the 'Maths & Physics' forum. Moved [smile]

Cheers,
Jack

How you go about this all depends upon any restrictions you have placed upon the meshes. If you've restricted these meshes to be convex only then there are numerous techniques you can use such as' seperating axis thoerem' or 'gjk'. If there are no restrictions then you're dealing with colliding triangle soups. The brute force method is to collide every triangle in one mesh with every triangle of the other, however this becomes prohibitively expensive very quickly as your meshes get larger. Therefore people usualy use some sort of partitioning technique on the meshes such as octrees etc to speed up the test.

You should really be asking yourself before you go into any the above techniques though whether you really need that level of collision accuracy. First of all I recommend you look into approximating your physics objects with a collection of boxes and spheres and using the tests you already have. For example a car might be 3 boxes, and to collide 2 cars togther you'd test each box of one against each box of the other giving 9 box-box tests. Consider this to the alternative, for example say each car mesh is 50 tris, thats 2500 tri-tri tests you'd have to complete using a brute force method with tri soups. As you can see the decomposition method is much more efficient and is more often than not convincing enough to use for games. Most proffesional games use this technique and you've probably never even noticed the loss of accuracy.

When you've given it some thought just let us know if you need any further information about any of the above methods. Have fun

It may be that a hack like a normal texture type thing on a BB for calculating collisions/collision results from will provide you with realistic enough simulation (actually, that's a good idea! I'll have to use that!). Another idea is to have several smaller, tighter BB's inside the first to test against.

If you're serious about collisions with any shaped mesh, I'd use precalc'd grids keyed to triangle size (try for X triangles per gridpoint - find the best number empirically by recording number of checks in-simulation, etc), and maybe figure out which quadrants of your model intersect to save on checks. After that, as said above, test triangle candidates against each other for an intersection. It's only high school level algrebra, don't be afraid to pull out some paper!

Just remember that game physics is all about working out what assumptions you can make safely without degrading gameplay - not about absolute realism ;)

First of all, sry for wrong forum post [rolleyes]
then I want to thank you for all the answers.

So, here is my model, and the collision model:



But as you said, maybe it gets too expensive to check collision with it.
That's why I thought of first making a bounding box to check proximity. Then if its true, start collision tests with this collision model. But it may be expensive anyway, huh?

The first thing i thought was this one of dividing the model in boxes so I could easy the math. Maybe 3 boxes for a car. But then I saw that this model if divided by 3 boxes, would get a really accurate collision detection. Thats why I made the low model.

As you said here, directx has 3 functions:

Intesect, IntersectSubset and IntersectTri. From D3DX Mesh Functions. You also said that to check collision between any model, by brute force, will be expensive especially if the model has too many polys. There will be too many calculations. So if I use directx functions will be no difference? The math that directx behind the functions is that one (taking 2 polys 1 by one from each model and checking collision) ?

I though also this one: after checking collision between bounding boxes from each model, I get wich face of the BB collided and then limit the collision model polys for the test. For example, if a get a collision between the 2 bounding boxes from each car, and they return true in the front face, I limit the collision tests of the collision models to test only the polygons from the front of the car. Is that a good one?

Or maybe dividing the car in many small BB's still is the best option?

What do you think?

And thanks for the help so far.

Yeah, either small BBs, or spheres, or a simple CONVEX hull (your shape is not convex).

One problem with tri/tri collisions, is not the collision detection itself, but what to do with it. You will find maybe a 100 intersecions, but which way should you move the car to resolve the intersections? With convex volumes, it is a lot simpler, although not trivial either.

In fact I'd like a good collision math since the game will be a car simulator. Maybe if I reach a really good and not too expensive collision detection, I can try distorting the mesh when it crashes.

So any suggestions to the best way to reach and accurate collision math?
I thought a new thing: check the movement vector to see where the car is moving to and just check collision in the faces wich upper side vector is in the same direction of th movement, understand? Because if all the scenary is still and only the car is moving, nothing can hit the back of the car while is moving foward... unless another thing is moving too. But I'm still loking for accurate and not so expensive methods.

Any other suggestions?

thanks