Quote:Original post by MrRowl
Yes - I noticed this in the big cabin (not the one where the captain would stand :). Not really quite worked out when it happens... but it can happen when you're just shooting at a big patch of wall (i.e. not towards a hole etc).

Quote:
I also noticed that you can get bad collision directions - fire a box at an angle against the side of the ship, and in some cases it comes bouncing back towards you, presumably because it hits a polygon edge. If you sort the collisions by depth (at least between pairs of objects) this problem can be reduced.

Quote:
Possibly the problem with swept tests and your implementation is that you only respond to the collision after moving the object (I think... may be muddled :) so the algorithm allows penetration to happen, and that is bad with triangle meshes. Processing the collisions before the position update generally results in no (or little - can get bad results in corners) penetration at the end of the step, which is a Good Thing, because collisions are effectively predicted. The bad thing is that objects stop before they hit, which can look odd, especially for supposedly inelastic collisions.

Quote:
I mentioned before that I had a solution to that. The idea is that the collision detection does a swept test and records (a) the contacts (as offsets relative to each object but in world space) and (b) the estimated penetration depth at that contact at the _start_ of the sweep, not the end. Then:

1. If you have two objects that are really overlapping, the penetration resolution code kicks in and applies impulses to separate them - it constrains the separating velocity to be >= (penetrationDepth * N * dt) where N is maybe 4 or 5.

2. If you have an object sitting "at rest" on a plane, whilst you detect collisions with the plane the penetration depth is 0, so no extra penetration-resolution gets done

3. Lets say all collisions are inelastic. Now, when a collision is detected, rather than constraining the separating velocity at each contact to be >= 0, you constrain it to be >= (penetrationDepth * dt), bearing in mind penetrationDepth is -ve. So, when a object (e.g. ball) is fired straight at a wall and about to hit it: (1) A collision is predicted, and the code calculates an impulse that will result in a normal velocity that places the ball _just_ touching the wall at the next time step (2) At the next timestep, normal inelastic collision occurs, and the ball stops dead, just touching the wall.

One nice thing about this is that exactly the same code is used for this predictive-collision impulse as is used for the penetration resolution, so there's not any extra cost. Oh, and the other nice thing is that it works :)