Re: [Dri-devel] GL_ATI_envmap_bumpmap
Ryan Underwood wrote: GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? ATI's drivers do support it, but Mesa does not. This would be a useful extension to have in Mesa since R100, R200, G400, and i830 all support it in hardware. I looked at adding support for it once. The main barrier is that the DUDV texture formats (which are the same as the DSDT texture formats in NV_texture_shader) are *signed*. Mesa doesn't currently have any support for signed texture formats. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
Ian Romanick wrote:
Ian Romanick wrote:
Ryan Underwood wrote:
GL_ATI_envmap_bumpmap seems to describe identical functionality to
DirectX6 EMBM. ATI's drivers support this extension and it is
implemented in Mesa apparently. Does anyone know of a demo or sample
code that utilizes this extension?
ATI's drivers do support it, but Mesa does not. This would be a
useful extension to have in Mesa since R100, R200, G400, and i830 all
support it in hardware. I looked at adding support for it once. The
main barrier is that the DUDV texture formats (which are the same as
the DSDT texture formats in NV_texture_shader) are *signed*. Mesa
doesn't currently have any support for signed texture formats.
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from the
texture. We'd either have to add a new function to fetch raw, signed
DSDT data or do some sort of trickery. The GL_ATI_envmap_bumpmap says
that fetch color data from a DSDT texture give {0,0,0,1}. Since I
didn't see an obvious, architecturally clean way to do it, and I already
had (have!) a lot of other stuff on my plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need
to apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
-Brian
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
Brian Paul wrote:
Ian Romanick wrote:
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from the
texture. We'd either have to add a new function to fetch raw, signed
DSDT data or do some sort of trickery. The GL_ATI_envmap_bumpmap says
that fetch color data from a DSDT texture give {0,0,0,1}. Since I
didn't see an obvious, architecturally clean way to do it, and I
already had (have!) a lot of other stuff on my plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need to
apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
That would do the trick. I guess the default internal type for DSDT
textures would be GLfloat instead of GLchan?
That doesn't solve the whole problem for DSDT textures (or depth
textures?), though. If a DSDT texture is bound to a texture unit, the
idea is that the texture environment will be set up to have the output
of that texture unit modify the texture coordinates for some other unit.
However, it is still possible to use that texture unit in the regular
(color) blending environment. In that case, the color is supposed to be
{0,0,0,1}, not {DS, DT, 0, 1} or some such.
I guess if the float-point fetch function is only used for depth, DSDT,
and fragment programs it should be okay. The various other (primarilly
SGI) extension that add either signed or floating point textures to the
classic fragment pipeline probably aren't too interesting anymore.
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
Ryan Underwood wrote: On Wed, Jan 21, 2004 at 12:23:17AM +0200, Ville Syrjälä wrote: On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... You're right, I was looking only at glext.h. My intent was to implement it to the mga driver too because it is sort of a unique functionality that can create some nice eye candy. A secondary intent was to implement DX6 EMBM in WINE and pass it through to this extension if available. That way you could run DX6+ games that utilize EMBM in WINE. Does that extension really provide all of DX6 EMBM? I seem to recall there being that modified the texture coordinates AND had an intensity (or is it luminosity?) value. The ATI extension doesn't have that. It could be simulated on ATI hardware by using an extra texture blend stage. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
Ian Romanick wrote:
Brian Paul wrote:
Ian Romanick wrote:
Let me elaborate on that a bit. Texture data with a format of
GL_DUDV_ATI should have a type of GL_BYTE. All of the signed types,
like GL_BYTE, have a range of [-1,1]. In all existing cases, texture
data has a range of [0,1]. When Mesa gets a texture of GL_BYTE, it
modifies each value by (x+128)*2 to convert it to a GL_UNSIGNED_BYTE.
Each texture has a function to fetch raw, unsigned color data from
the texture. We'd either have to add a new function to fetch raw,
signed DSDT data or do some sort of trickery. The
GL_ATI_envmap_bumpmap says that fetch color data from a DSDT texture
give {0,0,0,1}. Since I didn't see an obvious, architecturally clean
way to do it, and I already had (have!) a lot of other stuff on my
plate, I left off there.
One of these days I'm going to add support for signed/floating point
texture formats. They'd be pretty handy in conjuction with fragment
programs.
I'll probably wind up adding new texel Fetch functions that return 4
GLfloats.
Fetching DSDT texels as floats would probably be good since you need
to apply a floating point rotation matrix to the fetched texel.
How does that sound, Ian?
That would do the trick. I guess the default internal type for DSDT
textures would be GLfloat instead of GLchan?
The internal type could be anything. I'm just saying that the Fetch
function would return floating point data.
That doesn't solve the whole problem for DSDT textures (or depth
textures?), though. If a DSDT texture is bound to a texture unit, the
idea is that the texture environment will be set up to have the output
of that texture unit modify the texture coordinates for some other unit.
However, it is still possible to use that texture unit in the regular
(color) blending environment. In that case, the color is supposed to be
{0,0,0,1}, not {DS, DT, 0, 1} or some such.
Sure, adding signed float texture support doesn't solve the whole
problem, but I think it's a good first step.
I guess if the float-point fetch function is only used for depth, DSDT,
and fragment programs it should be okay. The various other (primarilly
SGI) extension that add either signed or floating point textures to the
classic fragment pipeline probably aren't too interesting anymore.
I think we're on the same page.
-Brian
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] GL_ATI_envmap_bumpmap
Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] GL_ATI_envmap_bumpmap
--- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? I'm not sure of an app that uses it, but as I recall mga g4xx cards could, in theory, support that extension as well since they had dx6 EMBM support. Alex -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_ATI_envmap_bumpmap
On Wed, Jan 21, 2004 at 12:23:17AM +0200, Ville Syrjälä wrote: On Tue, Jan 20, 2004 at 03:47:49PM -0600, Ryan Underwood wrote: Hi, GL_ATI_envmap_bumpmap seems to describe identical functionality to DirectX6 EMBM. ATI's drivers support this extension and it is implemented in Mesa apparently. Does anyone know of a demo or sample code that utilizes this extension? Last time I looked Mesa didn't support this extension. My plan was to add bumpmap support to the mga driver if/when someone added the relevant Mesa bits... You're right, I was looking only at glext.h. My intent was to implement it to the mga driver too because it is sort of a unique functionality that can create some nice eye candy. A secondary intent was to implement DX6 EMBM in WINE and pass it through to this extension if available. That way you could run DX6+ games that utilize EMBM in WINE. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
