Collision Timings

There are several ways. THe simple way, just test objects one by one. Consider other objects static, and trace the object through. When colliding, move the collider to the time of collision, apply the response (that will change the colliding and collider object's velocity), and trace again with the remaining portion of the time / distance, then move to the next object. So in the end, there will be no 'simultaneous' collisions to worry about :)

The complicated way, to sort collisions by time, move objects to first time, compute response, then do a test again. This is actually very slow if you are not careful (there are shortucts you can use, but it's still a pain to implement, and requires lots of work, like clustering objects into collidable groups, and so on).

The first way is way way simpler, and is the way Quake 3 and the likes do. Then you don't have to worry about timing. Obviosuly, it's not super accurate, but in the context of a game, with relatively slow moving objects, it should be fine. Depends what you need really. The first one, you can sort the objects but velocity, the faster ones will probably need to be tested first.

BTW, tracing means a swept test. Swept box, swept sphere, swept convex hull. That would probably be the most accurate way.

Quote:

Original post by oliii There are several ways. THe simple way, just test objects one by one. Consider other objects static, and trace the object through. When colliding, move the collider to the time of collision, apply the response (that will change the colliding and collider object's velocity), and trace again with the remaining portion of the time / distance, then move to the next object. So in the end, there will be no 'simultaneous' collisions to worry about :)

sorry for not replying, been swamped with tests and courseowrks and other horrible stuff..

thank you for the advice, but my problem has a lot of spheres moving around in a closed enviroment, so simultaneous collisions are very possible. the current way i'm trying to do it is..


//Itterate through the list of objects
//If it's a static object, don't bother
//Do a collision check against the rest of the lists objects from that point on
//If they collide
//add to a list of collisions
//Move onto the next object

...

//Itterate through the list of collisions
//If any object collides with 2 or more other objects
//Find which collision would occur first and only do that
//If two happen at once
//do a simultaneous collision


the way i see simultaneous collisions is that the object that collides with two other objects will be refleced in a plane defined by the two objects it's colliding with.

Ok here it is..."Glitchy Collision Demo V1.0"!!

http://www.sharebigfile.com/file/125032/Physics-exe.html

Disclaimer: May cause PC to combust, though I've tried my utmost to make it not a horribe memory hemmoraging beast...

I'm concerned about the sphere collisions glitching and 'orbiting' the collision point. Anyone know what could cause that? At a guess I'd have said that its the spheres not moving far enough each frame so they 'bounce' around the point of collision.

Also it doesn't "handle" 3 object collisions yet, that will be implimented shortly.

Also I'm aware sometimes spheres bounce outside the box and into the great unknonwn.

missing a bunch of dlls. I really need to update my home system...

Sort object by linear sorting algorithm (if you would use nonlinear sorting algorithm it must be stable. IIRC all linear sorting algorithms are stable.)
Colliding objects can't be far away on resulting array, thus you'd have easier work. If you need something more sort it by another axis. (for this you would need that stable sort.)

If this is still not enough, enclose them into some hiearchics objects. (for example into an octree)

For simultaneous collisions: Sum all vector of collisions (that affects the object) before you'd apply them.