PDA

View Full Version : 3D collision detection



Firlefanz
07-09-2006, 10:17 AM
Hello,

my big problems right now are collision detection and pathfinding for my units in 3D.

Right now I am using one of Dans samples and enhanced it a bit.

My meshes are stored in a class that is based on a TList (here: Engine)

Bolmovable says if the mesh is allowed to move, nRadius if the XSize of the mesh/2.

Works good for some meshes, for others not.

I have some meshes that are not round (like houses) here only the 2D 'circles' are used.




function TForm1.boundcollide(spriteself: TDJXSprite): boolean;
var i: integer;
colSpr: TDJXSprite;
ColPt: TD3DXVector2;
tmpVec: TD3DXVector2;
newx,newz: single;
begin
//Collision with other sprites
//do not be alarmed by the complexity of the
//calculations, they are really simple
//once you take a closer look;)
for i:=0 to Engine.Count-1 do
begin
if &#40;Engine.Sprites&#91;i&#93;<>spriteself&#41; and
&#40;distance_dbl&#40;spriteself.x,spriteself.z,0,Engine.S prites&#91;i&#93;.X,Engine.Sprites&#91;i&#93;.Z,0&#41; < Innomsprite&#40;spriteself&#41;.nRadius+Innomsprite&#40;Engine .Sprites&#91;i&#93;&#41;.nRadius&#41;
then
begin
colSpr&#58;=Engine.Sprites&#91;i&#93;;
ColPt&#58;=D3DXVector2&#40;&#40;spriteself.X+colSpr.X&#41;/2,&#40;spriteself.z+colSpr.z&#41;/2&#41;;
tmpVec&#58;=D3DXVector2&#40;spriteself.X - colSpr.X,spriteself.z - colSpr.z&#41;;
D3DXVec2Normalize&#40;tmpVec, tmpVec&#41;;
if innomsprite&#40;spriteself&#41;.bolmovable then
begin
if innomsprite&#40;ColSpr&#41;.bolmovable then
begin
newx&#58;=ColPt.x + tmpVec.x * innomsprite&#40;spriteself&#41;.nRadius;
newz&#58;=ColPt.y + tmpVec.y * innomsprite&#40;spriteself&#41;.nRadius;
if &#40;spriteself.x<>newx&#41; or &#40;spriteself.z<>newz&#41; then result&#58;=true;
spriteself.x &#58;=newx;
spriteself.z &#58;=newz;
end
else
begin
spriteself.x &#58;= ColSpr.x + tmpVec.x * innomsprite&#40;ColSpr&#41;.nRadius + tmpVec.x * innomsprite&#40;spriteself&#41;.nRadius;
spriteself.z &#58;= ColSpr.z + tmpVec.y * innomsprite&#40;ColSpr&#41;.nRadius + tmpVec.y * innomsprite&#40;spriteself&#41;.nRadius;
end;
end;
if innomsprite&#40;ColSpr&#41;.bolmovable then
begin
if innomsprite&#40;spriteself&#41;.bolmovable then
begin
ColSpr.x &#58;= ColPt.x - tmpVec.x * innomsprite&#40;ColSpr&#41;.nRadius;
ColSpr.z &#58;= ColPt.y - tmpVec.y * innomsprite&#40;ColSpr&#41;.nRadius;
end
else
begin
ColSpr.x &#58;= spriteself.x - tmpVec.x * innomsprite&#40;spriteself&#41;.nRadius - tmpVec.x * innomsprite&#40;ColSpr&#41;.nRadius;
ColSpr.z &#58;= spriteself.z - tmpVec.y * innomsprite&#40;spriteself&#41;.nRadius - tmpVec.y * innomsprite&#40;ColSpr&#41;.nRadius;
end;
end;
end;
end;
end;


I guess to compare the meshes itself is too slow, so maybe if this collision returns true, it could check the meshes then or something? Or perhaps enhance it for rectangles also?

Does somebody have a good (and fast) solution for this matter?

Then pathfinding comes next. :wink:

Firle

Huehnerschaender
07-09-2006, 12:09 PM
For many many objects, rectangles and circles work good. You can let every object have more than one bounding box/cirlce, too.

Ok, the good approach is, test bounding boxes and if they collide do the exact collision detection (if needed, meshcollisiontest).

The test with bounding boxes is very fast and it indicates which objects are "near" each other. Objects which don't collide by bounding boxes, cannot collide by mesh. So only test mesh collision when bounding box collision occured. (box-box, box-circle etc).

Depending on how exact your collision detection has to be (depends on the game), you could either do real mesh collision or give you objects more than one bounding box (a plane for example can have 2 bounding boxes building a cross).

Thats all I can do right now... I have to go back to my IGF entry... tomorrow is deadline and I am not finished yet :)

Greetings,
Dirk

Firlefanz
07-09-2006, 12:38 PM
Thanks for the info. I'll google a bit, never did 3D collision detection before, first check if bounding box collides then if true check if meshes collide sounds useful. :wink:

Firle

NecroDOME
07-09-2006, 01:54 PM
Why don't you try newton game physics?

Firlefanz
07-09-2006, 02:01 PM
I heard of it. Is it easy to implement?
Is it free also for commercial use?

I am using DanJetX headers based on Clooties DX9 headers.

The Meshes are stored in an own Engine that is based on a TList.

Firle

NecroDOME
07-09-2006, 03:28 PM
Newton only returns the transformation matrix. From this matrix you can read the position and rotation of a mesh and transform your own.

The implementation is very easy. I use it within my own engine! My engine is based on Omega DX9, also using Clootie's headers.

Take a look at the newton site:
http://www.newtondynamics.com/

And here you can find the Delphi header for newton:
http://newton.delphigl.de/

Firlefanz
07-09-2006, 06:27 PM
Hi!

Thanks for the hint. I've already watched some demos long time ago.
I always thought this would be too hard to implement.

I'll download it and will be back next couple of days with a lot of questions I guess. Does it also include some pathfinding?

Firle

Firlefanz
07-09-2006, 06:48 PM
Hi!

Any samples/tutorials to get an easy start with Delphi?

Just want my meshes to move, rotate and have collision detection first, later pathfinding.

Later sword-fighting :)

Firle