Advertisement

collision detection

Started by February 11, 2002 11:01 AM
4 comments, last by Crispy 23 years ago
hey, i''ve read several tutes on CD, each of them dealing with ray-to-plane, sphere-to-plane etc kind of CD, but none of them actually showing how to test collision between, for example, a sphere and an object compiled into a build list. i have objects of arbitrary shapes, but how can i extract the normals of the polys from the compiled pieces? then again, are build lists the best/most efficient way to do things? thanks, crispy
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared
Testing every polygon in your models for a colision is going to be very slow. Box/Cylinder/Sphere testing is usually good enough. If you really want to test you''re models shape, create a very low poly model of the basic shape of what ever it is and test against that.

Using lists is an easy way to draw the same thing over and over again. If you are going to be calculating data from the objects in realtime, then lists may not be the best idea. You probably want to create the list with the object on the origin, then in your program, translate it to the position you want it. You can use what you translated it by compaired to what your checking against to do simple Box if(x1 > x2 && x1 < x2+length . . . ) , Cylinder if(y1 > y2 && y1 < y2+width && sqrt((x1-x2)*(x1-x2)+(z1-z2)*(z1-z2)) < radius) , or Sphere if(sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2)+(z1-z2)*(z1-z2)) < radius) collision tests.

I''m not very good with the more complex stuff, so I''m not going to try, but I hope that is enough to help you.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.
Advertisement
Crispy : complexity of collision detection depend on what you want to do.
If you''re going to make a physics engine for real-time rendering (a game for instance), you gotta listen to smart_idiot''s advice.
But if you need more accurate collision detection, there exist other methods that can do it. But they''re not gonna be used in "real-time".
I know that if you take a line that passes through the outside of the model to a point inside of it you want to test against, if the number of polygons it itersects is odd, there is a collision. I just don''t know the math behind it. That only works if polygons cover the entire surface of the model and if none of the polygons occupy the same space.

This also works in 2D using lines.

Still, the other stuff is good enough, I think.
Chess is played by three people. Two people play the game; the third provides moral support for the pawns. The object of the game is to kill your opponent by flinging captured pieces at his head. Since the only piece that can be killed is a pawn, the two armies agree to meet in a pawn-infested area (or even a pawn shop) and kill as many pawns as possible in the crossfire. If the game goes on for an hour, one player may legally attempt to gouge out the other player's eyes with his King.
hey,

i'm building a game and the number of objects that i want to test collision with can be narrowed down quite a bit, so there isn't much strain in that on the cpu. moreover, the "models" as you call them (i'm not sure if this term is correct here - they're just simple meshes built of a few polys) won't be very detailed. the number of them on the screen at any given time, however, can become quite big (i'd guess somewhere around 100) plus they'd have to be well optimized for both collision detection AND drawing as the game is generally meant to run quite fast (which means no jumps in framerate) and precision is quite an issue. that's mainly why i'm trying to avoid CD with spheres or cylinders - it might prove to be insufficient. the game scene is never more than app. 1.5 * screen width, therefore mobility within that region would in my guess have to be well optimized. and this includes collision detection.
smart_idiot: how many polys is a "low poly model"?
vincoof: i'm pretty much a beginner in 3D, so unless these techniques are very complex, could you name a few of them

thanks anyway, guys


oops, misspelled you vincoof. sowwy


Edited by - crispy on February 11, 2002 3:53:58 PM
"Literally, it means that Bob is everything you can think of, but not dead; i.e., Bob is a purple-spotted, yellow-striped bumblebee/dragon/pterodactyl hybrid with a voracious addiction to Twix candy bars, but not dead."- kSquared
But the problem is there does not exist a generic solution for collision detection.
If you want to detect when a ball bounces on a wall, it is radically different than testing if a car pushes another car.
It depends on the type of collision information you look for (impact point ? direction of repulsion ? force of collision ?), it depends on the precision you need, and maybe other stuff depending on what you need.

But in most cases, you can deal with cylinder/spheres/planes collisions. For instance, if you want to collide a human body with a ball, the ball can be respresented as a sphere and the human body can be represented as a conjunction of cylinders.

Hope this helps.

This topic is closed to new replies.

Advertisement