   OOBB collision response
  Hi all,I have a working SAT collision/intersection implementation that I converted from a C code example from here abouts.So collision seemed to be sorted until I started using it within the game system.What is happeneing is that I have Mario-like blocks but in 3D to represent the level (oobb) and a player with a collision oobb. The issue is that as the player moves between the block boundaries, I get a kind of "snagging" effect, which seems to be dependant on player movement direction. My process is to test each nearby block to the players oobb and update the players position on each collision. This is part of the snagging problem as the resulting position is dependant on the order in which the blocks are tested.Is there a way to rectify this? Should I be testing horizontal and vertical movement seperately to remove the effect of gravity always pushing the player into the block. I currently am using the MTD as the way to rectify each collision - is this a reliable method (I ask as there seems to be some instability in the Mtd if the player is left standng on the edge for a while).Any help on models for responses would be most appreciated.Steele.   
  That's an unfortunate side of the MTD as the collision response. For characters, a 'step up' process is usually recommended for walking over small obstacles and stairs, as well as a 'step down' process for walking down slopes / stairs without the floaty effect.Alternatively, decompose your character movement into and (x,z)-axis and y-axis movement. Although you will probably still find wall junctions sticky. Another solution is to ignore edges that are 'joining' two faces for the response and MTD calculation. For example, a floor tile. Only two faces for each tiles are off interest, the top and botttom face. the edges should not produce a response to collision, nor the side faces. So, you still test for collision against those face / edge with the SAT collision test, but when it comes to the MTD calculation and refinement, you just ignore them.Also, a swept test would help in that regard as well, as one of the cause with the 'snagging; is the fact that collisions are not sorted by time of occurence (since you do not know the time it happened). Here you can clearly see the box will hit tile 'A' before hitting tile 'B'. So what you'd do is move box to time of collision against 'A', apply a response (slide character on top of 'A'), and then test again. Now the box will miss 'B'.Here is some code for the swept test, and also the intersection test where the MTD is computed. I do not sort my collisions, rather take them as they come, so you may need to add the sorting algo yourself. I'll probably write a version where this is done. [Edited by - oliii on May 26, 2010 11:02:49 AM];  Thanks oliii - I think I now remember where I got my base SAT code from! I do thank you very much for it (though I have C#-ified and XNA'd it - don't hate me for that!).I didn't think of splitting the intersections off by face, rather than by the full oobb.  I will need to see if I can fit that logic in.I am also moving the "displacement" position by the MTD directly, which, as I understand it, does not take into account the vector of motion from the originating position. I'm not sure I understand the math enough from your collisionReponse code to know if/how you are backing out in time along this motion vector, but then, I suppose I need to work out something myself!Implementation examples on SAT seems to be scarce, so I really do appreciate you sharing you knowledge on this.Steele.   ;  Hmmm... I tried the sorting approach on a holistic level, basically sorting the close oobb's kinda by the vector of motion (well, by x first, y second, z third) so the blocks behind *should* rectify first... but so far, not a good result.  I need to do some more debugging on exactly what values are being returned, but I think I have to chuck the MTD as a resolution method for the collision and research more into the resolution back along the vector of motion.Thanks for the help so far oliii.Steele.   ;  ok then. Here's an example of dealing with 'stitched' boxes, where the shared edges are ignored for response.imo, that would be a simpler way of dealing with your problem. The problem is identifying the faces and edges that should be masked for response. There are also problems in cases such as this    +-----+-----+    |||    |||    |+-----+    ||    +-----+    problem : 'T' junction. can't ignore shared face in the middle, as it is not fully occluded. so walking on top side can cause a snag.    solution : split the left box in two.    +-----------+    |.|    |.|    |.....+-----+    ||    +-----+I haven't found a neat enough solution to the problem yet. Apart from the step-up, step-down algorithm, or splitting your character motion in a horizontal movement (and test collisions), then vertical movement. But that won't work for sliding on walls as you'll still get the snagging effect.Note that using a sphere for your character greatly reduces the effect (no sharp edges to snag onto).   ;  That is a good way at looking at it - I must admit, I have been stuck thinking about the blocks within the level as basic, isolated units.  But you are right that even static blocks will have relationships to surrounding, static blocks.A new idea to play with.Thanks!   