where is a spec bout this extension? its supported by my nvidia geforce2 mx…
btw, its NOT GL_EXT_texture_env_dot3, i tried to just use this… and its not working
Well, strange things are happening with the DOT3 extension. First, the GL_ATIX_texture_env_dot3 and GL_EXT_texture_env_dot3 appeared on Radeon cards. Then they removed the GL_ATIX_texture_env_dot3, which is now available on GF cards. The documentation for the GL_ATIX_texture_env_dot3 is also gone, I don’t know if it actually was available to public some peroid of time or not.
If you get the 6.50 drivers from our web site, EXT_texture_env_dot3 is supported. (As a result of various miscommunications and release timing issues, the 6.31 drivers exported the ATIX extension.)
Note that the enumerants for the EXT extension are different than those for the ATIX extension. The ATIX extension uses enumerants in the 0x6000-0x8000 range, which is reserved for non-shipping extensions. This explains why we wanted to remove the ATIX extension ASAP.
The dot3 spec is available on the extension registry.
- Matt
ok, ill try to download the new drivers (once again… every time my pc crashed (not the pc, the ie…))
tnx anyways
There is a very good reason why the ATIX version has been “disappearing”: it was never supposed to be shipped in the first place!
I don’t know whether any other ATIX extensions use 0x6000-0x8000 enumerants, but if they do, this should be a big-time warning flag that the extension is not complete and that you should not use it in any real applications.
- Matt
ok, ive the 6.5 drivers now, and there is NO dot3 anymore, no EXT and no ATIX…
ive the win2k drivers…
Oops, I screwed up. Turns out that I did only comment out the ATIX one, and not add the EXT one.
The first version with EXT_texture_env_dot3 is 6.60.
I put this in last October in the 6.xx source tree. We still haven’t officially released a Windows driver that exposes it (interestingly, our latest Linux drivers probably do include it). Go figure.
- Matt
any chance to get a driver for win2k wich has the ext soon?
why?
vertex_program… i want it, but its not supported… snif
register_combiners … nice, i got my phongshading, but for this i need 2 textures, means, the normalmap (could be bumpy), the normalizationcubemap (for the point->light vectors, for example)
and then i need a 3th texture, wich is the diffusecolor (i can do it with just one color, but heh!, who would do this!
texture_env (4)… nice, combining the 4 texturestages of my mx… but heh, where is my texture_env_dot3 going to!
and no, i dont want to do multipasses, i buyed a geforce to do real per pixel lighing, as they say, and on such a board i cant do real per pixel lighing in one pass, thats somehow stupid…
There are various leaked drivers beyond 6.60 on the web… 
- Matt
and no one gives a link… ok, i search em…
Originally posted by davepermen:
and no, i dont want to do multipasses, i buyed a geforce to do real per pixel lighing, as they say, and on such a board i cant do real per pixel lighing in one pass, thats somehow stupid…
Sorry to tell you, but if you want accurate lighting, you are gonna have to do multipass. If you absolutely must get single pass, then you will have to drop one of the 3 textures (probably the normalization cube map). But you will probably want to do the bumped lighting calculation and store the result in the alpha channel, then on the second pass use the diffuse texture, and blend it by multiplying with the destination alpha.
hm, as info, i HAVE 4 TEXTURESTAGES, means i CAN use 3 textures at a time, but just not in the register combiners… i’ve now 6.67 (or something like this), and the GL_EXT_texture_env_dot3 is working nicely…
Actually, you can do single-pass per-pixel lighting. One texture is a normal map, the other is a specular reflection lookup cubemap. I wrote this demo, and it was the first real NV10 demo ever written. So it can be done.
The formula I used, and the one you can get in one pass, is:
LdMd(N dot L) + LsMs(N dot H)^4 + La*Ma + Me
…where the L’s and M’s are all constants, where N comes from a texture, where L is constant (infinite light) and H is from a texture (local viewer).
- Matt
Originally posted by mcraighead:
[b]Actually, you can do single-pass per-pixel lighting. One texture is a normal map, the other is a specular reflection lookup cubemap.
The formula I used, and the one you can get in one pass, is:
LdMd(N dot L) + LsMs(N dot H)^4 + La*Ma + Me
…where the L’s and M’s are all constants, where N comes from a texture, where L is constant (infinite light) and H is from a texture (local viewer).[/b]
But you still need a third texture for the diffuse texture, unless you arent using one (which is pretty uncommon these days). Yes, I guess depending on how you are wording things, then I guess the LIGHTING can be done in a single pass, but you need an extra pass for the diffuse texture. Or if you want to do an infinite light, you can kill the normalization cubemap (since all 3 normals will be the same, therefore no shortening of interpolated normals). Or you can kill the bumpmap, but that kinda takes all the meaning out of “per-pixel”.
[This message has been edited by LordKronos (edited 02-08-2001).]
hm, as info, i HAVE 4 TEXTURESTAGES, means i CAN use 3 textures at a time, but just not in the register combiners.
Actually, that’s not true. The GeForce2 has 4 pixel pipelines that work in parallel, and each can do 2 texel multitexturing. So you only get two textures, but the hardware is drawing 4 different pixels at the same time.
j
I’m not saying it’s a perfect technique, but it does the job for that particular equation. Interestingly, it uses all of the register combiners’ resources on the RGB side. There are no spare textures or constant colors, both the primary and secondary colors are used, it fills both of the general combiners, it fills all the inputs in the final combiner, and it uses both the EF product and the spare0+secondary register. In terms of efficiency in taking advantage of the HW, it is hard to do much better.
Mark Kilgard’s bumpdemo and md2shader illustrate quite well how to apply these techniques to more general cases. I only handled the flat surface, infinite light, local viewer, no diffuse material texture case. md2shader has an arbitrary polygonal model and both diffuse and specular material textures.
- Matt
Originally posted by mcraighead:
Interestingly, it uses all of the register combiners’ resources on the RGB side. There are no spare textures or constant colors, both the primary and secondary colors are used, it fills both of the general combiners, it fills all the inputs in the final combiner, and it uses both the EF product and the spare0+secondary register. In terms of efficiency in taking advantage of the HW, it is hard to do much better.
Mere coincidence? I think not. At first glance, the configuration of the register combiners seems so arbitrary. Yet, after digging so deep into it, I am surprised again and again just how well it can handle most equations(they always seem to just barely fit). There was definitely some good thinking put into their design.
hm, but when i take a look at maxtexturestages, i have 4
What is “maxtexturestages”?
- Matt