Collisions > Deflections > Move or M.C.D
Monkey Forums/Monkey Programming/Collisions > Deflections > Move or M.C.D
| ||
| Just wondering what order you place your move code and your collisions and deflection code. At the moment I am checking collisions, pushing back if needed and then moving. Wondering if moving first , then checking collisions and then doing any deflection might be more sound. anyone else care to throw in opinion ? |
| ||
| I generally move first, check collisions then deflection. It seems to work well for me :) |
| ||
| I'v been running some tests with my code, I can either have a ball bounce from only a tile, or have the ball bounce from other balls and tiles. with only tiles in play I can throw tons of balls in and they play nice with the tiles, but once I add the ball to ball detection in, it pushes some balls over a tile making the ball pop out at odd places. |
| ||
| Calc new target pos, get collision data, clip and then adjust your movement based on this collision data and then move to the actual point you are forced to go to. You may have to interpolate your moments if your moving to fast between collision checks too. |
| ||
| Multiple ball collision is not something you can just complete in a single time step with a single pass(a single collision). if you are trying to apply ball physics to your game and don't want to complicate your life, use a physics engine. I had to struggle with that for the pool game I have in the apps section. I had the same problem you are having at first but eventually figured it out. The problem you are having is that there are multiple collisions happening with in a single time frame(even possibly the same balls more than once) and not all collisions at the same time. you must determine which collision happened first, advance all of the balls to the position where all the balls would be at the time of that collision, change the direction of the balls that collided, advance "ALL" of the balls to the position they would be when the next collision happens, change the direction of those balls that collided and continue the process until all balls movement have been used up. Also consider that there might also be more than one collision happening at the same time. The process is time consuming and if you are not using dynamic collision, it's going to be even slower. walls may also be included in the sequence of collisions. |
| ||
| Yeah, actually my main issue at the moment is that a ball traveling at 6 pixels per step might step over a collision 3 pixels away and into another, when that happens the ball is nudged back to the point of almost touching the first collision, this then places it in collision with the tile it skimmed over, which then needs to push it back toward the first collision and it gets stuck in a loop. What I could do is move the ball 2 pixels at a time in a loop for speed, and check collisions each step but it will increase each update time, I think it might be fine with a low number of balls and I only ever plan to have about 6 at any time active. Another solution is to do a line intersection test, draw 3 lines from the balls last position to its new position, check if any of the intersect with an object, then move the ball to almost touching that object and calculate the response, this method would be far faster than the other but a little more mathy. As for the multipul collisions in the same pass, I gave my balls a collision counter, they cant collide with more than one object in the same pass, each time they more their collision counter is reduced capping at zero, so if a ball is touching 3 tiles in pass 1, it will react the first collision and ignore the other two, it will deflect, on the second pass if its still touching 1 or more of the other two tiles it will detect one and then react, its not a perfect system but it is a quick and dirty fix. |
| ||
| What Jesse said. I had the same problems with my pool game and after about 6 months of banging my head against the wall I decided it would be best to just do the whole thing in box2d. You have to have a whole system to do multiple passes on objects, casting rays forward and trying to predict the next frame, then moving back and "resolving" multi-body collisions before updating the simulation for the next round of updates, praying that the state you've updated to is still valid. Trying to do collisions after the fact without at least a little bit of next-frame prediction requires even more rewinding and chances that the simulation's going to go awry. The biggest issues are the speed one which you've already run into, and multi-body collision. Hitting narrowed-angle walls, or a dynamic body hitting a wall and another dynamic body at the same time, can cause the simulation to fail and your bodies getting stuck in a wall, or worse, exiting the simulation entirely. Adding "fudge factors" to get them unstuck becomes a nightmare and can lead to a whole host of cascade scenarios. Even well-made physics engines suffer from this to some degree, and can be exploited to exhibit cascading behavior (such as unusually high velocities, objects not conforming to their simulation constraints, etc) with enough determination. |
| ||
| Even for a single ball with rigid walls, it's by no means easy! |
   |