The reason why this is necessary is because you aren't guaranteed to have exactly the same number in the smallest parts of your precision due to rounding. Say you have 2 numbers that you've calculated: 2.948000021 and 2.948000342. You may want those to be equal, but they won't show as equal with a == check. No matter how careful you are, if you do any operations on a number that change it, it's almost always going to have a small rounding error at the end.

If you google the subject, you'll find plenty of information about it. You'll also find a more general rounding case for numbers that aren't close to 0, but for numbers that are relatively close to 0, the subtract and check is pretty much the easiest way to do it. (and you don't have to worry about a special case when one of them is 0)

Nayr Wrote:it is.
I believe there's a pre-defined epsilon buried in libc somewhere.. it might be too small for you purposes; float might be inaccurate enough to falsely pass the test...

Ahh yes, the constant is FLT_EPSILON, found in float.h

FLT_EPSILON is the smallest machine number (of a 32-bit float) that, when added to one results in a number greater than one. eg:
1+EPS > 1
1+0.9*EPS == 1

If you are just randomly doing "if (foo-bar < MYEPS)" you are most likely doing it wrong. The machine epsilon is usually meant to be used as a relative number. Machine numbers can be hard to deal with, and a badly chosen eps will very likely screw up things and introduce more degenerate cases than it fixes. Ideally, you should choose the eps mathematically to match your algorithm, in the worst case at least by lots of testing and deliberation.

I don't know about other people, but the main reason for me to compare floats in this way has been to eliminate equivalent vertices when optimizing my mesh. (that was also the context of my original statement)

akb825 Wrote:I don't know about other people, but the main reason for me to compare floats in this way has been to eliminate equivalent vertices when optimizing my mesh. (that was also the context of my original statement)

When I was doing similar work ( in my case, I wrote an API to let me declare meshes similarly to how you draw in immediate mode by drawing triangles and quads, and the backend would merge redundant vertices ) I collapsed similar vertices by ( expensively ) checking the squared distance between them, and collapsing if it was "close enough". In my case, "close enough" was defined on a per-situation basis... but admittedly, my models are simple. That being said, it worked beautifully for me.

I think you said before that you just used display lists with your demo program. Is all of your drawing going to be done with immediate mode/display lists? (since, if so, using something like bone-based animations would be... difficult without transitioning to vertex arrays/VBOs)