Jump to content

  • Log In with Google      Sign In   
  • Create Account


celloe

Member Since 21 Jan 2011
Offline Last Active Apr 07 2014 05:11 PM

#5066406 Swept AABB collisions and the crack problem

Posted by celloe on 31 May 2013 - 07:24 AM

@ LorenzoGatti That was my instinct, too, which made me wonder as to the specifics of my implementation, and where I'd.. gotten it wrong. With constant forces such as the mouse joint, it would bounce off on an initial swing (if the response was made elastic) then sink straight through. Is it to do with the ordering of resolving collisions, applying outside forces / impulses, and the integration itself?

 

@Krohm I understand your point fully about tools and libraries already existing to tackle this problem (box2d suffers from this also, you have to use edge chains I believe for static objects in sequence). However I do also view this as a learning experience and I value the process of solving the problem. I don't have a tight deadline or anything, I quite enjoy getting lost in the intricacies of physical simulation!

 

The main issue I have at this point is that I've seen from SacredSoftware's implementation that it is possible to get a more general solution, through the use of sorting collision priority based on which collision has a greater surface area of penetration in a given timeslice (or rather, time step with a threshold, as of course CCD would only really solve one at a time so you have to step forward and test a little). What puzzles me is the two facts that a) It does not function correctly without positional correction, and b) It gets stuck on an edge even in the case of a single box. I suppose if it's correcting it to the EXACT edge position, when it moves back down it would maybe get snagged on a corner? But is that correct behaviour?.. It's not common to many others, which makes me think the penetration resolution isn't quite correct, in terms of initial contact times.




#5066262 Swept AABB collisions and the crack problem

Posted by celloe on 30 May 2013 - 05:02 PM

Hello! Copying this over from a post I made on tigsource, hopefully I can articulate my troubles sufficiently.. I've been working on a tile based game that might end up involving high velocities and decided to go for a continuous collision detection sort of model, due to some nasty looking behaviour where the character approaches the edge of a tile too fast. I've done some searching around at various implementations of CCD, and it seems to vary from example to example.
Having looked at ThemsAllTook's implementation and guide for swept AABB collisions here I understood the theory but found the actual intersection check a little hard to follow, particularly with the use of previous positions as opposed to velocities - but I suppose they're equivalent. I've ended up settling for an amalgam of that and a GameDev article on swept collisions (which I found a bit more intuitive).

The trouble is, I'm finding it difficult to overcome the surface area 'stubbed toe' problem. I figured I could find out minimum translation distances from new positions and intersection positions, but sorting by the surface area calculated in that fashion (technically just on one axis in the case of my implementation) doesn't seem to quite work and I get edge 'stopping' even in the case of just one collision.

Here is a demo of it in action, you can control it with arrow keys or the mouse - http://www.filz.us/view/1e940c5a-764/. The most noticable effect is if you slide up against one side, then slide off it on that axis and try to slide back - you'll get stuck on the corner.

Another thing I wasn't quite clear on was the fact that I found myself having to set the object's position to its corrected one, is that standard for a CCD simulation? I wasn't sure if I'd only be dealing with negating velocities and so on, it just struck me as odd. Without the positional correction in the collision resolution, I'd get issues with persistent forces acting on the body causing it to sink through other AABBs.

This is the simplified code, if it's at all decipherable I'd really appreciate it if somebody could point out how to go about solving the problem, and if my implementation of CCD even makes sense - http://pastebin.com/xWFsuxWm




PARTNERS