Recent searches
Search options
Proper handling of signed zero is essential to avoid missing or doubled surfaces when interpreting signed distance data.
The only correct way to check for a zero crossing along an edge is to extract the sign bit from the f32 value at either end, and check for a bit flip. Floating point compares should not be used, since they treat positive and negative zero as the same number.
Zero values are common, especially when shapes are snapped to a grid, robustness is important!
@sjb3d can you just get rid of -0 altogether by adding “xxx + 0.0f” everywhere? Or no?
@christer I suppose you could filter out negative zeros if you did so consistently, but I wouldn't want to rely on FP arithmetic to do so!
@sjb3d depends on if getting rid of additional special casing of -0 vs sprinkling “+ 0” in the code is enough of a tradeoff, I guess. (And… FP arithmetic will do the right thing, but will you remember to add “+ 0” everywhere it’s needed?)
@christer ah, well my intent was more to say that -0 exists, and can be handled consistently (not as a special case) if you read the actual sign bit rather than using FP compares
@sjb3d We had a bug like that in an SDF just recently, although in our case the problem was that -0.0f did NOT compare as >= 0.0f, because of shader optimizations. Solved it by reordering operations a bit to avoid the negative zero. Another possible solution would've been to compare in integer domain instead of after float conversion.