Look at the picture below. It's supposed to describe the movement of a sphere during a full timestep. The top part of the picture describes where the sphere is estimated to be after a full timestep. The middle part of the picture shows that the collisiondetection routine detects a collision at half of the timestep. Now, should I "lie" and tell the simulation that this is the position of the sphere after a full timestep or should I do another "sub-timestep" using the remaining time of the first timestep(as the bottom part of the picture shows), to give a more accurate position of the sphere? [edit] I just realized that there is a thread with a similar topic... http://www.gamedev.net/community/forums/topic.asp?topic_id=275600 [Edited by - Sweenie on October 13, 2004 4:45:01 AM]

I handle this problem using the former method, ie, I lie and truncate the sphere's movement at the point of collision. Within an animation, it looks just as natural, and you don't notice a skip in the movement, or anything, especially if your frame rate is reasonable.

The advantage is, you avoid the possibility of infinite collision loops. It's theoretically possible for the moving sphere to bump into something else, AFTER the collision, which would then bump into something else, and into something else, etc, causing an infinite, or at least uncomforably long loop. (Technically an infinite loop shouldn't occur if you're correctly calculating your resultant velocities, and the collisions aren't perfectly elastic, but as an example, the "flying" physics engine that comes with old distributions of Linux had the infinte loop problem none-the-less.) If you truncate the sphere's movement, then each object can only have one collision per frame, which will give you a nice smooth performance. (Though if you simulate a pool break on an embedded device, you'll get a second of pause while the collisions radiate outward. [disturbed]

There is only one catch to this method. Your simulation will have slightly different results depending on the size of your timestep. Energy is conserved, but since the sphere's movement could get clipped at a different point in the timestep depending on the size of the ones before it, the exact time that it comes rebounding off the wall will differ, and it may or may not come into contact with other moving spheres. If you want the simulation to be deterministic, either stick with a set timestep, or use the latter method.

Thanks for your tips.

I think I will go for the latter method and set a limit on how many substeps/subcollisions that may occur.
This should prevent the simulation(it's a physics-simulation) from choking if the space around the sphere gets too crowded.
This way I could also adjust the accuracy by changing the limitvalue.