all vars are of type float and the data in
each is:
v1[0] = -100.222
v1[1] = 101.733
v1[2] = -101.109
v2[0] = -100.222
v2[1] = 101.733
v2[2] = 101.109
the problem is when I subtract v1[1] from
v2[1] i get -3.05176e-005 not zero as you
would expect. Anyone know why this happens?
I’ve tested this on a few computers and the
vertex data was exported from 3dsMAX.
Assuming that you did not explicitly set the values for v1 and v2, i.e. it was calculated by something else, the values slight differences to the order of e-5
always be wary of checking for zero when you are using floats. Even if it prints out 0.00000 then it can still fail if ((float)x == 0).
floats only approximate integers.
As I pointed out earlier the figure you posted are rounded off versions of the float’s true value (unless you specifically had in the code v1[1] = 101.733; v2[1] = 101.733 . When the calculation of the difference is being done it uses the true value and not the rounded off value. Hence the result will not be zero.
But even if the normal is (0.0, 1.0, -1.50915e-007) your z value for all intents and purposes is the same as zero. Visually, I doubt anyone can distinguish the between the rendered results of that normal and (0.0, 1.0, 0.0). The difference should be too small to distinguish with the naked eye.
On the other hand if another calculation depends on the normal then you have two choices; normalise the vector or set z to 0 manually. Sorry I can’t be more helpful but thats how data types are. You can’t force them to be different, you just have to live with it and make adjustments yourself.
Just write a func which rounds your numbers up to say 4 dp or something similar. I use that alot when doing trig and quaternians as things need to be normalized etc…
. When the calculation of the difference is being done it uses the true value and not the rounded off value. Hence the result will not be zero.