Hi Timothy, On Tuesday 15 February 2005 12:48, you wrote: > Has anyone figured out exactly how much precision we actually NEED?
It's a tough question, especially for me, by no means an expert. But nobody else jumped out of the woodwork and it's an important topic, so I'll have a go. First, this is all about worst cases. It hardly matters how rarely the worst case comes up when you animate thousands of triangles per screen. That rare worst case is going to show up pretty soon. Animation is far more demanding than a static scene. If a texel is shifted by a pixel in a static scene, who will ever know? But if it shifts back and forth in an animation it becomes glaringly obvious. Accuracy to within a pixel is nowhere good enough. Think about a polygon edge crossing the screen, slightly rotated so that at exactly one place on the edge there is a one pixel jag. The _position of the jag_ needs to be accurate to subpixel precision, otherwise the transition point will jiggle in animation. Antialiasing doesn't get rid of the jiggling, it just turns noisy pixels into jiggling jello. In any case, we can't count on antialiasing or filtering to cover up precision defects because the application may not enable them. Positioning each jag with subpixel precision effectively doubles the bits needed to render edges and then some. For a screen width of 2048, 24 bits is barely enough. There are only two bits left over for subpixel jag position. Our planned 17 bits is not even close, so we clearly need to do something here. Precision requirements for textures depend on both texture size and screen size. Consider a texture consisting of black and white stripes, with no build in filtering. When rendered, the stripes should be straight and the edges of stripes should be as stable as polygon edges. Each texel jag should be positioned with subpixel accuracy. The accuracy requirement is the sum of bits needed to address the texel, bits needed to position the texel on the screen and some additional bits for stability in animation. For a texture width of 256 and screen width of 1024, that is 18 bits before allocating any bits for animation stability. Given that the hardware pretty much forces us to 17 bit precision here, we can be thankful that it's not that far off. We do however need to take great care not to let other factors such as interpolation error and divide approximation degrade that much more. Large textures and higher magnification require more precision. There are opportunities to control this at the driver level. Repeating textures are a nasty problem. Simply masking the texture address after division eats one bit of precision for each doubling of repetitions. Somehow, the perspective interpolation needs to be kept in range during interpolation, even though that's not an easy calculation at all. It would be nice if we could just forget about repeating textures and let them jiggle, but we can't, if only because they are very common in wall, ceiling and floor tiles. Now on to interpolation. It's a necessary evil because it eliminates many multiplies. However it introduces cumulative error that can become very large. In animation, worst case tends to snap suddenly to best case, causing large wobbles in edges and textures. If deltas are accurately calculated and properly rounded, worst case loses half a bit every step. For 1600x1200, animating down the screen and across, worst case is roughly a 10 bit error. We simply can't afford to take that out of our limited rasterization precision and must find other ways to control it. There is probably no good way to avoid a few bits of interpolation error, but trying to interpolate across the whole screen with 17 bit precision is a guaranteed disaster. So let me summarize the areas where we need to focus and come up with solutions: 1) Higher fixed point precision for edges 2) Accurate divide approximation 3) Control interpolation error 4) Do something about repeating textures Number 1 is easy, 24 or 32 bits will do the trick. Number 2 is pretty much solved. We've touched on number 3 but need to get serious about it (see next post). Number 4 is a big, unsolved problem. I likely missed a few sources of error in my survey, can anybody point out missing details or (ahem) errors in my arguments? Regards, Daniel _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
