Re: [Mesa3d-dev] Fog still different

[Brian P. <br...@va...>]

Keith Whitwell wrote:
> 
> Brian Paul wrote:
> >
> > Brian Paul wrote:
> > >
> > > Klaus Niederkrueger wrote:
> > > >
> > > > On Fri, 16 Feb 2001, Keith Whitwell wrote:
> > > >
> > > > > Klaus Niederkrueger wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have compared again the software-fog in the 'fire'-demo with Mesa-3.4
> > > > > > and Mesa-3.5 and in Mesa-3.5 it is still a lot denser than in the old one.
> > > > > >
> > > > > > I don't know if this is important or not and if was a bug, I have no idea
> > > > > > if it is now or it was before.
> > > > > >
> > > > > > I haven't try though Mesa-3.4.1.
> > > > >
> > > > > On what driver?
> > > > >
> > > > > I've got the two X11 drivers running side by side & they look identical.
> > > > >
> > > > > Keith
> > > > >
> > > >
> > > > Just normal software-rendering.
> > > > 24bit TrueColor
> > > > Frame buffer: 24bit R8:G8:B8:A0
> > > >
> > > > I don't know what else could help.
> > >
> > > I'm seeing denser fog with 3.5 than 3.4.x too.  Strange thing is,
> > > I think it looked OK the first time I ran it but subsequent runs
> > > look different.  Might be an uninitialized variable somewhere.
> > > I'm looking into it.
> > >
> > > The fire demo seems to be the only demo w/ fog that looks different.
> > > Tunnel, for example, looks identical with 3.5 and 3.4.x.
> >
> > There's a call to glHint(GL_FOG_HINT, GL_NICEST) which is only
> > compiled in if FX is defined.  If the hint is GL_NICEST fog is OK.
> > But if the hint is GL_FASTEST or GL_DONT_CARE the fog is extra
> > dense.  That narrows it down...
> 
> One change is that swrast (in 3.5) now respects (or tries to respect) that
> hint -- previously the software rasterizer *always* did pixel fog, now it has
> the choice.
> 
> The driver can additionally configure swrast to match what the hardware is
> doing with _swrast_allow_vertex_fog() and _swrast_allow_pixel_fog().  I'll
> look over this functionality for unitialized values now.


I think I've gotten to the bottom of this.  GL_NICEST mode causes
the fog factor to be computed per-fragment from the fragment Z coordinate.
It works fine.

GL_FASTEST/DONT_CARE computes the fog factor per vertex then linearly
interpolates the factor across the triangle.  Thing about fire.c is
it draws one large polygon for the ground, most of which gets clipped
away.  We're just linearly interpolating the fog factor in the polygon
clipper.  Doing a perspective-corrected interpolation would probably
improve things.  OpenGL doesn't require perspective correct interpolation
during clipping and adding it to Mesa in this case could be a bit
complicated.

By subdividing the ground polygon into smaller quads the problem
effectively goes away.

I think I'll just clean up fire.c a bit and let it go at that.

-Brian