Jump to content

  • Log In with Google      Sign In   
  • 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.

  • You cannot reply to this topic
1 reply to this topic

#1 Koobazaur   Members   -  Reputation: 691

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 blink.png . 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.

Postmortem: one must die -  Political narrative-adventure game playing an Agent of Death who must take ONE life that could change the fate of a conflict-torn Nation

 

Check out my DevBlog for news on the next title!


Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2297

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.



PARTNERS