I have an idea for all you newbies trying to make collision detection work. First, type this define in: #define DIST(x1,y1,z1,x2,y2,z2)(sqrt(((x2 - x1) * (x2 - x1)) + ((y2 - y1) * (y2 - y1)) + ((z2 - z1) * (z2 - z1)))) Then, for every object get the center point and "radius" {how big around the object is) To find out if two objects are colliding run this: if( DIST(obj1.x,obj1.y,obj1.z,obj2.x,obj2.y,obj2.z) < (obj1.radius + obj2.radius) ) { // run collision event } That should give you a rough idea if two objects ar colliding. That help anyone? ----------------------------- Blue*Omega (Insert Witty Quote Here)

You might want to note that this doesn''t work for things that are oblong and only works for things that have equal dimensions. Otherwise you''re hit-testing a larger (or smaller) area then you wanted to test.

S.

you know, making the distance formula a macro never occured to me (seriously); thanks. and Strylinys is right, but this would be a good way to test if the objects might have collided, and if so you may want to do a more accurate (and processor consuming) test.

<(o)>

Checking a rectangle around your figure that has it''s max x, y, and z dimensions isn''t exactly processor consuming, so you should probably use that instead of a sphere.

S.

i recommend a bounding sphere test first to get rid of all objects in the scene that are not colliders, its quicker than a box

you could try this:

#define SQR(x) ((x)*(x))

if(SQR(obj1.x-obj2.x)+SQR(obj1.y-obj2.y)+SQR(obj1.z-obj2.z){
checkforexactcollisionperpoligon(obj1,obj2);
}
else
{
nocolision
}

so you don''t have a sqrt, which is very time-consuming

Yes, I realize a box would work better than a sphere for 99.9% of all collision detection needs. I''m just trying to help anyone getting STARTED on collision detection so that they have somthing to build on. *sigh* If you already know this stuff pay my post no mind, if you''re looking for this info then I hope I helped.


-----------------------------

Blue*Omega

(Insert Witty Quote Here)

Spherical fences are good first tests since objects can be rotated without having to rotate the fence.

Your idea is right On Omega.

Consider this. Every game needs diffrering hit collision needs. For an FPS omega''s solution is ideal. It''s rougly 1 check for collision. however for a fighting game, it''s not the best.

Now, the problem lies in the "radius" However this can be easily solved.
When I load a model, I log the distance from it''s center, to the vertex i''m loading. However, I only do a distance check on the
x & z axis Meaning we''re getting a 2d overhead view of the model, thus, getting a correct and accurate description of the "radius".
Once you have the radius, You can also get the height of the object, which upon, you can create a bounding cylindar. Which, if you do your math checks gentlemen, requires 2 checks, rather than a bounding box (plane checks:6 or vert checks: 8) and it''s more effecient than a bounding sphere (1 check) So if anything it''s the best of both worlds.
Quite frankly, I use the bounding cylindar in everything. I''ve yet to find a method where it''s NOT practical, OR useful.

I''ve got all this and a huge collision article over at my website
www.sinewave.net
Still needs to be uploaded with the demo though

~Main
==
Colt "MainRoach" McAnlis
BadHeat Inc.

dude, thanks.