- Joined
- Jan 21, 2006

- Messages
- 2,552

Now, during development I consistently encountered problems where objects would seemingly "randomly" pass right through lines without any collision. I found that the problem of this was because it was really poor at floating-point math. Occasionally it would predict the intersection point of a horizontal line (

*y*=

**100**) to be something stupid, like

**100.001**which would screw up my calculation.

So what I did was implement a value labeled as

`epsilonZero`

. This value is a very low value that is supposed to prevent poor floating point mathematics from screwing with my geometry detection.My first value for this was

`0.000061`

which seemed to be the point at which comparisons would fail. For example, **2 + 0.00006**would be equal to

**2**but

**2 + 0.000061**would not.

Implementing this value did not work practically, and objects still passed through lines.

The next value I implemented was

**0.0001**which worked a little better. I realized that the preciseness of

**0.000061**was too precise for the engine in Warcraft. This seemed to fix certain untypical cases but there were still occasions where my system would tell me that

**600.001**is not on the line with a dimension of

**600**(even though no values of 600.001 were actually used).

I then proceeded to use 0.001 as my epsilon-zero value; and the problem seemed to be similar to the one described right above. Instead of 600.001 not being in the bounds, however, the value was something arbitrary like 600.003.

So I bumped up the value of epsilon-zero to 600.002. This seemed to solve the immediate problems and objects seemed to stop passing through lines (note that this is used to add to the position of the object as well as deduct from the component of the line - basically meaning the net difference would be 0.004).

The reason I posted this is because for many things floating-point math can be very useful in Warcraft. The poor math procedures that obviously take place in the background really make it difficult to use this effectively. I couldn't imagine spending hours on debugging only to find that it was a stupid floating point error that was causing problems (thought it is sometimes easier to see).

Does anybody know a foolproof value for epsilon-zero that will avoid floating point math errors?

It seems like the more I increase the value of my epsilon-zero constant it simply takes longer for the game to crash. It seems as though there is an extremely slowly incrementing margin of error. Testing with

**350**moving objects my FPS stays up at

**64**but it seemed to take

**50~**seconds before the game crashed (from an object moving through a line). This is with an epsilon-zero value of

**0.003**.

With an epsilon-zero value of

**0.005**objects seem to occasionally get "stuck" in the line, but the duration of the game before crash is indefinitely increased. Right now I am at

**160~**seconds but I've got

**3**objects that seem to be "stuck".

With an epsilon-zero value of

**0.0045**I have ran to

**60~**seconds without a crash, and only

**1**object being stuck in the wall. Also note that I bumped up the amount of objects from

**350**to

**450**.