Archived

This topic is now archived and is closed to further replies.

Collision detection - what's so difficult?

This topic is 5293 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hi! I''ve seen in the tutorial request topic that many people want a tutorial on collision detection. But I think collision isn''t too hard. Imagine you have a brush (a closed 3d object with several polys), for example a cylinder. Now you just calculate the plane for every polygon of your brush. Your plane has 4 paramters: A, B, C, D A, B and C are the components of the plane''s normal, D is the distance of the plane along this normal. You want to check now, if a player in a 3d shooter is walking into this brush. That''s really simple now: The player has a bounding sphere. The center of this sphere is just the player''s position. Then you need to define a radius for the sphere which describes the player''s size. Ok, now you simply check the distance of the sphere''s center to every plane by calculating: d = A*sx + B*sy + C*sz + D If the distance to any of the planes is < -radius then the sphere is colliding with the brush. Hope that helps you cu

Share on other sites
Yes, it is simple if you use a brute-force method and collision spheres. The difficult part is implementing real-time polygon-accurate collision, which returns the collision point for the physics simulation.

-Jussi

Share on other sites
Yes, might be that''s brute force, but it works. And even Quake 3 uses this technique. If you want a ray-poly collision detection
then please look at the new topic I''ve posted.

cu

Share on other sites
hi,
i''ve tried months ago to implement a collision detection based on a sphere-plane collision, but i ran into a big problem : the formula d=Ax+By+Cz+D is the formula of an infinite plane... and poly are not infinite plane. How do you perform this test?!!
btw i prefer bounding boxes because you can easily make a hierarchical tree with acurate collision. For example let''s take a group of monsters. Those monsters have bodies : they have heads, chests, arms and legs. First perform a test for the whole group. If we detect a collision, perform a test for each monster. For the first we detect the collision, perform the test for each part of his body.
This method is easy to implement, fast and enough acurate for games (but not for medical simulation )
lunasol

Share on other sites
quote:
Original post by LaBasX2
Yes, might be that''s brute force, but it works. And even Quake 3 uses this technique.

Well, where did you hear that one from?

-Jussi

Share on other sites
Hi!

If you look at the q3 bsp file structure you can find a lump
called brushes (check out www.planetquake.com/aftershock). These brushes contain a list of planes. When I coded a little q3 map viewer I tried to handle the brushes as I described in my first
post. And it worked perfectly, even for curved surfaces. So that''s why I think (well, actually I''m quite sure) that q3 uses
this technique. Furthermore I''ve seen several quake2 viewers which use brushes in the same way.

cu
LaBasX2

Share on other sites
hi lunasol,

I''ve read your question. In fact, planes are infinite. That''s why you have to use brushes. A brush is an object and it needs
to be closed, that means you can''t look into the object from
outside. This object consists of planes. And I guess you know,
when 2 planes are not coplanar, they will intersect. If you take
all the intersections of the planes defining a brush, you can find an object. The intersection points of the planes are the vertices used to convert a brush to polygons. So you can make
a limited objet out of a set of infinite planes. And that''s why
the collision test works.
Well, that''s a little difficult to explain so excuse me if I can''t help you more.

cu

Share on other sites
Unless you are doing something more than calculating the distance of the sphere to the planes, your technique does NOT work.
You have to take into account the real boundaries of the polygons, and not just their planes.

Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

Share on other sites
Well I don''t know why this technique shouldn''t work. I''ve read about it in several tutorials and as I mentioned quake2 and
quake3 are using it, too. I think that''s the fastest and best
way of checking if the player runs into a wall. Checking every polygon for a ray-collision is much too slow. I tried it in one of my engines and it costed me some frames! And why do you think are precalculations of lightmaps so slow? It''s just because of these damn slow ray-tri intersection tests, I got to know that when writing a lightmap compiler. Disabling the test speeds it up a hundred times.

So what do you think doesn''t work? All I can say is that I tried it and for me it worked. I was walking through a quake3 level with my viewer and using the brush technique I didn''t manage to walk into any wall! So if you have a better and faster way of collision detection, tell me.

cu

Share on other sites
the thing is we should call it like it is and thats collision + response. its no good knowing youve collided without knowiung what u have to do afterwards

1. 1
Rutin
46
2. 2
3. 3
4. 4
5. 5

• 13
• 10
• 12
• 10
• 13
• Forum Statistics

• Total Topics
632993
• Total Posts
3009762
• Who's Online (See full list)

There are no registered users currently online

×