collision detection on diagonal planes

Newbie & Debugging Questions
#1

im thinking about a proper way of adding to my arkanoid game some not only rectangle like bricks. so it should be possible (like in a flipper) to have diagonal collision, e.g. if a brick is hexagonal or turned with 30°.

the only way to do proper collision detection i see is to calculate (or perhaps better store) the normal of each side of the object.

i only want to go sure tehres no better way …

#2

in my demo of “destructible terrain” in the java2d forum, I was using the following method:

  • check for collision
  • normalize the speed vector
  • backtrace the trajectory until exact collision point found
  • do an approximation on the angle of the surface:
    calculate dy/dx of a small surface, like from collision point - 2 to collision point + 2. On cp + 2 and cp - 2, we always go up or down to find the exact surface point (up if inside object and down if outside object). this gives you the surface angle

I know this method isn’t perfect but worked great in our case. There could be some errors on extreme situations where you hit the edge of something.

#3

Asuming the ball is round, the collision normal is always (center of ball) - (exact point of collison between ball and wall).

But to get the point of collision you may need to store the normals of the bricks. Depends on how you do your collisions.

#4

im still in my planning phase, so some thought may be unfinished.
if all bricks were standard rectangles i needed only to test if the point on which the direction*speed vector is pointing lies within the bounding box.

now for the polygons. tom, you got a main problem:
even if i store all normales for each plane i additionally need to know the exact intersection point.
i only know one way to test this, to calculate the intersection of both lines (the one is the plane itself, the other is the line following the ball’s direction vector).
but line intersection is pretty expensive so i want to consider all possible methods before using them …

#5

[quote]im still in my planning phase, so some thought may be unfinished.
if all bricks were standard rectangles i needed only to test if the point on which the direction*speed vector is pointing lies within the bounding box.

now for the polygons. tom, you got a main problem:
even if i store all normales for each plane i additionally need to know the exact intersection point.
i only know one way to test this, to calculate the intersection of both lines (the one is the plane itself, the other is the line following the ball’s direction vector).
but line intersection is pretty expensive so i want to consider all possible methods before using them …
[/quote]
what about what I wrote ?

#6

ohhh, im very sorry, i overstepped your suggestion :o

but i didnt really get the clue. you have to explain it carefully.

  • check for collision:
    yes, thats the main problem. do you mean a precollision over bounding boxes ?

  • normalize the speed vector
    up to now i realize movement over an always normalized direction vector and a speed scalar

  • backtrace trajectory
    sure, but the question is, with which method ?
    for tracing the collision point (and later calculating the gradient of the small surface) i only see the method of line intersection

#7

In my destructible terrain demo, I use a collision map and check with the position of the object if it is a collision or not.

I hope this topic is about how to react physically to an object collidion with a vertical plane instead of being a “how to know if an object has collided” topic.

Because what I wrote was mainly how to react and not how to detect a collision.

#8

thats the pronlem. perhaps i did not mention it clearly, but i have never taken a collision map into view for arkanoid style game.
so i really have to widen the topic to, which is the probably best way to test ball to diagonal spheres collision.