Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Vectors and Reflection - Ball bouncing messed up by simultaneous collisions?  (Read 1116 times)
0 Members and 1 Guest are viewing this topic.
Offline danieldean

Senior Member


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
Online basil_
« 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 Wink
Offline danieldean

Senior Member


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!  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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online basil_
« Reply #3 - Posted 2014-07-15 19:50:11 »

yea, need is a strong word Smiley

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

Senior Member


Medals: 15



« 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.
Online basil_
« 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.
Offline danieldean

Senior Member


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...
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« 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
Offline danieldean

Senior Member


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.  Sad 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...
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 801
Projects: 4
Exp: 16 years


Hand over your head.


« 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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline danieldean

Senior Member


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.
Offline pjt33
« 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
Offline danieldean

Senior Member


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.  Smiley 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?
Online basil_
« 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.
conditions like bad angles :

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

Senior Member


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  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (44 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (40 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!