Vectors and Reflection - Ball bouncing messed up by simultaneous collisions?

Game Mechanics
#1

Evening

I’m trying to tidy up and make my first attempted game actually fun. In doing so I’ve found myself delving into vectors, which are fairly new to me so bear with me, and I’m having a few problems. I think I have a ball bouncing off of a rectangle successfully.

My problem occurs when the ball collides with two, or more, rectangles at the same time. Usually this happens when the ball hits between two rectangles which is a fairly frequent occurrence as I’m dealing with a grid of blocks in a Breakout clone. I’ll try a diagram to make what I mean clearer:

| | |
| | |

                                                     ^
                                            Ball hits here.

You can see my code for this here https://github.com/danieldean/Bounce/blob/master/src/me/danieldean/demo/bounce/Ball.java, see methods ‘colliding’ and ‘bounce’. There is also a demo I’ve compiled if you don’t want to do it to try for yourself https://github.com/danieldean/Bounce/releases. Drag the ball by holding the mouse to get it to collide between the two rectangles.

If anyone has any suggestions I’d be grateful. So far my consideration is to combine the blocks into one rectangle and collide with that on the fly which seems wasteful and doesn’t solve when a collision occurs with an ‘L’ of blocks. I work out what blocks to collide with in the actual game by grid positioning.

Thanks

#2

i hear you. got exactly the same problem (i guess tho’) … just cannot get my head around it. i know the solution is simple, once known.

particles bouncing and colliding with more then one obstacle, in that case a two lines connected by a sharp angle, then bleeding through cos’ of bad intersection testing :

from a glance at your code, which looks good … i think what’s going on is : it happens that the first intersection and constraint moves the affected object into a spot that makes the following intersection-test go kaputt. might pile up to a decent stack of crap after a couple intersections. now that does not help you :wink:

#3

Yes, when I wrote the code I was working on the hope that the two corner collisions would ‘cancel’ out into one side collision. I was misguided! :cranky:

Another consideration is to make the grid of blocks a polygon from the balls perspective so they would not be separate for the collision but still make them separate inside the grid so they could be destroyed. Again each time a block is hit I’d need to create a new polygon and this introduces more complex reflection which I don’t think I need.

#4

yea, need is a strong word :slight_smile:

you mean like, projecting obstacles into local-coords of the object simulated ? i’ve read that is a common way; makes the math easier.

#5

Process only one object at a time. Move it, check for collisions, move it back if necessary. Make sure the game is in a valid state at the end of that process i.e. nothing overlaps. Only then go on to the next object.

#6

“many objects” like many simulated objects or obstacle objects ? i’m probably totally off anyway, but the trouble occurs already with a single object simulated.

“going back”. that sounds like it must work but would break velocity continuity. what about “reflecting” :

we do not move back but “advance”. zero-overlap contraint in danieldean’s case or reflect at intersection, advance by length of penetration, in my case. simulation state is not broken at this point, but creates an undesired one.

maybe calculating the “time of impact”, TOI like box2D calls it, would help.

  • advance simulation to impact -> update forces/cap velocities but do not change object position -> advance simulation with TOI again.

sort of recursive approach. looks too heavy for such “small task” to me, but maybe that’s the way to handle this. is it ?

maybe we approach it from the wrong side. we both do contraint/intersections into the “past” : correct the state after it became broken. maybe we should look ahead of time.

#7

I’ve reverted my demo to check for only one collision per moving object per tick which instantly solves this but I’m not sure if there will be an repercussions from this. Now to try in the game…

#8

The repercussion is that you can push the particle farther and farther through/beyond the line you’re also meant to collide against.

Imagine a corridor that is too narrow to move through. With your approach you’ll move through the corridor.

#9

Yes, I thought this could be the case and as I tried it I soon realised. :frowning: It simply delays the hits, which should occur together, until the next tick or misses one of them entirely. If the ball hits in the corner of an ‘L’ of blocks it’ll actually get stuck in one of the blocks.

If I use very high ticks, as the demo does, this works okay but ideally this game shouldn’t eat the CPU.

I thought I’d be over this part by now and onto simulating the paddle having a convex face. Now I’m not looking forward to that…

#10

One approach to this problem is to detect it, and re-run the simulation for that particle at a higher rate - meaning: running it, say, 10 times within the current tick, with delta-time reduced by factor 10.

#11

Yes that sounds like it could help a lot as opposed to running at a consistently high rate.

I’ve changed my collision detection so that it predicts a collision by replacing all ‘x’ and ‘y’ for the ball with ‘x + vx’ and ‘y + vy’ and it does yield better results at much lower rates. I’ll see if I can improve on that if not I’ll make it step though until collision as you’ve suggested.

#12

It’s not a trivial solution, but the one which I used for Torquing! is from Complementarity based multiple point collision resolution, Giang, Bradshaw, and O’Sullivan, Eurographics Ireland Workshop, pp1 - 7, 2003, available online at http://www.tara.tcd.ie/bitstream/2262/18699/1/GiangEgirl03.pdf

#13

Thanks for this, I’ve started reading it through and attempting to understand it. :slight_smile: I’m well aware it’s not a trivial solution. I’ve only been taught the basics of vectors and I’m beginning to feel I’ve bitten off more than I can chew but I’m sure given some time and brushing up on my maths I can get it.

For some reason I feel that, after having read some of it, I could take all of the unit vectors from my collided methods, add them together and then convert the resulting vector back to a unit vector to get the balls direction. To do so I’d have to change my bounce method to accept an array. I’m sure there’s an obvious pitfall to this but is it plausible?

#14

it works to some degree.

summing all final states of all collisions works 99% … pitfall is i have to avoid extrem conditions.
conditions like bad angles :

summing at the bottom left corner can result in a point outside valid area. :clue:

#15

I’ve just tried this. It seemed to produce result then the ball went straight between my two test rectangles and came out the other side. I’m going to try combining the contact points to make one normal and thus one ‘bounce’ now as suggested in the paper pjt33 provided.