mesa3d-dev

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

[Holger W. <hwa...@ya...>]

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

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

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 ?)
Can those modes be accelerated by 3dfx, Matrox and ATI cards ?

- Holger

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

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

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

[I think I accidently deleted part of my reply]


Brian Paul wrote:
> 
> 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.

A new extension for doing the dot product, that is.  Perhaps call it
GL_MESA_texture_env_dot3.  In fact, you could implement the dot3
extension without GL_EXT_texture_env since there's no dependency.


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

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

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

Brian Paul wrote:
> 
> 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.

I also believe this is true.

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

Holger, are you planning on doing this?  It should be fairly straight
forward.

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

Brian's idea of a new/separate GL_MESA_texture_env_dot3 extension would
be the best way to handle this.

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

I'll take a look at some of the hardware specs I have today.

-- Gareth

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

[Holger W. <hwa...@ya...>]

On Tue, 20 Jun 2000, Gareth Hughes wrote:

> > 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.
> 
> Holger, are you planning on doing this?  It should be fairly straight
> forward.

I'll implement EXT_texture_env_combine instead. I hope, I have something
working until next week. The EXT_texture_env API can be expressed in terms
of EXT_texture_env_combine, but I'm not shure if this makes sense.
As far I know yet, Mesa would be the only OpenGL implementing this 
extension. It's a bit easier to use, but less flexible.


> > I'd implement GL_EXT_texture_env as-is.  Then, perhaps design a new
> > extension.
> 
> Brian's idea of a new/separate GL_MESA_texture_env_dot3 extension would
> be the best way to handle this.

I will write this extension so that it defines a new mode for
EXT_texture_env_combine.


> > Don't know.  Better find out before writing GL_MESA_texture_env_dot3
> > though.
> 
> I'll take a look at some of the hardware specs I have today.

This would be great.
Could you look, if all other modes are supported, too ??

- Holger

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

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

Here's a link to some new NVIDIA demos, including a dot3 bumpmapping one
with source:

http://www.nvidia.com/marketing/developer/devrel.nsf/TechnicalDemosFrame?OpenPage

-- Gareth