Re: [Mesa3d-dev] Fog still different

[Keith W. <ke...@va...>]

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.

Keith