Hi Timothy, On Monday 31 January 2005 10:59, Timothy Miller wrote:
> What I WANT to do is define "round" so that it rounds up if the > parameter is exactly 0.5. �The hardware for that is MUCH simpler than > the alternative. Just as trunc(X) + 1 is easier than ceiling. However, does OpenGL permit this? I seem to recall something about a "upper left" rule for screen coordinate rounding. > > I seem to recall it was decided that geometry should be processed > > in fixed point, as opposed to floating point for color, texture and > > depth parameters. Considering that the multipliers are 18 bit, I > > suggest 14.18 fixed point format, or perhaps 12.20 on the theory > > that a couple of bits of extra interpolation accuracy are worth the > > extra shifts. > > We're using floats. 8 exponent, 1 sign, 16 mantissa. There's some discussion back there in the archives, but I may have failed to spot the final conclusion. I do recall it being mentioned that floating point does not make sense for geometry because the precision degrades as you move away from the origin. What worries me more than that though, is the complexity of floating point operations. Addition in particular requires a variable shift at the start and normalize at the end. That amounts to a lot of logic that has to be replicated many times over. Surely it must be at least three or four times what is required for fixed point addition. Are you sure that the design can afford this luxury without displacing some more important feature, such as a second pixel pipeline? I strongly agree with floating point color handling if it's possible to pull it off. This will help create the impression that the card is not old technology and provide a much better base when it comes time to implement shaders and the like. I have my doubts about the wisdom of using floating point for the edge interpolation though. > I designed the simulation model to deal with pixel centers and get > the right results. �The reason you can't pre-bias is that it breaks > down when you do MIPmapping. �Therefore, we just have to do it > "right". I do not see your point with respect to mipmapping. The geometry bias does not affect the projection of textures onto the geometry. > > This calculation is more complex for perspective interpolation > > because the adjustment has to be performed on the inverse of the > > interpolant. Could somebody please take the time to work out an > > efficient algorithm for this? �Even per-span divides have to be > > kept to a minimum otherwise small triangles become too expensive. > > We do perspective correction by taking the reciprocal of W and > multiplying. Of course. However, this is just an optimized way of dividing several parameters. For perspective interpolation you have to interpolate the inverses of the parameters, and divide by the interpolated inverse of W. This does not appear to be handled correctly in the model. 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)
