Re: [Dri-devel] tuxracer texture problem on radeon

[Tim S. <ti...@el...>]

On Monday 08 Jul 2002 6:31 am, Elladan scribed numinously:"
> On Sun, Jul 07, 2002 at 09:18:44PM -0600, Brian Paul wrote:
> > Elladan wrote:
> > >On Fri, Jul 05, 2002 at 08:15:26AM +0100, Keith Whitwell wrote:
> > >>Elladan wrote:
> > >>>Yes.  I'm seeing the same thing on my Radeon 7500.  See screenshots
> > >>>here:
> > >>>
> > >>>http://www.eskimo.com/~elladan/tux
> > >>>
> > >>>(Or in the bug report I filed on the dri project page...)
> > >>>
> > >>>I'm also seeing generally horrible problems with tuxracer whenever
> > >>> it uses multiple textures on the same polygon, as far as I can
> > >>> tell.
> > >>>
> > >>>There seemed to be a few other bugs in the database on multitexture
> > >>>problems, too...
> > >>
> > >>It's to do with multipass rendering, I think, rather than the texture
> > >>code specifically.
> > >>
> > >>The same problem gives you the 'shimmery' ice patches.  The mesa
> > >> gloss demo shows similar artifacts.
> > >
> > > Where would this problem most likely reside in the code?  Any
> > > guesses? Eg., file/function areas?  I can go playing around in there
> > > if someone have some vague idea what the problem might be...
> > >
> > > -J
> >
> > This sounds like Z-buffer fighting.  If you draw the same triangle
> > twice with exactly the same vertices you'd expect that the same Z
> > values would be generated for each fragment.  But the OpenGL spec
> > doesn't require that to be true, depending on particular state changes
> > between passes.  (See the OpenGL spec appendices).
> >
> > If the first triangle is drawn in hardware but the second is drawn with
> > software (or vice versa) you almost never get exactly the same
> > rasterization results.  I've also seen cards which will do both passes
> > in hardware but still produce different Z values.
> >
> > glPolygonOffset() is the usual solution to this problem and its up to
> > the application programmer to know when to use it.
> >
> > Strictly speaking, the gloss demo should use glPolygonOffset() for
> > the second rendering pass.  But it doesn't because I was lazy when I
> > wrote the demo.
> >
> > So, if my hypothesis is correct, this is an application problem.
>
> Ok, I'll investigate the application to see if it's the problem.
>
> I seem to recall that TuxRacer more or less worked with the 4.2 Radeon
> 7500 drivers, but doesn't seem to work with the TCL drivers.  This might
> indicate that, eg., one pass is being done with TCL and one with CPU
> transform (and they don't agree)...

FWIW I get this problem too. With RADEON_NO_TCL it goes away (as later 
reported).

I see it on character models in the Neverwinter Nights Beta toolset, but 
only when the server is in 24bpp mode. In 16bpp mode it doesn't occur. In 
the case of tuxracer it's still there in 16bpp but much less pronounced 
than in 24bpp. Don't know if this information is useful but thought I'd 
mention it.

-- 
Tim Smith (ti...@el...)
England Prevails.