# Timestep and collisionresponse(pic inside)

This topic is 5456 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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?  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]

##### Share on other sites
i would do the last thing because it looks more natural.

##### Share on other sites
It depends on your exact situation - is this for non-physical character movement, or for physics?. And can you afford to divide up the movement into a number of steps (e.g. if you had a lot of objects)? There is an argument that, assuming your timestep is reasonably small, then if there's a significant different between the two positions (one touching the collision poly, the other "reflected" off it) it means the object is going so fast that nobody would notice if you "lie".

##### Share on other sites
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.

##### Share on other sites

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.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 22
• 17
• 13
• 46