Sign in to follow this  

Deciding the right direction

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

To put it simply - I wanted to make a brick that turns the ball 90 degrees. But not just alwayr right/left or randomly. No. I don't want it to bounce INTO the brick. Look at this picture: The dark gray is of course brick. White ball is the ball, white line is the Ball movement vector. Red line indicates two possible ways the ball go bounce, and the one with red ball at the end is the way the ball should go. So the ball bounces by 90 degrees so that it WON'T try to move INTO the brick. And if it hits the corner, it changes the direction so that it tries to be Horizontally closer to the ball position before moving and intersecting. I think I could do it with amazing amount of IFs but it is ineffective I think. So the data I have is Brick Position vector [bPos], Brick dimensions [25x35], Ball position Vector (Sitting in the position of intersection) [bPos], Ball Movement vector [Move], and, if needed, Closest Point on Brick as vector [bClos]. Can it be done in some reasonable way?

Share this post


Link to post
Share on other sites
I think you should remove the rule that the ball tries to move to be horizontally closer to the original ball position, when the ball hits a brick corner. I prefer an approach that doesn't have to worry about corners at all, and in your case I believe there is a very clean approach to this...

To do the collision response without a lot of logic/IF statements, you need to have a contact normal also. When you have concave shapes, it can be tricky to find the contact normal. But, you have two convex shapes, a brick/box and a circle. Though it is convex, the brick shape is also a problem, since at the corners there are two surfaces, one vertical and one horizontal, and you would need to have a rule to choose which normal to use. But, the ball is a circle and so the normal is unique at each point on the circumference. In your case, treat the ball as a circle with a radius (not just a point) and use the ball's surface normal vector at the contact point as your contact normal. The surface normal is simply the unit vector parallel to a line from the center of the ball to the point that touched the brick. Pretty easy. That normal will help you decide which direction to turn without much trouble or logic.

So, given the contact normal and the movement direction (which is similar to a velocity), you can pick a direction to turn. The traditional approach to bounce a ball off a wall is to reflect the movement direction/velocity about the axis defined by the contact normal and reverse the component parallel to the normal. (This is like the real-world if you ignore gravity and friction and ball deformation.) If the velocity is parallel to the contact normal, the ball just bounces straight back where it came from. There is no logic at all needed, just one math formula. In your case, given the 90 degree turn requirement, the simple rule would be:


PD = PerpDot(movement direction, contact normal);
if PD is nearly zero
{
rotate +90.0 degrees
// could also rotate -90.0 degrees. Doesn't matter in this case
}
else
{
Otherwise, rotate sign(PD) * 90 degrees, where sign is + or - 1.0
// may need to use -sign(PD) depending on your implementation.
}


Er, PerpDot is the perpendicular dot product, defined in 2D, which is the dot product with a vector perpendicular to the first input vector, so PerpDot(A, N) is the same as Dot(A rotated by 90 degrees, N).

Dot Product Fun (with description of perpendicular dot product (a very nice presentation)

So, I think that'll work in your case. It is taking advantage of the characteristics of convex geometry and will only work well if your ball shapes have a nonzero radius so you can find a contact point that is different than the center of the ball (there are some nice things that happen when two convex shapes collide, which enables you to use the contact normal from the ball). Also, if you add some concave shapes things will be more complicated. Note that if you have two bricks next to each other forming an "inside" corner....that inside corner is concave and that is a bit trickier...

Hope that helps!

[Edited by - grhodes_at_work on June 27, 2008 9:57:03 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by grhodes_at_work
I think you should remove the rule that the ball tries to move to be horizontally closer to the original ball position, when the ball hits a brick corner. I prefer an approach that doesn't have to worry about corners at all, and in your case I believe there is a very clean approach to this...


Indeed, that's a better approach.

*looks up meaning of Concave and Convex in dictionary* Ah right, how could I even forget that. Anyway, I think I can see it working. At least it isn't as difficult as implementing Capsule-Ray intersection tests, and writing RayTracing five times in a row (and then realize RayTracing is just wrong approach to the problem) :P.

Thanks very much, I will test if I can make it work tomorrow (As today is almost tomorrow already).

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this