Hi Lourens, On Tuesday 08 February 2005 16:21, Lourens Veen wrote: > On Monday 07 February 2005 20:36, Daniel Phillips wrote: > > On Monday 07 February 2005 11:21, Lourens Veen wrote: > > > Oh, and a remark: I just checked and nVidia's 16-bit framebuffer > > > format (which is also used in OpenEXR, that's where I checked) > > > uses 1 sign bit, 5 bits exponent and 10 bits mantissa. This > > > almost-13-bit reciprocal will probably also be good enough for a > > > floating point (High Dynamic Range) framebuffer... > > > > I have strong doubts that 13 bits is enough precision for the > > reciprocal. I think 16 bits is barely enough. I'm not in a > > position to quantify that yet, though. > > Attached are two renders (I made the quad's angle a bit more extreme) > of the software model. One is with float25 and correct division (16 > bit), the other is with float25 and the approximate reciprocal (a > little less than 13 bit). There are a few off-by-one errors, but to > my naked (well, I wear glasses) eye there is no difference. Judge for > yourself. Tips for better tests are welcome by the way, I have no > idea whether this is worst case.
It looks good, but it's far from the worst case, try setting the viewpoint so that one texel spans half the screen. Note that the accuracy varies depending which part of the texture you map. Higher values of s and t eat some of the mantissa, which is something that bothers me about using floating point for texture coordinates (or did I miss something there?). Also, have you tried animating it? A single pixel jiggling here and there is easy to see in an animation. 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)
