Re: [Mesa3d-dev] a 'better EXT_texture_env' for Mesa

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

Holger Waechtler wrote:
> 
> Hi,
> 
> I'm still thinking about how to accelerate per pixel lighting and bumpmapping
> on current hardware.
> 
> A problem arising in bumpmapping using current OpenGL implementations is at
> least the missing SUBTRACT texenv mode. The nVidia register combiner
> extension provides a solution, but are neither easy to use nor portable to
> other cards. The other way is defined by GL_EXT_texture_env, but at least
> Mesa doesn't has it yet.
> 
> Brian pointed me out that EXT_texture_env_combine may be a more common
> solution (the nVidia driver already has it -- it's designed for their
> cards), but I first have to read this again ...

I have reason to believe that GL_EXT_texture_env_combine will be supported
by several vendors in the future, if they don't already.


> However, it should be quite easy to add GL_EXT_texture_env to Mesa. It
> defines the following modes (new are only SUBTRACT, REVERSE_SUBTRACT and
> REVERSE_BLEND -- I have no idea, for what COPY should be good ...):
> 
>         Cv = Cf                                   COPY
>         Cv = Ct                                   REPLACE
>         Cv = Cf * Ct                              MODULATE
>         Cv = Cf + Ct                              ADD
>         Cv = Cf - Ct                              SUBTRACT
>         Cv = Ct - Cf                              REVERSE_SUBTRACT
>         Cv = aCf + (1-a)Ct                        BLEND
>         Cv = aCt + (1-a)Cf                        REVERSE_BLEND

I agree that it would be pretty simple to add these new modes to the
software renderer.  Off-hand I don't know which of the cards supported
by the DRI could support them.  If you implement GL_EXT_texture_env
just send me a patch.


> Additionally a dotproduct mode would make per pixel lighting possible
> (D3D has one, so why don't we have ?? -- it seems to be accelerated by
> hardware at least on nVidia's new cards):
> 
>         Cv = Rf*Rt+Gf*Gt+Bf*Bt                    DOTPROD3
> 
> Input components are understood as they were scaled and biased by 128, so
> their range [0,255] is mapped to [-1.0,1.0]:
> 
> Results will be scaled as defined in EXT_texture_env, then clamped and
> written into the R, G and B component of Cv. It can be used now as light
> map to modulate another texture.
> 
> I'd really like to hear your comments before I start any coding.
> Shall we define a complete new spec as superset of EXT_texture_env ?
> (was this ever implemented yet ?)

I'd implement GL_EXT_texture_env as-is.  Then, perhaps design a new
extension.


> Can those modes be accelerated by 3dfx, Matrox and ATI cards ?

Don't know.  Better find out before writing GL_MESA_texture_env_dot3 
though.

-Brian