Java-Gaming.org Hi !
 Featured games (91) games approved by the League of Dukes Games in Showcase (757) Games in Android Showcase (229) games submitted by our members Games in WIP (844) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 Vectors and Reflection - Ball bouncing messed up by simultaneous collisions?  (Read 8671 times) 0 Members and 1 Guest are viewing this topic.
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Posted 2014-07-15 18:54:28 »

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
basil_

« JGO Bitwise Duke »

Medals: 418
Exp: 13 years

 « Reply #1 - Posted 2014-07-15 19:35:53 »

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
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Reply #2 - Posted 2014-07-15 19:44:58 »

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!

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.
basil_

« JGO Bitwise Duke »

Medals: 418
Exp: 13 years

 « Reply #3 - Posted 2014-07-15 19:50:11 »

yea, need is a strong word

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

JGO Coder

Medals: 21

 « Reply #4 - Posted 2014-07-16 00:45:59 »

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.
basil_

« JGO Bitwise Duke »

Medals: 418
Exp: 13 years

 « Reply #5 - Posted 2014-07-16 09:18:03 »

"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.
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Reply #6 - Posted 2014-07-16 09:20:08 »

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...
Riven

« JGO Overlord »

Medals: 1340
Projects: 4
Exp: 16 years

 « Reply #7 - Posted 2014-07-16 10:43:30 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Reply #8 - Posted 2014-07-16 12:20:35 »

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

Yes, I thought this could be the case and as I tried it I soon realised.  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...
Riven

« JGO Overlord »

Medals: 1340
Projects: 4
Exp: 16 years

 « Reply #9 - Posted 2014-07-16 12:23:42 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Reply #10 - Posted 2014-07-16 14:05:23 »

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.
pjt33

« JGO Spiffy Duke »

Medals: 40
Projects: 4
Exp: 7 years

 « Reply #11 - Posted 2014-07-16 14:35:04 »

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
danieldean

Senior Devvie

Medals: 5
Projects: 1

 « Reply #12 - Posted 2014-07-18 20:58:36 »

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

Thanks for this, I've started reading it through and attempting to understand it.  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?
basil_

« JGO Bitwise Duke »

Medals: 418
Exp: 13 years

 « Reply #13 - Posted 2014-07-18 21:34:14 »

it works to some degree.

summing all final states of all collisions works 99% .. pitfall is i have to avoid extrem conditions.

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

Senior Devvie

Medals: 5
Projects: 1

 « Reply #14 - Posted 2014-07-19 12:02:13 »

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.
Pages: [1]
 ignore  |  Print

 EgonOlsen (74 views) 2018-06-10 19:43:48 EgonOlsen (55 views) 2018-06-10 19:43:44 EgonOlsen (74 views) 2018-06-10 19:43:20 DesertCoockie (254 views) 2018-05-13 18:23:11 nelsongames (154 views) 2018-04-24 18:15:36 nelsongames (154 views) 2018-04-24 18:14:32 ivj94 (895 views) 2018-03-24 14:47:39 ivj94 (156 views) 2018-03-24 14:46:31 ivj94 (808 views) 2018-03-24 14:43:53 Solater (172 views) 2018-03-17 05:04:08
 Java Gaming Resourcesby philfrei2017-12-05 19:38:37Java Gaming Resourcesby philfrei2017-12-05 19:37:39Java Gaming Resourcesby philfrei2017-12-05 19:36:10Java Gaming Resourcesby philfrei2017-12-05 19:33:10List of Learning Resourcesby elect2017-03-13 14:05:44List of Learning Resourcesby elect2017-03-13 14:04:45SF/X Librariesby philfrei2017-03-02 08:45:19SF/X Librariesby philfrei2017-03-02 08:44:05
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org