From: Brian P. <br...@va...> - 2000-10-27 17:36:07
|
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'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. > 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? I'll take care of the SecondaryColor dispatch code as soon as I get the dispatch offsets. Thanks! -Brian |