|
Floats And Doubles Question submitted by (15 January 2000)  |
Return to The Archives |
 |
 |
|
| What is the difference between floats and doubles, and what difference do they make in a 3D engine? Currently (because there is a lot of resources) I am working on a Quake II style game engine. When I render the levels, I get pixel gaps around the scene. I know this is from floating point precision errors, when two polygons, right next to each other, are rendered, occasionally a single pixel gets rendered up and the next gets rendered down, so a pixel gap gets rendered. Is thisfrom using floats rather fhan doubles, or does this not even make any difference? | ||
 |
 |
 |
|
|
|
For the most part, this is not a precision issue. Precision does play a part,
but not as much as you might think. Let's examine what happens when we
scan-convert a polygon... When we scan-convert a polygon we calculate the deltas along each edge. There is some error calculated here (except in rare cases, like perfectly vertical edges.) And what's worse, is that the error in the deltas is accumulated as we step from scanline to scanline along that edge. For example, if our precise delta should be 0.1, and our calculated delta was 0.101 then our error is 0.001. As we step from scanline to scanline (adding that delta – and its error – to a value), we accumulate that error over and over, until, on the 10th scanline, our total error is now 0.01. Believe it or not, this usually doesn't cause edge gaps. Why? Because when we render the neighboring polygon (which shares this error-prone edge), it will also accumulate the same amount of error at the same rate, assuming that the vertices are exact (or shared.) So, although the error is present, the result is that both edges are scanned exactly the same, so there should be no gaps. So, where do these "edge sparkles" come from? Well.... Depending on how the scan conversion is setup, you can get rare cases of edge sparkle, but unless there's a bug there someplace, it should be rare. I've seen some old buggy Matrox G400 drivers that caused a ton of pixel gaps, but those drivers have long since been fixed. I've also seen the Voodoo 1 & 2 produce some edge sparkles. But most of your newer cards should be pretty good about reducing them to "almost never". The most common cause of edge sparkles is t-junctions. The reason why t-junctions are prone to error is the same reason why shared edges are not prone. T-junctions don't share the vertices of the entire edge, so the deltas are calculated slightly differently for the edge (one delta for one edge, two deltas for the adjoining edges.) This means that the error is different, but more importantly, it accumulates at a different rate. This is true for both, software and hardware rendering. In the end, my suggestion is to make sure your geometry shares all of its edges perfectly with no t-junctions. If you're using a software renderer, start looking for a bug, or inconsistencies in the way edges are scan-converted. Response provided by Paul Nettle |
||
|
|
|
This article was originally an entry in flipCode's Ask Midnight, a Question and Answer column with Paul Nettle that's no longer active. |