🔒 Locked

Normalized Vector Roundoff Errors

Started by Endemoniada Aug 7, 2003 at 1:58 PM 3 replies 1.2k views

Original Post

131

Aug 7, 2003 at 1:58 PM

Hi guys, Sometimes my pool balls bounce off corners in a crazy way and I figured out that it's caused by roundoff errors. Here is a perfect example:

// the normal to the wall (perfect diagonal)

Vector2D vNormal;
vNormal.x=1.0f;
vNormal.y=1.0f;
NormalizeVector(&vNormal);

// the ball's direction (already normalized)

Vector2D vBallDir;
vBallDir.x= -1.0f;
vBallDir.y=0.0f;

// reflect ball direction (pseudo code)

newDir=vBallDir-2.0f*((vBallDir*vNormal)*vNormal)

Here is the result (should be 0.0f,1.0f): newDir.x: -0.000000059605 newDir.y: 0.999999940395 Now I don't really care if the direction is slightly off but when I use those numbers in other calculations it messes everything up. How should I go about handling this ? I guess I can see if a value is really close to 0.0 and then make it zero if it is and do the same with 1.0 but will that work ? Any guidance is appreciated. Thanks. [edited by - Endemoniada on August 7, 2003 2:59:45 PM]

johnb

Aug 7, 2003 at 2:56 PM

I would say just accept such "errors". The errors in FP calculations such as these are far smaller than the errors that occur in real physical situations, due to uneven surfaces for example. If you are working on the principal that everything must be mathematically perfect then your simulation is far too precise to be realistic.

If you want such unrealistic precision: e.g. if your objects are constrained to only move along lines parallel to the 4/8/16 points of a compass, then you can examine the values each time and see what direction they are closest too, then subnstiture that direction. But otherwise I''d look at your logic as a physics engine that goes "crazy" whenever things are less than perfect sounds like one with inherent stability problems.

JohnBolton

132

JohnBolton

Aug 7, 2003 at 5:42 PM

I suggest you figure out why your code is so super-precision-sensitive and how you can reduce that, rather than implementing some hack that is guaranteed to cause even worse problems in the future.

Endemoniada

Author

131

Endemoniada

Aug 7, 2003 at 6:00 PM

Hi guys,

Yeah, you are both right. I don''t really care about it being perfectly accurate.

I figured it out. It was fucking up my collision detection which resulted in some crazy behavior. For example, it''s not supposed to test for a collision if X is less than zero but the very slight -0.000000065 caused a test and a collision and a new ball direction that was all wrong.

I think I fixed it.

Thanks.

Zipster

511

Zipster

Aug 7, 2003 at 6:25 PM

A good technique is to use epsilon values. Instead of checking if a value is less than 0.0, you check to see if it''s less than -EPSILON (epsilon being something like 0.0001, or another value just past the precision you care for). For greater than 0.0, instead use greater than EPSILON. And finally, it you want to check for equality to 0.0, check if the absolute value is less than or equal to EPSILON.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.