mesa3d-dev

[Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

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

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've tested EXT_fog_coord with ATI's demo, after some de-windows-ing.

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.

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)?

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.

Keith

Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

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

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

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

Re: [Mesa3d-dev] EXT_fog_coord, EXT_secondary_color

[Michael V. <bri...@lo...>]

On Fri, Oct 27, 2000 at 12:46:32PM -0600, Keith Whitwell wrote:

> 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.  

The w-value is always 1 (or 0, can't remember) for vertices in an
orthographic projection, and the 3Dfx card uses the w-value for
indexing into the fog table--thus everything is fogged with the fog
color from entry 1 (or 0).

In the past, Brian and Daryll mentioned using an alternatve fogging
method available in Glide3 (a z fogging method), but I don't believe
it was pursued.

m.

-- 
Programmer             "Ha ha." "Ha ha." "What are you laughing at?"
Loki Software                      "Just the horror of being alive."
http://lokigames.com/~briareos/                   - Tony Millionaire

[Mesa3d-dev] Fog on tdfx (was: GL_EXT_fog_coord, etc.)

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

Michael Vance wrote:
> 
> On Fri, Oct 27, 2000 at 12:46:32PM -0600, Keith Whitwell wrote:
> 
> > 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.
> 
> The w-value is always 1 (or 0, can't remember) for vertices in an
> orthographic projection, and the 3Dfx card uses the w-value for
> indexing into the fog table--thus everything is fogged with the fog
> color from entry 1 (or 0).
> 
> In the past, Brian and Daryll mentioned using an alternatve fogging
> method available in Glide3 (a z fogging method), but I don't believe
> it was pursued.


In glide.h we see this:

typedef FxI32 GrFogMode_t;
#define GR_FOG_DISABLE                     0x0
#define GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT  0x1
#define GR_FOG_WITH_TABLE_ON_Q             0x2
#define GR_FOG_WITH_TABLE_ON_W             GR_FOG_WITH_TABLE_ON_Q
#define GR_FOG_WITH_ITERATED_Z             0x3
#define GR_FOG_WITH_ITERATED_ALPHA_EXT     0x4
#define GR_FOG_MULT2                       0x100
#define GR_FOG_ADD2                        0x200

So using GR_FOG_WITH_TABLE_ON_Q or GR_FOG_WITH_TABLE_ON_W is the
same and neither works with orthographic projection since the W
value is always 1.0.

I'm thinking that if we're using orthographic projection that we
could use GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT (available on Voodoo3
and later, don't know about Banshee or Voodoo1/2) if we added a
fog coord to the Glide vertices and computed it from the vertex Z
somewhere in the vertex setup code.

I think this would be much more easily done in the new tdfx-3-0-0
driver than the current driver.

Gareth, could we put GR_FOG_COORD into the vertex struct where
we currently have a GLuint padding?  I haven't examined the vertex
layouts very much yet.

I can't find any documentation for GR_FOG_WITH_ITERATED_Z but I'd
guess that f (fog factor) is just a multiple of the fragment's Z and
can only be used for GL_LINEAR fog if near=0 and far=1.

-Brian

[Mesa3d-dev] Re: [Dri-devel] Fog on tdfx (was: GL_EXT_fog_coord, etc.)

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> I'm thinking that if we're using orthographic projection that we
> could use GR_FOG_WITH_TABLE_ON_FOGCOORD_EXT (available on Voodoo3
> and later, don't know about Banshee or Voodoo1/2) if we added a
> fog coord to the Glide vertices and computed it from the vertex Z
> somewhere in the vertex setup code.
> 
> I think this would be much more easily done in the new tdfx-3-0-0
> driver than the current driver.
> 
> Gareth, could we put GR_FOG_COORD into the vertex struct where
> we currently have a GLuint padding?  I haven't examined the vertex
> layouts very much yet.

Yes.  It's on my tdfx-3-0-0 todo list (which, unfortunately, is still
rather long).

I can look into this sooner rather than later if you like.  I'm
travelling again today, but was going to investigate the 32bpp
performance hit tonight.  It should be fairly easy to hook up the fog
coordinate stuff, especially since we've got a place for it in the
default vertex structure already.

-- Gareth