Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

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

Brian Paul wrote:
> 
> Keith Whitwell wrote:
> >
> > I've implemented these two extensions.  EXT_secondary_color hasn't been hooked
> > into dispatch, and so hasn't been tested & isn't enabled yet.
> 
> I'm getting some compile errors in the FX driver:
> 
> FX/fxcva.c: In function `fxDDMergeAndRender':
> FX/fxcva.c:482: structure has no member named `Specular'
> 
> FX/fxsetup.c: In function `fxSetupFog':
> FX/fxsetup.c:1438: structure has no member named `FogMode'
> FX/fxsetup.c:1438: `FOG_FRAGMENT' undeclared (first use in this function)
> FX/fxsetup.c:1438: (Each undeclared identifier is reported only once
> FX/fxsetup.c:1438: for each function it appears in.)
> 
> FX/fxvs_tmp.h:152: structure has no member named `FogMode'
> FX/fxvs_tmp.h:152: `FOG_FRAGMENT' undeclared (first use in this function)
> 
> Commenting-out references to VB->Specular, and ctx->FogMode fixes the
> compile-time problems.

I'll check out why this wasn't committed.

> > I've tested EXT_fog_coord with ATI's demo, after some de-windows-ing.
> 
> It would be nice to have a demo of fog_coord and secondary_color in
> Mesa/demos/.  Hint, hint. :)
> 
> > The treatment of fog in the software rasterzer has changed somewhat.  The
> > trick of merging fog colors into vertex colors during the vertex pipeline has
> > been removed.  This wasn't happening for any of the accelerated drivers (FX,
> > utah or dri), to my knowledge, as any driver that asserted it has hardware fog
> > would disable this stage.   We can do this inside the triangle functions if
> > anyone decides they want to.
> 
> Merging fog colors into vertex colors was really only legal when not
> using texturing anyway (or at least particular tex env modes).
> 
> > I was unwilling to play with the logic for choosing line/point/triangle
> > functions at this point, so the fog coordinate will be interpolated whenever z
> > is interpolated.  This is wasteful & will probably be fixed before too long.
> >
> > Brian:  It occurs to me that calculating a fog factor at the vertices and
> > interpolating linearly across the triangle is less accurate than doing the fog
> > equation at each pixel.  Is there a requirement to do it per pixel (in certain
> > hint modes, for instance)?
> 
> That's what GL_FOG_HINT controls.  GL_NICEST implies doing it per-pixel,
> but implementations are allowed to ignore hints entirely.

It's a simple change to get perpixel fog back.  I still have to be able to fog
pixels based on z values for drawing bitmaps etc.

> > Drivers with table fog don't need fog calculations except during fallbacks.
> > The FX driver has an example of how this can be done, though further testing
> > of this is required.
> >
> > Drivers with fog in the 4th component of specular color (mga, i810, r128) no
> > longer need to fiddle with the pipeline to get fog coordinates, as this is now
> > the standard mechanism for calculating fog at the vertices.
> 
> Is this expected to fix the problem with fog not working when using an
> orthographic projection in the 3dfx driver?

Not really.  The FX driver basically turns this code off as the hardware
normally fogs from the z or 1/w values (I can't remember which).  I'm sure
it's just a matter of setting up the fog table correctly for orthographic
projections & making sure that some usable value gets into the vertex format.  

I don't really know much about how table fogging on the tdfx cards works...

Keith