Menu
▾
▴
mesa3d-dev
|
From: ralf w. <b_...@gm...> - 2000-06-06 09:43:12
Attachments:
mesa_perpixel.txt
|
attached are my thoughts on a bumpmapping extension for mesa. i would like to hear some opinions :> i am thinking about poor loki entertainment when they have to port a game that uses the directX bumpmapping function. -- ralf willenbacher (bj...@oc...) oops.. mesa3d is now at sourceforge.. |
|
From: Brian P. <br...@pr...> - 2000-06-13 00:26:26
|
ralf willenbacher wrote:
>
>
> attached are my thoughts on a bumpmapping extension for mesa.
> i would like to hear some opinions :>
> i am thinking about poor loki entertainment when they
> have to port a game that uses the directX bumpmapping function.
I'm not familiar with DirectX's bumpmapping. Is your extension
a copy of it?
My comments follow.
> i ripped this style from texgen_emboss from nvidia
>
> Name
> MESA_perpixel_lighting (or MESA_anisotropic_blending)
>
> Extension String
> GL_MESA_perpixel_lighting (or GL_MESA_anisotropic_blending)
>
> Dependencies
> ARB_multitexture.
>
> Overview
> The extension allows lumination per pixel of textures depending on 4 direction vectors.
> Its done with a texture containing height differences of X and Y (U/V) in texture space.
> The texture may contain a third component that specifies the reflection of the surface material.
>
>
> Issues
>
> why depending on arb_multitexture ?
> most hardware implements anisotropic lighting in the second texture stage and outputs
> the luminance to the first.
Huh?
> it cannot be used as the first texture stage because
> then someone might want to use the second texture stage for something else which would require
> another pass in the driver (is this really that bad ?). could be used in single texture mode too
> for flat triangles with carvings on it.
I don't see any dependency on multitexture for this extension.
> perpixel or anisotropic ?
> dunno.. anisotropic will make some people to run for dictionaries.
I'm not sure either name is really accurate.
> New Procedures and Functions
>
> glLightDirectionMESA(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
> sets the direction the light is shining on the surface.
> is clamped to -1.0/1.0
> negative numbers mean darken, positive brighten.
> defaults to 0.0, 0.0, 0.0, 0.0
You aren't defining a light direction so much as four blending weights.
Perhaps glBlendWeightsMESA(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
> New Tokens
>
> GL_DXDYDL (or DUDVL ?)
> defines a texture format to load an image containing delta X(U), delta Y(V) and
> material luminance (L).
> to be used in glTexImage2D
> DX and DY are signed, L is unsigned.
>
> GL_DXDY (or DUDV)
> the same without luminance.
>
> GL_FUNC_PERPIXEL_LIGHTING (or _ANISOTROPIC)
> to be used in glBlendEquation. could be a problem bacause it clashes with glBlendFunc...
I would think that this feature would be implemented in the texture environment,
not in the fragment blending stage. I.e. GL_FUNC_PERPIXEL_LIGHTING would really
be a glTexEnv mode.
> for hardware that does not have native bumpmapping (oops.. um.. perpixel..
> anisotropic.. emboss.. nvidia magic) support an internal texture format might be
> specified that contain 4 seperate luminance maps to be applied seperate to the
> framebuffer/ first stage texture. could be left to the drivers though..
>
> the following additions to the opengl specification could be wrong
> because the 1.2 .pdf looks funny in xpdf. i will stick to name in braces
>
> Additions to Chapter 2 of the 1.2 Specification (OpenGL Operation)
>
> when glTexImage2D is called with either GL_DXDYL or GL_DXDY the incoming pixels will
> be converted to byte size. when luminance is not given (GL_DXDY) a luminance of
> 255 (full luminance) will be assumed. DX and DY will be clamped to -127/127
> when a border is given the bordercolor will be taken as DX,DY,L. alpha will be ignored.
It's against the grain of OpenGL to specify the internal storage format for
something like this. I'd just say that the image is stored internally with
values in [-1, 1] and indeterminate precision.
> Additions to Chapter 3 of the 1.2 Specification (Rasterization)
>
> in single texture mode where the blendequation is GL_FUNC_PERPIXEL the lumination
> will be applied to
> the frame buffer like a GL_LUMINANCE texture.
>
> the luminance from the GL_FUNC_PERPIXEL blending equation is calculated like this:
> incoming texture is of type GL_DXDYL, left, right, top, bottom is set by glLightDirectionMESA
>
> for every pixel
>
> dX = DX / 127.0
> dY = DY / 127.0
> l = L / 255.0
>
> luminance = 1.0 ; start with no luminance
>
> if(dX >= 0.0) luminance += left*dX
> else luminance += right*(-dX)
> if(dy >= 0.0) luminance += top*dY
> else luminance += bottom*(-dY)
>
> luminance *= l;
>
> the destination pixel RGBA
> R*l, G*l, B*l, Alpha is unchanged.
>
> in the multitexture case the destination will be the first texture stage..
Here's how I would phrase it:
let dx, dy = the sampled texture value
luminance = 1.0
if(dX >= 0.0) luminance += left*dX
else luminance += right*(-dX)
if(dy >= 0.0) luminance += top*dY
else luminance += bottom*(-dY)
luminance *= l;
let (R, G, B, A) be the texture unit's incoming fragment color.
The outgoing fragment color (R', G', B', A') is then:
R' = R * l
G' = G * l
B' = B * l
A' = A
That said, however, I don't see how this extension is really going to work.
I think I can see this working on a planer polygon, with the four blend
weights getting recalculated depending on the surface orientation. But how
is it supposed to work for a non-planar surface? The luminance calculation
has to be dependent on the polygon's orientation with respect to the light
position. Either the DXDV data or the blend weights would have to be modified
per polygon. Or maybe determine which parts of the texture get mapped to which
triangles and modify the DX DY values accordingly (sounds hard).
Finally, is it your expectation that this feature can be implemented in terms
of current hardware? Or, is it supposed to be a software solution. I don't
think either is practical.
-Brian
|
|
From: Holger W. <hwa...@ya...> - 2000-06-13 16:17:01
|
ralf willenbacher wrote: > > attached are my thoughts on a bumpmapping extension for mesa. > i would like to hear some opinions :> What do you think about implementing GL_EXT_texture_perturb_normal ?? GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting would have to be written first, but it's the better solution in my mind. If you go this way, I would be glad if I could help implementing one or two of those extensions. - Holger |
|
From: Gareth H. <ga...@pr...> - 2000-06-13 16:26:23
|
Holger Waechtler wrote: > > ralf willenbacher wrote: > > > > attached are my thoughts on a bumpmapping extension for mesa. > > i would like to hear some opinions :> > > What do you think about implementing GL_EXT_texture_perturb_normal ?? > > GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting > would have to be written first, but it's the better solution in my mind. > If you go this way, I would be glad if I could help implementing one or > two of those extensions. I still haven't heard back from SGI regarding permission to implement EXT_light_texture or EXT_fragment_lighting, but I haven't chased it up in a while... -- Gareth |
|
From: Brian P. <br...@pr...> - 2000-06-13 16:42:13
|
Holger Waechtler wrote:
>
> ralf willenbacher wrote:
> >
> > attached are my thoughts on a bumpmapping extension for mesa.
> > i would like to hear some opinions :>
>
> What do you think about implementing GL_EXT_texture_perturb_normal ??
>
> GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting
> would have to be written first, but it's the better solution in my mind.
> If you go this way, I would be glad if I could help implementing one or
> two of those extensions.
I have some concerns about implementing these extensions:
1. Will any of these extensions map onto current hardware? None that I
know of.
2. There are patent issues associated with them.
3. They're somewhat complicated and I worry about implementation problems.
4. I don't know of any other GL that implements these extensions.
I'd like to see an extension spec for NVIDIA's new per-pixel lighting feature.
That might be more interesting/useful.
-Brian
|
|
From: Holger W. <hwa...@ya...> - 2000-06-14 12:02:56
|
On Tue, 13 Jun 2000, Brian Paul wrote: > Holger Waechtler wrote: > > I have some concerns about implementing these extensions: > 1. Will any of these extensions map onto current hardware? None that I > know of. Shure, but if next generation cards may be designed for this. Do you know a graphics chip designer we might ask ? > 2. There are patent issues associated with them. Who is owning the patents ? > 3. They're somewhat complicated and I worry about implementation problems. Yes, but the design is clean and we have the spec now. As far I have seen, a new triangle rasterizer would have to be implemented, which interpolates normals and light texture parameters. > I'd like to see an extension spec for NVIDIA's new per-pixel lighting feature. > That might be more interesting/useful. That's the other way. Who knows, where to get this ? - Holger |
|
From: Stephen J B. <sj...@li...> - 2000-06-13 20:00:21
|
On Tue, 13 Jun 2000, Holger Waechtler wrote: > > ralf willenbacher wrote: > > > > attached are my thoughts on a bumpmapping extension for mesa. > > i would like to hear some opinions :> > > What do you think about implementing GL_EXT_texture_perturb_normal ?? > > GL_EXT_light_texture, GL_EXT_coordinate_space and GL_EXT_fragment_lighting > would have to be written first, but it's the better solution in my mind. > If you go this way, I would be glad if I could help implementing one or > two of those extensions. Whatever you implement needs to be something that at least *some* hardware can support - which means that we should be using some of the existing extensions rather than inventing new ones. Also, if you stick with existing extensions, there is a better chance that programs not specifically written for Mesa will take advantage of this new code. Note that Mesa is no longer the only game in town for Linux users - the nVidia driver already has bump-map extensions - and I fully intend my programs to make use of them. You should be able to find out all about the nVidia extensions (for example) at the www.opengl.org site. --ooOOoo-- Please note the change in my email address (was hti.com - now link.com) Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: ralf w. <b_...@gm...> - 2000-06-14 11:25:32
|
Stephen J Baker wrote: > You should be able to find out all about the nVidia extensions (for example) > at the www.opengl.org site. > nvidia writes extensions specific to their hardware.. so does sgi. i wanted something simple. -- ralf willenbacher (bj...@oc...) |
|
From: Scott M. <mcm...@ca...> - 2000-06-14 13:54:04
|
I don't know if this is coincidence or not, but Slashdot posted a pointer to an article at tweak3d.net about the various kinds of bump mapping. At one point the article mentions that the G400 can do Environment Mapped Bump Mapping: "This feature was first introduced in Matrox's G400 graphic card series and the upcoming RadeOn GPU from ATI is expected to implement EMBM as well." Check out: http://www.tweak3d.net/articles/bumpmapping/ -- Scott McMillan mailto:mcm...@ca... Cambridge Research Associates http://www.cambridge.com 1430 Spring Hill Road, Ste. 200 Voice: (703) 790-0505 x7235 McLean, VA 22102 Fax: (703) 790-0370 |
|
From: Holger W. <hwa...@ya...> - 2000-06-14 16:26:46
|
Hi, on http://www.nvidia.com/Marketing/Developer/DevRel.nsf/TechnicalDemosFrame?OpenPage you find various demos and algorithms for different approaches to bump mapping without the need of a special extension. However, non of them does a real per pixel lighting or is able to change light parameters over a triangle. - Holger |
|
From: Holger W. <hwa...@ya...> - 2000-06-14 12:03:53
|
On Tue, 13 Jun 2000, Stephen J Baker wrote: > Whatever you implement needs to be something that at least *some* hardware > can support - which means that we should be using some of the existing > extensions rather than inventing new ones. Does any current card supports a 'real' per pixel lighting ? I believed phong shading is usually implemented by multitexturing using the modulating texture as exponential lookup table. > Also, if you stick with existing extensions, there is a better chance > that programs not specifically written for Mesa will take advantage > of this new code. Note that Mesa is no longer the only game in town > for Linux users - the nVidia driver already has bump-map extensions - and > I fully intend my programs to make use of them. Simple bumpmapping can be implemented on usual consumer cards using multitexturing without any additional extension. On nVidia's website was a 'GLBump' demo a while ago (don't know, if it's still there ...), which shows a simple and straightforward implementation of this. Does anybody knows where to get the spec to nVidias bumpmapping extension ? I never heard about it until now. - Holger |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X