• Create Account

## Is the GamaSutra collision article wrong or am I just being stupid?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

### #1Koobazaur  Members

866
Like
0Likes
Like

Posted 12 February 2013 - 08:02 AM

OK I've been butting my head for way too long now and just can't get past the idea that this article on AABB collision sweep algorithm is just wrong:

http://www.gamasutra.com/view/feature/131790/simple_intersection_tests_for_games.php?page=3

I implemented it with just one moving box (player) and whabam, I can't move cause I'm colliding with a box on the other end of the map. The heck? It seems to work only if we already know that the two boxes will overlap at the end of the movement.

Problem is with the for loop for each separating axis, which only sets values if the boxes are not overlapping on a given axis but moving towards each other. (A.max(i)<B.min(i) && v[i]<0) . What this effectively means is that if the boxes are either already overlapping or moving away from each on that axis, the algorithm will not modify the given u_0 and u_1, thus falsely claim collision is happening when it's not (since the final check is u0 <= u1).

Or am I just missing something really obvious here  . Tell me GameDev!

EDIT: Example case Box A min(0,0,0) max(0.5, 0.5, 0.5) and Box B min(1,0,1) max(1.5,0.5,1.5), displacement of A (0, 0, 0.6 ) . Only Z axis causes collision at "0.8" but since the other times don't get computed due to displacement being 0 on them, it reports it as collision.

Edited by Koobazaur, 12 February 2013 - 08:23 AM.

Comrade, Listen! The Glorious Commonwealth's first Airship has been compromised! Who is the saboteur? Who can be saved? Uncover what the passengers are hiding and write the grisly conclusion of its final hours in an open-ended, player-driven adventure. Dziekujemy! -- Karaski: What Goes Up...

### #2C0lumbo  Members

4074
Like
0Likes
Like

Posted 12 February 2013 - 09:57 AM

Yes, I think you're right. It needs to handle the case where v[i] == 0.0. When the velocity is zero on an axis it's not distinguishing between the constantly overlapping case (which it's defaulting to by initialising u_0 and u_1 the way it is, and the never overlapping case which could just early out by returning false.

I'd also spend a little time thinking about what happens when v[i] is very close to zero, is the algorithm going to produce dodgy results?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.