glGetInteger(GL_MAX_TEXTURE_UNITS_ARB (or somthing like this…),&maxTex);
…and the value of that is most definitely 2.
Originally posted by mcraighead:
What is “maxtexturestages”?
It’s from Direct3D
yep… currently with this drivers wich supports the env_dot3, it is 2, but before, with the old (original) ones, it whas 4…
i buyed the mx because there are more than two texturestages, cause thats all i wanted… and now i’m sitting here with some hardware, wich is fast… (really fast…), but CANT do perpixellighting… multipassing is a joke…
vertexlighing is done in ONE pass, and real perpixellighing should be possible in ONE pass, every thing else is just a fake, and i dont like to be faked (if this word egists like this…)
for gamers its not really important but for guys who want to work with the hardware… i now even prever the old matrox with its environment_bump, with it (ok, combined with cube_maps), you can do real perpixellighing with bumpmaps
the ati radeon is currently the best thing for working with i think… the register combiners are the biggest joke ever seen… i do understand how to use them… but when i got my nice bumpmapping, there is nothing left to do some colorisation over it…
GL_VARIABLE_A_NV to G_NV… and just 2 textures…
i’m not sure, but there are two possibilities for real perpixellighting:
more textures than texture0 and texture1 _arb, or GL_SGIX_fragment_lighting… means first of all normalization of the interpolated normal… that would be best at all… (pixelshaders can do such nice things… but no hw yet…)
now i just hope next gpu of nvidia does really what it says it does…
I have NEVER seen drivers that reported 4 texture units. If your drivers did, then I would bet you have some hacked drivers that arent from nvidia.
Why is multipass a joke. There is nothing wrong with multiple passes. Dont try to get all high and mighty on not doing multipass. Its gonna be a while before you can do everything in a single pass. Even if the NV 20 gives us 4 texture units, there will still be plenty of reasons to do multipass then. How about the following “realistic” lighting.
Tex0: Diffuse color texture (RGB) and gloss map (Alpha)
Tex1: Light vector normalization cube map
Tex2: Half-angle vector normalization cube map
Tex3: Bump map
Tex4: Distance attenuation map
Tex5: Environment reflection cube map
Tex6: Detail map
So if you really want to get realistic, you are gonna need lots more texture units. And this only counts single lights. What happens when 2 lights are illuminating the same polygon. Either you FAKE it (somehow average the lighting) or you bite the bullet and do more passes (or you get high and mighty and wait until the graphics card with 83 texture units comes out).
And to say that you prefer the matrox because it supported real perpixel lighting. Im sorry that you dont like fakes, becuase Im gonna have to burst your bubble here and let you know that EMBM is one of the biggest lighting fakes there is. Does it look good…reasonably yes, but it is actually QUITE inaccurate.
As for the radeon being better, well thats a matter of preference and of situation. If you are JUST trying to do diffuse lighting with a diffuse texture, bump map, and light vector normalization cube map, then yes, you will probably find the radeon somewhat better. But in general the register combiners get you a lot more. With the radeon, you can use whatever extensions they give you to do things with. However, with the register combiners, you have complete control over the math that is used to combine the textures. This presents itself with a lot of opportunity for coming up with implementing unique ideas. The radeon doesnt even begin to give you the same flexibility as the register combiners, and it came out several months (8, I think) after the original GeForce.
[This message has been edited by LordKronos (edited 02-09-2001).]
To follow up on the ATIX_texture_env_dot3 vs. EXT_texture_env_dot3 discussion:
In order to quickly get extensions available to ISVs and before the spec’s have been solidified, we use the ATIX (X = experimental, which also means subject to change) naming convention. These extensions are NOT meant to be used in shipping products and are there for experimental purposes only.
With ATIX_texture_env_dot3, once we got support from multiple vendors and solidified the spec, we EXT’d the extension and used official enumerants from SGI.
There are several more ATIX extensions in the pipe…please understand that until these are made ATI, EXT, or ARB, they should not be used in shipping products. The reason for this decision is we needed a quick way to get extensions out the door before finalizing specs and getting official enumerants.
I hope this hasn’t caused too much confusion. Thanks.
[This message has been edited by dginsburg (edited 02-09-2001).]
i’m sorry, but what do the register combiners for us? two texturestages are just not enought, even with the register combiners… (ok, they are nice, right, but at the end its first of all a predefined function with alot of settings… )
i just dont like multipassing cause it just shows where the end of the gpu is, and its BEVORE perpixellighting… even with one simple light… and thats stupid somehow…
glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_RGB_ENV_EXT (?!not sure ), GL_COMBINE );
the first combiner (the one in texture0) has to be GL_REPLACE, not? so you can just set the second one (the one in texture1), right?.. damn…
If you think multipass is a joke, talk to Carmack. His next game will have a ridiculously large amount of multipass.
Well, for anyone who disputes the usefulness of register combiners, I challenge you: port Mark Kilgard’s md2shader app to any currently shipping non-NVIDIA hardware and see whether it takes you more or fewer rendering passes. Make sure you take all the effects into account, including specular lighting, proper specular clamping, the gloss map, all of the per-triangle math,
Or, simpler, port my one-pass per-pixel specular lighting equation to any currently shipping non-NVIDIA hardware. I can guarantee in advance that you will have a lot of trouble doing it in even 2 passes.
The dot3 extension is all right if you want to do plain old diffuse lighting. However, specular is where it’s at, and for specular, the extra computations of register combiners really help out.
Not to mention all of the other novel uses of register combiners that people have found. Mark Kilgard did not only per-pixel shading on arbitrary polygonal models, but also 16-bit shadow maps. We’ve also seen correct self-shadowing bump maps that use register combiners, and all sorts of other fancy computations.
And to think, this is all on hardware that came out in September 1999.
And the gloves come off. Pick your corner everyone.
Seriously, the register combiners are outragously flexible. You can use them to perform all kinds of tricky things. Just a few weeks ago (in the thread “OGL blending”), I figured out a way to do
abs(tex0-tex1) for someone in a single pass. Im sure that wasnt in the mind of the designers when they made the register combiners. Seems everytime I come up with some ridiculous idea, after enough though I find that the idea isnt so ridiculous using the register combiners.
While the register combiners certainly are very useful and flexible a third texturing unit also provides it’s own set of advantages. With a two texturing unit setup you cannot for example have more than two textures combined before the framebuffer content is lost. This puts some constraints on what effects you can apply to translucent surfaces.
sure, you can do nice things with the regcombiners, i never said you can not… BUT, when you want a simple diffuse per pixel lighened cube with a diffuse texture, ITS NOT POSSIBLE with one pass… and thats sad, not?..
i mean, such much power of such a powerfull geforce2 mx… and you cant do a bumpmap in one pass…
You can give up the normalization cubemap, for one. Perfect? No. Life isn’t perfect, and neither is 3D hardware.
3 textures is also useful, but it’s not a cure-all either. As LordKronos pointed out, you can easily justify wanting 7 textures! I would take 2 textures and the combiners any day over 3 textures, but I do happen to be biased.
To be honest, I wouldn’t even bother with per-pixel lighting without specular.
is there any chance that a nv20 has more texture stages? i mean, look at this:
#define GL_TEXTURE0_ARB 0x84C0
#define GL_TEXTURE1_ARB 0x84C1
#define GL_TEXTURE2_ARB 0x84C2
#define GL_TEXTURE3_ARB 0x84C3
#define GL_TEXTURE4_ARB 0x84C4
#define GL_TEXTURE5_ARB 0x84C5
#define GL_TEXTURE6_ARB 0x84C6
#define GL_TEXTURE7_ARB 0x84C7
#define GL_TEXTURE8_ARB 0x84C8
#define GL_TEXTURE9_ARB 0x84C9
#define GL_TEXTURE10_ARB 0x84CA
#define GL_TEXTURE11_ARB 0x84CB
#define GL_TEXTURE12_ARB 0x84CC
#define GL_TEXTURE13_ARB 0x84CD
#define GL_TEXTURE14_ARB 0x84CE
#define GL_TEXTURE15_ARB 0x84CF
#define GL_TEXTURE16_ARB 0x84D0
#define GL_TEXTURE17_ARB 0x84D1
#define GL_TEXTURE18_ARB 0x84D2
#define GL_TEXTURE19_ARB 0x84D3
#define GL_TEXTURE20_ARB 0x84D4
#define GL_TEXTURE21_ARB 0x84D5
#define GL_TEXTURE22_ARB 0x84D6
#define GL_TEXTURE23_ARB 0x84D7
#define GL_TEXTURE24_ARB 0x84D8
#define GL_TEXTURE25_ARB 0x84D9
#define GL_TEXTURE26_ARB 0x84DA
#define GL_TEXTURE27_ARB 0x84DB
#define GL_TEXTURE28_ARB 0x84DC
#define GL_TEXTURE29_ARB 0x84DD
#define GL_TEXTURE30_ARB 0x84DE
#define GL_TEXTURE31_ARB 0x84DF
#define GL_ACTIVE_TEXTURE_ARB 0x84E0
#define GL_CLIENT_ACTIVE_TEXTURE_ARB 0x84E1
#define GL_MAX_TEXTURE_UNITS_ARB 0x84E2
thats not from me, thats downloadable at the nvidiasite
i dont want to make you angry, i know you are from nvidia (some of you), and i have no problems with my geforce2mx (like on my old ati radeon… crashing all the time, and no other drivers there…)
but i think, for doing “simple” things like bumpmapping, or perpixelattentuationmapped pointlights for example, an ati radeon has much more power currently…
the bumpmapping is there ment environmentbumpmapping with a cubemap as environment… on the other site, the perpixelattentuationmap you can create with a nice texture3D, one …
and so you can do the other lights with a texture3d, too…
i’m sorry that i have to say things like this… but heh, no one is perfect… and as it looks, ive to implement multipassing… its just not nice when you have stenciling,alphablending for transparences and such,and depthtesting etc, when you have to switch from onepass to multipass… that gives some stresssituation… (and i dont like em )
on the other site, a tipp for next gpu’s… when you want perpixellighing in your gpu, then plz renormalize the normal at every pixel and give it like GL_PRIMARY_COLOR_EXT as a possible parameter… GL_INTERPOLATED_NORMAL_EXT… and a glEnable(GL_NORMALIZE_INTERPOLATION_EXT);
and THEN, bumpmapping can be done in one pass with dot3… (thats what i thought when i heard first time bout the geforce2…)