Sign in to follow this  
kosmon_x

Time inaccuracies in a collision detection system

Recommended Posts

A little background: ------------------------ I just implemented a basic sphere-sphere collision system which will determine whether a collision will occur when given an elapsed time. The result will be in the interval [0,1) if there is a collision -- 0 meaning right at the start of the frame and close to 1 meaning right at the end of the elapsed time. When I detect a collision at time T with a sphere, I move the collider up to ElapsedTime * T, then change both velocities, then repeat looking for more collisions with that object. When no more are found, I move it the rest of the duration -- ElapsedTime * (1.0f - T), and then repeat for every other sphere. The problem: ------------------------ The problem is floating point precision -- every time a collision happens, I lose about 0.005 milliseconds. In other words, if I pass in an ElapsedTime of 15ms to my physics update every frame, the objects that collide only get moved for around 14.995ms worth of time. I think the problem comes with my multiplication -- ElapsedTime is already pretty small, and then multiplying that with an even lower T value could cause some loss of precision, but I'm not sure. Has anyone else encountered this problem, and if so, how did you fix it?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
yeah, that happens all the time. How did I fix it? I didn't. It's not a bother for me. If it's a bother for you, use doubles instead, if you can. You can also try to compensate at the end of the frame for loss of energy (kinetic + potential).

Share this post


Link to post
Share on other sites
Rounding errors are everywhere in games development. We use floats instead of doubles because we prefer the speed offered in floats at the cost of accuracy. If you are particually concerned about accuracy the best thing you can do is use more than one equation to keep the physics consistent. As anon said theres energy that needs to be consistent, but for non elastic collisions I recomend momentum (momentum before = momentum after, ALWAYS). I personally find that normalizing my vector for the normal of collision trashes any accuracy I hoped to have, but I just live with it.

Yratelev

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this