On Sun, 30 Jan 2005 00:35:00 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Saturday 29 January 2005 18:05, Timothy Miller wrote: > > On Sat, 29 Jan 2005 13:28:51 +0100, Nicolai Haehnle <[EMAIL PROTECTED]> > wrote: > > > We can't get away without a full software fallback anyway. e.g. because > the > > > hardware won't support projective textures, and probably for the more > > > exotic OpenGL modes like feedback. This is not that big a deal because > we > > > can just use Mesa for that. So how are 3D and 2D any different, again? > > > > This is problematic. For instance, the chip does W-buffering, while > > Mesa probably does Z-buffering. We'd have to rewrite parts of Mesa in > > order to be able to fall back on it and still have it WORK. > > Well, don't say you haven't been warned because this is not the first time > this has come up. > > The fact is, *all* 3D APIs expose their depth buffer. OpenGL (and Direct3D) > specify a Z-buffer. Applications can read this Z-buffer - for example using > glReadBuffer, but there are probably less straightforward ways to do it. So > we *MUST* be able to produce compliant Z values. There's simply no way > around it. > > And once we're able to produce compliant Z values, we can just use Mesa for > software rendering. > > I'm curious what the rationale for the current design was, because I > honestly don't remember. There is one interpolant less than with a Z > buffer. Was there anything else?
(1) Saves on hardware (2) Can't screen interpolate world Z values anyhow (3) W buffering has been found to produce better results (4) Screen W can be represented more precisely in float25 than screen Z _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
