is there an algo for quick and dirty sliding collisions?

something less intense than recursive ellipse vs each tri, done in elliptical coordinates, so the entity location at time of intersection is easy to compute?

i mean, the physics are simple:

determine entity location at time of collision,

determine remaining entity movement vector at time of collision

convert remaining movement vector to normal and tangential movement vectors with respect to the obstacle.

discard normal, and apply tangential.

continue until remaining (tangential) movement vector is used up.

i suppose continued collision detection while applying the tangential is required.

this would mean that any collision detected then turns into a stepped movement thing.

aa-bbox approximations for everything?

is there an algo for quick and dirty sliding collisions?

something less intense than recursive ellipse vs each tri, done in elliptical coordinates, so the entity location at time of intersection is easy to compute?

i mean, the physics are simple:

determine entity location at time of collision,

determine remaining entity movement vector at time of collision

convert remaining movement vector to normal and tangential movement vectors with respect to the obstacle.

discard normal, and apply tangential.

continue until remaining (tangential) movement vector is used up.

i suppose continued collision detection while applying the tangential is required.

this would mean that any collision detected then turns into a stepped movement thing.

aa-bbox approximations for everything?

Some ideas:

You can use a 0.0 coefficient of restitution in que equation above:

float fForceLen = -(1.0f + fE) * CVector3::Dot( vNormal, vVelRel ) / fInvMassSum;

Another option is to only resolve the penetration instead of the positions and velocities at time of contact.

What you're saying looks like continuous collision detection. The Real Time Collision Detection book has a entire chapter on that. What you'd do is to test the intersection between t0-tN where tN is how much are the increments of the fixed time step that you have – looks like this method is deprecated in today's physics libraries.

The entity location at time of collision is just copy cache the entity location. The contact point is another thing, and so on...

some possible simplifications i though of:

1. use the players starting position, not the players location at the time of impact moved back a bit. this eliminates the need to calculate the players location at the time of collision, and the move back a bit fixup for floating point inaccuracy. the difference would be <= one frame's worth of movement.

2. use AABBs instead of mesh triangles for collision detection. this reduces tangent velocity calculation to determining if the obstacle is north south east or west, then computing the projected tangent velocity accordingly.

3. using a while (displacement_left>0) loop to call a routine that moves the player by a diaplacement vector, and returns a new displacement vector resulting from collision (the amount and direction of tangential displacement remaining to be moved), or a zero magnitude vector if done moving. this avoids recursion.

There's nothing wrong with computing the TOI for the player and you don't need to do it recursively; you can do it iteratively. You can treat the TOI computation as a root finding problem and solve for the impact time at 0 (for example with a binary search down to some acceptable threshold). This can be especially easy if you change your player to a sphere instead of an ellipse. You could even try inflating the planes of your triangles and shrinking the sphere to a point allowing you to raycast against the triangle plane to solve for the TOI in closed form. You can also approximate the player's ellipse shape with two partially intersecting spheres.

Also don't forget you don't need to search every triangle like you stated in your original post. For example, you can calculate an AABB over the player's swept motion and then find only the triangles who have their own AABBs intersecting the swept AABB. From here you can then more finely test the triangles that passed the pruning step.

A simple way to make the player slide along walls (or planes) is to use the outer product and the player velocity:

v = (I - (u * u))v;

Where u is the plane normal, I is the identity matrix, v is velocity and * is the outer product. This is just projecting the velocity vector onto the plane. You can take the matrix (I - (u * u)) and use it to project any vector onto the plane corresponding to the normal u.

A simple way to make the player slide along walls (or planes) is to use the outer product and the player velocity:

form engineering mechanics - statics and dynamics:

the projection of a velocity vector V onto a plane P is the vector V times the cosine of the angle between the vector V and the plane P.

this is used all the time to determine the i,j,k components of a displacement, velocity, acceleration , or jerk (daccel/dt).

the linear algebra approach should get the same result - perhaps with more math and writing required.

for AABB's i came up with this (for left handed coordinate system):

1. move as usual:

x_displacement = player_speed * sin(player_Y_rotation)

z_displacement = player_speed * cos(player_Y_rotation)

// temporarily move the player, then check for collisions

temp.x=player.x

temp.y=player.y

temp.z=player.z

// move them

temp.x+=x_displacement

temp.z+=z_displacement

2. if collision occurs at location temp,

check locations player+x_displacement and player+z_displacement

3. if no collision in x, but collision in z, move player by x_displacement.

likewise, if no collision in z, but collision in x, move player by z_displacement.

else don't move player